Javascript Redux-多个商店，为什么不？

请注意：我已经阅读了Redux（Baobab）的文档，我也做了相当一部分的谷歌搜索和测试

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

我了解单店设置与多店设置的优缺点（在这个问题上有很多问答）

在我看来，这一架构决策属于基于项目需求的应用程序开发人员。那么，为什么它如此强烈地建议Redux，几乎到了听起来是强制性的（尽管没有什么能阻止我们创建多个商店）

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

经过几个月的研究，在很多人认为复杂的SPA之后，我可以说单商店结构是一种纯粹的乐趣。 以下几点可能有助于其他人理解为什么在许多、许多用例中，单个存储与多个存储是一个没有实际意义的问题：

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

几个指针

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

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

希望这个反馈能帮助其他人

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

有一种方法可以基于模式规范化数据。然后，它提供了一个界面来处理您的数据，并通过

id

获取数据的其他部分，很像一个字典

---

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

当您可能使用多个存储时，会出现一些边缘情况（例如，如果您在每秒多次更新屏幕上数千个项目的列表时遇到性能问题）。也就是说，这是一个例外，在大多数应用程序中，你只需要一个商店

为什么我们要在文件中强调这一点？因为大多数来自Flux背景的人会认为多个存储是使更新代码模块化的解决方案。然而，Redux对此有不同的解决方案：还原剂成分。

在Redux中，将多个简化程序进一步拆分为简化程序树是保持更新模块化的方法。如果您没有认识到这一点，并且在没有完全理解reducer的组成的情况下选择多个商店，那么您将错过Redux单商店体系结构的许多好处：

• 使用reducer composition可以很容易地在Flux中实现la

  waitFor

  的“依赖更新”，方法是编写一个reducer，用附加信息和特定顺序手动调用其他reducer

• 使用单个存储，很容易保存、水合和读取状态。服务器呈现和数据预取非常简单，因为客户端上只有一个数据存储需要填充和重新水化，JSON可以描述其内容，而不必担心存储的ID或名称

• 单个商店使Redux开发工具的时间旅行功能成为可能。它还使诸如redux undo或redux Optimit之类的社区扩展变得容易，因为它们在reducer级别上运行。这种“还原剂增强剂”不能用于商店

• 单个存储保证仅在处理分派后调用订阅。也就是说，在通知侦听器时，状态已完全更新。对于许多商店，没有这样的保证。这就是Flux需要

  waitFor

  拐杖的原因之一。对于一个单一的商店，这并不是你一开始就看到的问题

• 最重要的是，在Redux中不需要多个存储（性能边缘情况除外，您应该首先分析这些情况）。我们在文档中强调了这一点，因此鼓励您学习reducer合成和其他Redux模式，而不是像使用Flux一样使用Redux，从而失去其优势

---

在以下用例中，多个存储区可能会有所帮助 1.如果您有在数据结构、行为和应用程序上下文方面相互独立的大型组件。隔离这些组件