Многочисленные редукционные магазины или объединение редукторов для похожих форм? - PullRequest
Новая
       6

Многочисленные редукционные магазины или объединение редукторов для похожих форм?

0 голосов
/ 04 сентября 2018

У меня есть целевая страница, которая содержит 3 разные формы. На данный момент, целевая страница не обязательно должна быть подключена к Redx, данные статичны и не изменятся. Однако формы извлекают данные и позволяют пользователю отфильтровывать параметры на основе конкретной службы, которой они соответствуют и которая связана с redis. Формы практически идентичны по внешнему виду и функциональности, но все они имеют разные конечные точки.

Чтобы помочь мне объяснить здесь, это грубое отображение форм. S # - это выпадающий список, а кнопка - это ссылка, которая ведет пользователя на страницу с дополнительной информацией о выбранных значениях. 

|------------|
|    FORM    |
|------------|
|-----s1-----|
|-----s2-----|
|-----s3-----|
|--[button]--|

Если в s1 внесено изменение, он инициирует вызов API, который извлекает допустимые параметры для s2 и s3 и изменяет ссылку для кнопки. Аналогично, если s2 изменяется, комбинация выбора в s1 и s2 определяет параметры в s3.

В основном это работает, чтобы формы использовали те же редукторы и действия, но просто имели разные URL в зависимости от конечной точки API, передаваемой в форму через реквизит.

Вопрос в том, имеет ли смысл иметь эти 3 отдельных хранилища через ключ хранилища, передаваемые в соединение activ-redux, или они должны быть в одном хранилище, но затем регистрировать редуктор верхнего уровня на основе некоторого уникального ID

Итак, 3 магазина со следующей структурой данных верхнего уровня 

{
  selected: { [field: string]: string }
  options: { field: string]: string[] }
}

Или что-то вроде одного магазина, и каждая форма регистрирует редуктор с formId? 

{
  [formId: string]: {
    selected: { [field: string]: string },
    options: { field: string]: string[] }
  }
}

Ответы [ 2 ]

0 голосов
/ 12 сентября 2018

Нарезка состояния - одна из ролей редукторов. Приложения обычно должны иметь только один глобальный магазин. В вашем случае вы хотите разделить состояние для каждой из ваших трех форм, поэтому имеет больше смысла создать один или несколько редукторов для этого. Если состояние каждой формы тесно связано друг с другом, то ваш подход с одним редуктором - это хорошо, но для несвязанных данных рассмотрите возможность создания нескольких редукторов и использования функции CombinReducers.

0 голосов
/ 11 сентября 2018

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

У меня есть главный ModuleReducer, у которого есть действие registerModule. Это действие вызывает ключ, который будет добавлен в магазин. Главное, что каждое действие проходит через модуль-редуктор, и если это не действие модуля, оно передается другим редукторам для конкретного ключа.

Вот упрощенный пример кода. 

interface FormOptions {
  [key: string]: any;
}

interface FormValues {
  [key: string]: any;
}

interface ModuleState {
  options: FormOptions;
  selectedValues: FormValues;
}

interface AppStore {
  [id: string]: ModuleState;
}

const moduleReducer = (state: AppStore = {}, { type, payload }: AnyAction) => {
  const { formId } = payload;
  switch (type) {
    case 'REGISTER':
      return {
        ...state,
        [formId]: { options: {}, selectedValues: {} }
      };
    default:
      const { options, selectedValues, ...restState } = state[formId];
      return {
        ...state,
        [formId]: {
          ...restState,
          options: optionsReducer(options, ({ type, payload })),
          selectedValues: valueReducer(selectedValues, ({ type, payload }))
        }
      };
  }
}

В конечном итоге я решил сделать это таким образом, если формы ссылаются на общие значения в AppStore.

...