Redux - 多个商店，为什么不呢？
2022-08-30 00:24:38
请注意：我已经阅读了Redux（Baobab）的文档，并且我已经做了相当多的谷歌搜索和测试。
为什么如此强烈地建议Redux应用程序只有一个商店？
我了解单店设置与多店设置的利弊（关于这个主题有很多关于SO的问答）。
IMO，此架构决定属于应用程序开发人员，具体取决于其项目的需求。那么，为什么Redux如此强烈地建议使用它，几乎到了听起来强制性的地步（尽管没有什么能阻止我们制作多个商店）？
编辑：转换为单店后的反馈
在与redux合作几个月后，许多人认为这是一个复杂的SPA，我可以说，单一商店结构是一种纯粹的乐趣。
有几点可以帮助其他人理解为什么单个商店与许多商店在许多用例中是一个没有实际意义的问题：
- 它是可靠的：我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息。我们知道，所有需要的数据都在一个存储中。它避免了所有关于国家问题可能在哪里的问题。
- 它很快：我们的商店目前有近100个减速器，如果不是更多的话。即使在这个计数下，也只有少数化简器处理任何给定调度的数据，其他化简器只返回以前的状态。一个巨大的/复杂的存储（nbr的化简器）很慢的论点几乎是没有意义的。至少我们还没有看到任何来自那里的性能问题。
- 调试友好：虽然这是使用整个redux的最有说服力的论点，但它也适用于单个商店与多个商店。在构建应用程序时，您必然会在过程中出现状态错误（程序员错误），这是正常的。PITA 是当这些错误需要数小时才能调试时。多亏了单一存储（和 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 - 有用的商店工具
对于那些一直想知道如何“轻松”管理单个商店的人来说，这可能会很快变得复杂。有一些工具可以帮助隔离商店的结构依赖关系/逻辑。
有Normalizr可以根据架构规范化您的数据。然后，它提供了一个接口来处理您的数据，并通过 获取数据的其他部分，就像字典一样。id
当时我不了解Normalizr，所以我按照同样的路线构建了一些东西。relational-json 采用一个模式，并返回一个基于表的接口（有点像数据库）。relational-json的优点是你的数据结构动态地引用数据的其他部分（本质上，你可以在任何方向上遍历数据，就像普通的JS对象一样）。它不像Normalizr那样成熟，但我已经在生产中成功地使用了几个月了。
