Redux-多家商店，为什么不呢？
注意：我已经阅读了Redux（Baobab，也是如此）的文档，并且做了很多Google搜索和测试工作。 为什么强烈建议Redux应用程序只有一个商店？ 我了解单商店设置与多商店设置的优缺点（关于此主题，有很多关于SO的问答）。 IMO，这个架构决定是基于应用程序开发人员的项目需求。那么，为什么如此强烈地建议Redux使用，几乎达到强制性的程度（尽管没有什么阻止我们开设多个商店）？ 编辑：转换为单店后的反馈 在与redux一起工作了几个月后，许多人认为它是复杂的SPA，我可以说单一的商店结构让我感到很高兴。 以下几点可能会帮助其他人理解为什么在许多很多用例中，单商店还是多商店是一个有争议的问题： 可靠：我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息。我们知道所有需要的数据都在一个存储中。它避免了所有关于国家问题可能在哪里的质疑。 速度很快：我们的商店目前有将近100个减速器，如果没有更多的话。即使达到这个数量，也只有极少数的减速器在任何给定的调度上处理数据，其他的只是还原以前的状态。关于大型/复杂存储（reducers的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，就像一个Dictionary。 当时我还不了解Normalizr，所以我沿相同的思路建立了一些东西。Relational-json采用一个模式，并返回一个基于Table的接口（有点像一个数据库）。Relational-json的优点是您的数据结构可以动态引用数据的其他部分（本质上，您可以像正常的JS对象一样在任何方向上遍历数据）。它不如Normalizr成熟，但是我已经在生产中成功使用了几个月。