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

Question

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

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

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

null

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

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

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

Answer 1

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

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

将多个简化程序进一步拆分为简化程序树是在Redux中保持更新模块化的方法。如果你没有认识到这一点，在没有充分了解reducer组成的情况下就去多个商店，你将错过Redux单店架构的许多好处：