Передовой опыт: работа с данными только для чтения с помощью Redux

Я создаю приложение с помощью React и Redux, и у меня есть вопрос о дизайне.

В моем приложении используется React Router. Он имеет панель навигации (слева), которая отображает маршруты из файла конфигурации React Router с меню Material Design.

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

Эти данные имеют следующий вид:

const menuItems = [
  {
    icon: 'home',
    label: 'Home',
    url: '/home',
    withDivider: true,
    access: 'all',
  },
  {
    icon: 'settings',
    label: 'Settings',
    url: '/settings',
    access: 'admin',
  },
  {
    icon: 'power_settings_new',
    label: 'Log Out',
    url: '/logout',
    access: 'user',
  },
];

В соответствии с предложением по умным и глупым компонентам, мой LeftNav компонент глуп. и без гражданства. У меня также есть интеллектуальный компонент (сейчас это просто мой AppContainer), который отображает компонент LeftNav и предоставляет ему массив menuItems через реквизит.

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

export default handleActions({}, [
  {
    icon: 'home',
    label: 'Home',
    url: '/home',
    withDivider: true,
    access: 'all',
  },
  {
    icon: 'settings',
    label: 'Settings',
    url: '/settings',
    access: 'admin',
  },
  {
    icon: 'power_settings_new',
    label: 'Log Out',
    url: '/logout',
    access: 'user',
  },
]);

Хорошо ли иметь постоянный редьюсер без обработчика действий? Если нет, что мне делать?

Заранее спасибо.


reactjs javascript redux react-router flux
person Cnode    schedule 21.12.2015    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Лично я предпочитаю, чтобы мои редукторы сосредоточивались на работе с состоянием приложения/системы. Конфигурация в вашем примере будет чувствовать себя более комфортно, живя как константа внутри компонента, который ее использует (LeftNav?)

person JonnyReeves    schedule 21.12.2015
comment
Спасибо за этот ответ. Я согласен с тем, что редюсеры должны больше ориентироваться на состояние приложения. В ближайшем будущем я хочу динамически генерировать эту конфигурацию (прочитав конфигурацию маршрутизатора), и я не уверен, что это должно происходить в немом компоненте. - person Cnode; 21.12.2015
comment
Не чувствуйте себя ограниченным своим выбором фреймворка; просто переместите свою логику в служебную/вспомогательную функцию и импортируйте ее из своего тупого компонента. - person JonnyReeves; 26.12.2015

arrow_upward
2
arrow_downward

Я не узнаю, как работает ваш редуктор. Что такое handleActions?

Я думаю, что постоянный редуктор кажется разумным решением, но я бы реализовал его, используя первый параметр по умолчанию. Предполагая, что вы используете combineReducers для охвата всех ваших редукторов частью состояния, которое они контролируют, я бы сделал что-то вроде:

/* reducers.js */

const menuItemsInitialState = [
  {
    icon: 'home',
    label: 'Home',
    url: '/home',
    withDivider: true,
    access: 'all',
  },
  {
    icon: 'settings',
    label: 'Settings',
    url: '/settings',
    access: 'admin',
  },
  {
    icon: 'power_settings_new',
    label: 'Log Out',
    url: '/logout',
    access: 'user',
  },
];

export function menuItems(state = menuItemsInitialState, _) {
  return state;
}
person acjay    schedule 21.12.2015
comment
Привет, спасибо за ответ. handleActions предоставляется redux-actions. Это крошечная функция, которая уменьшает шаблон при создании редуктора. Я вызываю combineReducers с помощью этого редуктора, чтобы создать корневой редуктор. - person Cnode; 21.12.2015

arrow_upward
0
arrow_downward

@Cnode Я согласен с @acjay, что он должен быть в состоянии редуктора, даже без создателей действий.

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

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

  1. Добавьте статический редуктор для размещения этого состояния
  2. Получите данные после инициализации приложения, а затем поместите их в состояние — это означает, что у вас будет как минимум один создатель действия.
person Elise Chant    schedule 05.04.2018