Правильный способ связи между изменением состояния в резервном хранилище и соответствующим изменением состояния реакции - PullRequest
1 голос
/ 09 июля 2019

У меня есть приложение реагирования, которое использует инструмент управления избыточным состоянием, а также локальное управление собственным состоянием, то есть состояние реакции (компонент / контейнер).Предположим, есть компонент формы, данные которого хранятся в состоянии реакции.Вызов API выполняется и обрабатывается через sagas, который соответствующим образом обновляет Redux Store.Как изменить состояние реакции, например, изменить ключ состояния формы на loading: false или, как правило, обновить форму (контролируемую или неконтролируемую) данными после того, как сага получит данные из вызова API.Для контролируемой формы будет компонент контейнера, который управляет реквизитом для этой формы, но опять же, как обновить состояние контейнера?Я не хочу хранить данные как в избыточном, так и в реактивном состоянии, особенно если эти данные предназначены для локального хранилища, а не для избыточного хранилища

Если я использую метод getDerivedStateFromProps, мне снова потребуетсяхранит эти данные, например, в reduxState, чтобы в конечном итоге скопировать или вычислить и перевести в состояние реакции.Я сейчас использую подход, описанный ниже, но мне было интересно, может ли кто-нибудь из вас предложить что-либо еще.

https://github.com/redux-saga/redux-saga/issues/907

Пример кода, который я использую, выглядит следующим образом:на тот, который описан в ссылке

validate = (drops, senderDetails, revalidate) => {
    const { largestLCU, actions: { validateDispatch } } = this.props
    const promise = new Promise(resolve => validateDispatch(drops, senderDetails,
      requestBatchSize, defaultMaxCapPerStop, defaultMarkerColor, largestLCU, resolve, revalidate))
    promise.then(({ success, data }) => {
      if (success) {
        this.setState((state) => {
          const { messages } = this.props
          return {
            ...state,
            senderDetails: {
              ...state.senderDetails,
              ...data,
            },
            currentStatus: {
              ...state.currentStatus,
              isAllValid: messages.length === 0,
              isFileSelected: false,
            },
            csvFile: null,
            loading: false,
          }
        })
      } else {
        this.setState({
          loading: false,
        })
      }
    })
  }

validateDispatch отправляет действие, перехватывает саги, выполняет вызов Api и возвращает определенные данные для обновления состояния реакции после разрешения Promise.Конечно, это компромисс

1 Ответ

1 голос
/ 09 июля 2019

Вообще говоря, я думаю, что вы захотите использовать Sagate Redux для его силы: обработки асинхронных побочных эффектов. Ваш пример кода обходит преимущества redux-saga, используя вместо этого обещания в функции обратного вызова. Ничто не мешает вам использовать redux-saga с, скажем, избыточным thunks или обещанными обратными вызовами на основе, но вы должны взвесить, стоит ли (или необходимо) иметь несколько способов обработки асинхронных побочных эффектов в вашем проекте.

Кажется, есть пара вопросов, которыми вы манипулируете.

Одной из проблем является дублирование данных в избыточном хранилище и состоянии компонента.

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

На какие данные вы ссылаетесь?

Если вы имеете в виду фактическую полезную нагрузку на сервер, то довольно обычно хранить полезную нагрузку на сервер в хранилище с избыточностью и иметь ответ-редукс, обновляющий компонент при изменении состояния избыточности. Это однонаправленный поток данных, на котором основан редукс.

Если вы имеете в виду «производные» данные (данные, которые могут быть получены из полезной нагрузки сервера), то я бы рекомендовал не дублировать эти данные как в хранилище с избыточностью, так и в состоянии компонента. Рекомендуется хранить только минимальный объем данных, необходимых в хранилище с избыточностью, иначе вы столкнетесь с проблемами согласованности и обслуживания / обновления нескольких копий одних и тех же данных. Вы можете посмотреть нормализаторы данных или селекторы (например, перевыбрать), чтобы справиться с этим. Документы Redux имеют довольно хорошее объяснение этих понятий.

Так как вы используете локальное состояние компонента, то, возможно, вы могли бы взглянуть на контекстный API реагирования , который служит альтернативой управлению состоянием избыточности. Я использовал контекстный API с локальным состоянием компонента, но в целом мои использования были ограничены действительно «временным / временным» состоянием пользовательского интерфейса (например, отображается ли / скрывается всплывающее окно). Я не пытался (или не нуждался) использовать контекст реагирования для обхода redux-saga / Reaction-redux, как в приведенном выше примере кода.

Удачи:)

...