Каковы наиболее важные соображения при разработке действий Redux?

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

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

Самое важное соображение при разработке действий: что они означают для состояния моего пользовательского интерфейса? Какое влияние они на него оказывают? Как они связаны с состоянием моего магазина?

Если вы хотите объединить код вызовов API, существуют различные шаблоны для этого: используйте простую вспомогательную функцию, принимающую параметры, используйте что-то вроде redux-saga для запуска побочных эффектов и т. д. Но в целом вызовы API не должны не иметь значения при разработке действий.

В документах ничего не говорится о том, что действия должны сопоставляться с конечными точками API. Поэтому вам не нужно думать о том, сколько у вас конечных точек API.

Из http://redux.js.org/docs/basics/Actions.html:

Действия — это полезные данные, которые отправляют данные из вашего приложения в ваш магазин.

Однако в вашем случае, если одно действие с полезной нагрузкой может привести к результату и изменить ваш state до желаемого состояния, я не вижу причин использовать три (и, следовательно, иметь три редуктора и т. д.).

В документах Redux есть хороший раздел о том, как асинхронные действия/использование API должны работать в приложении Redux.

http://redux.js.org/docs/advanced/AsyncActions.html

Я следовал этому шаблону, используя промежуточное ПО thunk, и обнаружил, что оно работает очень хорошо. Идея состоит в том, чтобы дать вашим действиям возможность возвращать функцию. У вас будет:

• «Основная» функция, которая будет отправлять информацию о том, что приложение выполняет вызов API, выполняет вызов API и обрабатывает результаты.
• Два чистых создателя действий (функции, которые возвращают объект с типом и любым количеством других свойств), которые будут передавать информацию, связанную с вызовом API, вашим редукторам.

Действия:

/* Inside ./action.js */

/* This is the function you will dispatch from another component (say, a container component. This takes advantage of thunk middleware. */

export function fetchAllInfo() {

  return function(dispatch) {
    dispatch(requestAllInfo())

    /* Import your API function, make sure it takes a callback as an argument */
    API.fetchAllInfo((allinfo) => {
      dispatch(receiveAllInfo(allinfo))
    }
}

/* Pure action creators */
function requestAllInfo() {
  return {
    type: "REQUEST_ALL_INFO",
  }
}

function receiveAllInfo(allinfo) {
  return {
    type: "RECEIVE_ALL_INFO",
    allinfo,
  }
}

Редуктор:

/* Inside ./reducer.js */

export function inforeducer(state, action) {
  switch(action.type) {
    case "REQUEST_ALL_INFO": {
      return Object.assign({}, state, {
        /* This can be passed as prop so a component knows to show a loader */
        isFetching: true,
      })
    case "RECEIVE_ALL_INFO": {
      return Object.assign({}, state, {
        isFetching: false,
        allInfo: action.allInfo,
      })
    }
    default:
      return state
  }
}

Таким образом, с промежуточным программным обеспечением thunk (или вашим собственным способом работы с асинхронной диспетчеризацией) и обратным вызовом при каждом вызове API вы можете использовать этот метод для работы с диспетчеризацией вызовов API как в начале вызова, так и при получении результатов.