我应该在商店中存储永不更改（引导）的数据吗？答案

【问题标题】：Should I store never changing (bootstrapped) data in the store?我应该在商店中存储永不更改（引导）的数据吗？
【发布时间】：2016-06-22 21:12:12
【问题描述】：

我的应用程序中有一些状态来自服务器并且不会改变（在用户会话的生命周期内）。这种状态在 HTML 中被引导。

我应该将它作为 store 的一部分并入减速器中吗？ const bootstrappedData = (state, action) => state

或者我应该公开一些像bootstrappedData.get('key') 这样的全局助手？

【问题讨论】：

标签： reactjs redux flux

【解决方案1】：

有趣的是，我昨天就自己商店中的数据做出了同样的决定。我得出的结论是，我们应该只在 Redux 存储中存储 有状态 数据，即能够维护状态的数据，或者可能会发生变化的数据。根据定义，静态数据没有状态，因此不需要这样跟踪。

因此，我通常有一个 /common/app-const.js 文件来存储这些类型的静态对象。例如，我在这里存储了 Redux 的 DEFAULT_STATE，但也存储了其他一些不会更改的对象（因此在 Redux 中不跟踪）。

现在假设我实际上希望允许最终用户在 UI 中操作 numRows 和 numCols，那时我肯定需要将它们放在 Redux 存储中，但不是现在，因为它们只是静态常量！

/common/app-const.js

export const DEFAULT_STATE = {
    model: {},
    timer: {
        isRunning: false,
        ticks: 0
    }
};

export const GRID_DATA = {
    numRows: 50,
    numCols: 75,
};

每当我需要这些静态数据时，它就像导入一样简单：

import { GRID_DATA } from '../common/app-const';

【讨论】：

【解决方案2】：

与这个问题稍微相关的是异步（非自举）但静态数据，

为此，将数据存储在 Store 中与 Store 之外需要权衡取舍。

商店内部

优点

无需使用console.log即可轻松查看和调试数据
查询数据是通过选择器同步的

缺点

概念不准确，因为静态数据根据定义不是有状态的，而存储是用来保存状态的

商店外

优点

概念上准确（基于this reasoning）

缺点

由于数据是异步的，因此您必须导出异步数据访问 API（相对于同步选择器）
异步数据导致有状态组件（例如在生命周期挂钩中获取数据并将数据设置为状态）

我在大型生产应用程序中采用了前一种方法，回想起来，我更愿意采用后者。

【讨论】：