作为说明：我已经阅读了 Redux 的文档（也是猴面包树），并且我已经完成了相当一部分的谷歌搜索和测试。

为什么强烈建议 Redux 应用程序只有一个商店？

我了解单店设置与多店设置的优缺点（ 关于此主题的 SO 有很多问答 ）。

IMO，这个架构决定属于应用程序开发人员根据他们的项目需求。那么为什么强烈建议 Redux 使用它，几乎到了听起来是强制性的程度（
尽管没有什么能阻止我们创建多个商店 ）？

编辑：转换为单店后的反馈

在与 redux 合作了几个月后，许多人认为这是一个复杂的 SPA，我可以说单一商店结构是一种纯粹的工作乐趣。

有几点可以帮助其他人理解为什么在很多很多用例中单店与多店是一个没有实际意义的问题：

• 它是可靠的 ：我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息。我们知道所有需要的数据都在一个存储中。它避免了所有关于状态问题可能在哪里的问题。
• 很快 ：我们的商店目前有将近 100 个减速器，如果不是更多的话。即使这样算，在任何给定的 dispatch 上也只有少数 reducer 处理数据，其他的只是返回之前的状态。 大型/复杂存储（ nbr of reducers ）速度慢的论点几乎没有实际意义。至少我们没有看到任何性能问题来自那里。
• 调试友好 ：虽然这是作为一个整体使用 redux 的最有说服力的论点，但它也适用于单存储与多存储。在构建应用程序时，您肯定会在过程中出现状态错误（ 程序员错误 ），这是正常的。PITA 是这些错误需要数小时才能调试的时候。多亏了单个存储（ 和 redux-logger ），我们在任何给定的状态问题上花费的时间从未超过几分钟。

一些指示

构建 redux store 的真正挑战是决定如何 构建
它。首先，因为在路上改变结构只是一个主要的痛苦。其次，因为它在很大程度上决定了您将如何使用以及查询您的应用程序数据以获取任何进程。关于如何构建商店有很多建议。在我们的案例中，我们发现以下是理想的：

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

希望此反馈对其他人有所帮助。

编辑 2 - 有用的商店工具

对于那些一直想知道如何“轻松”管理 单个商店 的人，这很快就会变得复杂。有一个工具可以帮助隔离商店的结构依赖/逻辑。

Normalizr可以根据模式对您的数据进行规范化。然后它提供了一个接口来处理您的数据并通过
获取数据的其他部分id，就像字典一样。

当时不知道 Normalizr，我按照相同的思路构建了一些东西。关系
json接受一个模式，并返回一个基于表的接口（
有点像数据库 ）。关系 json 的优点是你的数据结构可以动态地引用数据的其他部分（ 本质上，你可以在任何方向遍历你的数据，就像普通的 JS
对象一样 ）。它不像 Normalizr 那样成熟，但我已经在生产中成功使用了几个月。