注:我已经阅读了Redux (Baobab也是)的文档，并且我也做了相当一部分的谷歌搜索和测试。
为什么强烈建议Redux应用只有一个商店?
我理解单店和多店的利弊(关于这个问题有很多问答)。
在我看来，这种架构决策应该由应用程序开发人员根据他们的项目需求做出。那么，为什么Redux如此强烈地推荐它，几乎是强制性的(尽管没有什么能阻止我们创建多个商店)?
编辑:转换为单店后的反馈
在与redux一起工作了几个月之后，我可以说，这种单一的商店结构是一种纯粹的乐趣。
以下几点可能有助于其他人理解为什么在许多用例中，单店vs多店是一个没有意义的问题:
it's reliable: we use selectors to dig through the app state and obtain context-relevant information. We know that all the needed data is in a single store. It avoids all questioning as to where state issues could be. it's fast: our store currently has close to 100 reducers, if not more. Even at that count, only a handful of reducers process data on any given dispatch, the others just return the previous state. The argument that a huge/complex store (nbr of reducers) is slow is pretty much moot. At least we've not seen any performance issues coming from there. debugging friendly: while this is a most convincing argument to use redux as a whole, it also goes for single store vs multiple store. When building an app you're bound to have state errors in the process (programmer mistakes), it's normal. The PITA is when those errors take hours to debug. Thanks to the single store (and redux-logger) we've never spent more than a few minutes on any given state issue.
几点建议
构建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获取数据的其他部分，很像Dictionary。
当时我还不知道Normalizr，所以我按照同样的思路构建了一些东西。relational-json接受一个模式，并返回一个基于表的接口(有点像数据库)。relational-json的优点是数据结构动态引用数据的其他部分(本质上，您可以在任何方向遍历数据，就像普通的JS对象一样)。它不像Normalizr那样成熟，但几个月来我一直在生产环境中成功地使用它。
