最佳实践：使用 Redux 处理只读数据答案

【问题标题】：Best Practice: Handle read-only data with Redux最佳实践：使用 Redux 处理只读数据
【发布时间】：2016-03-27 01:51:39
【问题描述】：

我正在使用 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',
  },
];

为了尊重smart and dumb component proposal，我的LeftNav 组件是哑且无状态的。我还有一个智能组件（现在它只是我的AppContainer），它呈现LeftNav 组件并通过props 向它提供menuItems 数组。

我想知道我是否必须将此只读数据包含到我的 redux 状态树中。在这种情况下，我会有一个像这样的常量减速器：

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',
  },
]);

拥有一个没有动作处理程序的常量减速器是一个好习惯吗？如果不是，我应该怎么做？

提前致谢。

【问题讨论】：

标签： javascript reactjs react-router flux redux

【解决方案1】：

我不知道你的减速器是如何工作的。什么是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;
}

【讨论】：

您好，谢谢您的回答。 handleActions 由 redux-actions 提供。这是一个很小的函数，可以在创建 reducer 时减少样板。我用这个减速器调用combineReducers 来创建我的根减速器。

【解决方案2】：

我个人更喜欢我的 reducer 专注于处理应用程序/系统范围的状态。您的示例中的配置会感觉更像是在使用它的组件内作为常量生活在家里 (LeftNav?)

【讨论】：

感谢您的回答。我同意 reducer 应该更加关注应用程序状态。在不久的将来，我想动态生成这个配置（通过读取路由器配置），我不确定这应该发生在一个哑组件中。
不要被你选择的框架所束缚；只需将您的逻辑移动到实用程序/辅助函数中，然后从您的哑组件中导入即可。

【解决方案3】：

@Cnode 我同意@acjay 它应该处于reducer 状态，即使没有动作创建者。

我会更进一步，建议您应该在应用加载后获取数据，而不是将数据包含在构建的文件中。通常数据不属于构建文件。

这是因为，在现实世界中，这个特定的集合（以及其他 - 可能更大的集合）将在 API 上静态可用，因为您可能希望这些值可由 CMS 配置。

添加一个静态 reducer 来托管此状态
在应用程序初始化后获取数据，然后将其推送到状态 - 这意味着您将拥有至少一个动作创建者。

【讨论】：