Как я могу отслеживать состояние различных вызовов API в Redux?

Я видел много способов справиться с этим, все со своими плюсами и минусами.

Каждый ресурс имеет свой статус

Хотя правил нет, обычно предлагается, чтобы пользователи Redux моделировали схему своего состояния, как если бы это была база данных.

В основном это означает, что вы будете хранить ресурсы, проиндексированные по некоторому идентификатору. В этом случае у вас есть список задач, поэтому ваше состояние может выглядеть так:

{
  todosById: {
    '1': {
      id: '1',
      content: 'Do something'
    },
    '2': {
      id: '2',
      content: 'Do another thing'
    }
  }
}

Если вам нужен массив всех задач, вы создаете его на лету всякий раз, когда выбираете свое состояние:

const selectTodos = (state) => Object.values(state.todosById);
/*
  [{
    id: '1',
    content: 'Do something'
  }, {
    id: '2',
    content: 'Do another thing'
  }]
*/

const selectTodoIds = (state) => Object.keys(state.todosById)
// ['1', '2']

Зачем тебе это? Одна из причин заключается в том, что это упрощает поиск вещей по идентификатору, что часто необходимо в пользовательском потоке; например показать список вещей, а затем использовать выбирает одну из них.

Другая причина, применимая в описанной вами ситуации, заключается в том, что теперь мы можем отслеживать состояние каждого ресурса отдельно. Таким образом, каждый из них может иметь свои собственные isFetching, isSaving и т. д. Или, если вы хотите гарантировать, что ресурс находится только в одном состоянии, вы можете использовать перечисление, но будьте осторожны, что это действительно невозможно для выборки и сохранения в то же время!

{
  todosById: {
    '1': {
      id: '1',
      content: 'Do something',
      isFetching: false,
      isSaving: false
    },
    '2': {
      id: '2',
      content: 'Do another thing',
      isFetching: false,
      isSaving: false
    }
  }
}

interface Todo {
  id: string;
  content: string;
  isFetching: boolean;
  isSaving: boolean;

  // or using an enum. here are some possibilities:
  enum Status { Fetching, Saving, New, Prestine, Dirty }
  status: Status;
}

Это также работает естественным образом, когда ваш пользователь заходит непосредственно на один из ресурсов. например если они могут перейти к одному Todo, вы должны заполнить его в todosById и точно так же отслеживать его статус. Если вы позже также загрузите список задач, последнее значение с сервера будет объединено с нашей ранее загруженной задачей.

Когда вы имеете дело с созданием нового ресурса на стороне клиента, у вас, вероятно, еще не будет идентификатора для него, пока вы не сохраните его на сервере. В этом конкретном случае у меня есть временный идентификатор, который генерируется и используется только на стороне клиента. например 'tmp-todo-1', 'tmp-todo-2' и т. д.

{
  todosById: {
    'tmp-todo-1': {
      id: 'tmp-todo-1',
      content: 'A new todo that has never been saved yet',
      status: Status.New
    },
    '1': {
      id: '1',
      content: 'A todo that has been created but has unsaved changes',
      status: Status.Dirty
    },
    '2': {
      id: '2',
      content: 'Do another thing',
      status: Status.Prestine
    }
  }
}

Отдельное государство

Другой вариант более сложного управления запросами ресурсов — полностью отделить его от ресурсов, которые они извлекают/сохраняют и т. д.

Что-то похожее на это:

{
  meta: {
    '1': {
      isFetching: false,
      isSaving: false
    },
    '2': {
      isFetching: false,
      isSaving: false
    }
  },
  todosById: {
    '1': {
      id: '1',
      content: 'Do something'
    },
    '2': {
      id: '2',
      content: 'Do another thing'
    }
  }
}

Преимущество этого заключается в том, что не нужно объединять сам ресурс с состоянием только на стороне клиента, которое не включено в сервер, например, что такое isFetching.

Существует много вариантов этого, некоторые из которых создали библиотеки, такие как redux-resource, хотя я не использовал эту конкретную библиотеку, поэтому я не могу много говорить о ней. Я использую пользовательские абстракции, которые я сделал.

Почему бы не иметь единственное значение isBusy в магазине? затем ваши редукторы переключают это на основе ADD_TODO_.., DELETE_TO_DO_.. и т. д. Это предполагает, что вы показываете только один индикатор занятости.