注意：我已经阅读了Redux的文档（Baobab也是），我已经做了相当多的谷歌搜索和测试。
为什么强烈建议Redux应用只有一个商店？
我了解单店设置与多店设置的利弊（* 关于这个主题，有许多问答 ）。
IMO，这个架构决定是应用开发者根据他们的项目需求做出的。那么为什么Redux会强烈建议这样做，几乎到了强制性的地步（ 尽管没有什么能阻止我们建立多个商店 *）？
EDIT：转单店后反馈
经过几个月的工作与redux对什么许多人会认为是一个复杂的SPA，我可以说，单一的商店结构一直是一个纯粹的喜悦与工作。
以下几点可以帮助其他人理解为什么在许多使用案例中，单商店与多商店是一个没有实际意义的问题：
*可靠：我们使用选择器来挖掘应用程序的状态并获取上下文相关的信息。我们知道所有需要的数据都在一个存储中。它避免了所有关于状态问题可能在哪里的问题。
真快：我们的商店目前有近100个Reducer，如果不是更多的话。即使这样，只有少数Reducer在任何给定的分派上处理数据，其他的只是返回以前的状态。关于大型/复杂的商店（ 数量的Reducer ）很慢的论点是没有实际意义的。至少我们没有看到任何性能问题来自那里。
调试友好：虽然这是一个最有说服力的论点，使用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
}希望这个反馈能帮助其他人。
EDIT 2 -商店实用工具
对于那些一直想知道如何“轻松”管理一个 * 单个商店 * 的人，这可能很快就会变得复杂。有一个工具可以帮助隔离商店的结构依赖性/逻辑。
Normalizr基于模式对数据进行规范化，然后提供一个接口来处理数据，并通过id获取数据的其他部分，很像字典。
当时我不知道Normalizr，所以我沿着同样的思路构建了一些东西。relational-json接受一个模式，并返回一个基于表的接口relational-json的优点是数据结构可以动态地引用数据的其他部分（* 本质上，您可以像普通的JS对象一样在任何方向上遍历数据 *）。它不如Normalizr成熟，但我已经成功地在生产中使用了几个月了。
7条答案
按热度按时间sr4lhrrt1#
在一些极端情况下，你可能会使用多个商店（例如，如果你在每秒多次更新屏幕上数千个项目的列表时出现性能问题）。这是一个例外，在大多数应用程序中，你永远不需要多个商店。
为什么我们要在文档中强调这一点？因为大多数来自Flux背景的人会认为多个存储是使更新代码模块化的解决方案。然而Redux对此有一个不同的解决方案：还原剂成分。
将多个Reducer进一步划分成一个Reducer树，这就是在Redux中保持更新模块化的方式。如果你没有认识到这一点，并且在没有完全理解Reducer组成的情况下就开始使用多个存储，你将错过Redux单存储架构的许多好处：
waitFor支持的原因之一。对于单个存储，这不是您首先看到的问题。bxgwgixi2#
在一些拥有成百上千个Reducer的大型企业应用中，将应用的不同区域视为完全独立的应用通常是有用的。在这种情况下（实际上是多个应用共享一个域名），我使用多个商店。
例如，我倾向于将以下常见功能区域视为单独的应用程序：
如果其中任何一项很小，就把它们作为主应用程序的一部分。如果它们变得非常大（就像一些企业客户管理和分析工具那样），就把它们分开。
管理非常大的应用程序的最佳方法是将它们视为许多较小应用程序的组合。
如果您的应用程序小于约50 k LOC，您可能应该忽略此建议，并遵循Dan的建议。
如果您的应用程序超过100万LOC，您可能应该拆分迷你应用程序，即使您在单次回购中维护它们。
exdqitrt3#
此架构决策由应用程序开发人员根据其项目的需求做出
你生活在自己的世界里。我每天都在和使用redux的人见面，因为它很受欢迎。你甚至无法想象有多少项目是在没有任何决策的情况下开始redux的。我讨厌redux的方法，但我不得不使用它，因为其他开发者对它一无所知。这只是Facebook吹大的史诗般的泡沫。
*它不可靠因为商店的各个部分没有隔离。
*这是低效的，因为你是在克隆和遍历哈希trie。当变异以算术方式增长时，复杂性以几何方式增长。你不能通过重构任何reducer、selector等来修复它。你必须拆分你的trie。
*当它变慢的时候没有人想把它拆分成单独的应用程序和单独的存储。没有人想在重构上花钱。人们通常把一些智能组件转换成转储，就这样。你知道redux开发人员的未来是什么吗？他们将维护这些地狱。
*它不便于调试。很难调试存储中虚拟隔离部分之间的连接。甚至很难分析这些连接的数量。
假设你有几个redux商店，你会打破单向数据流，你会立刻意识到你的商店之间有多少连接，你会受到这些连接的影响，与循环deps斗争等等。
单向流的单一不可变存储并不是万能药，如果你不想维护项目架构，你无论如何都会受到影响。
uhry853o4#
为什么我们不能使用redux来使用多个存储？？？？
这在Redux中是不必要的，因为数据域之间的分离已经通过将单个Reducer拆分为更小的Reducer来实现。
我是否可以或应该创建多个存储区？我是否可以直接导入我的存储区，然后自己在组件中使用它？
最初的Flux模式描述了在一个应用中有多个“商店”，每个商店保存不同区域的域数据。这可能会带来一些问题，比如需要一个商店“等待”另一个商店更新。
这在Redux中是不必要的，因为数据域之间的分离已经通过将单个Reducer拆分为更小的Reducer来实现。
与其他几个问题一样，可以在一个页面中创建多个不同的Redux存储，但预期的模式是只有一个存储。拥有一个存储可以使用Redux DevTools，使持久化和再水合数据更简单，并简化订阅逻辑。
在Redux中使用多个存储的一些合理原因可能包括：
解决由于过于频繁地更新状态的某个部分而导致的性能问题，当通过分析应用确认时。将Redux应用隔离为更大应用中的一个组件，在这种情况下，您可能希望为每个根组件示例创建一个存储。但是，创建新存储不应该是您的第一本能，特别是如果您来自Flux背景。首先尝试Reducer合成，并且只有在多个存储不能解决问题时才使用它。
类似地，虽然您可以通过直接导入来引用商店示例，但在Redux中这不是推荐的模式。如果您创建一个商店示例并将其从模块中导出，它将成为一个单一示例。这意味着将Redux应用隔离为一个更大应用的组件（如果有必要）或启用服务器渲染将更加困难。因为您希望在服务器上为每个请求创建单独的存储示例。
official doc by redux
oknrviil5#
在下列使用案例中，多个存放区会很有帮助1.如果您有大型元件，且这些元件在数据结构、行为、应用程序内容方面彼此独立。隔离这些元件可让您更容易管理数据和应用程序流程。它也有助于独立开发和维护元件。2.效能问题：不是典型的使用案例，但是如果您的一些组件更新非常频繁，并且对其他组件没有任何影响，那么您可能可以选择不同的商店。
对于所有其他情况，您可能不需要有多个商店。正如丹所说，创造深思熟虑的还原剂组合可以证明是更好的解决方案。
ax6ht2ek6#
有一个商店在Redux是真正的我们需要在许多情况下，我都使用Redux和通量，并相信Redux做得更好！
不要忘记存储在JavaScript对象中，因此虽然您只有一个存储，但它可以很容易地扩展和重用，对我来说，有一个存储使使用Redux开发工具遍历变得更容易，并且不会在大型应用程序中混淆...
此外，一个商店的概念是模仿我们的数据库，一个真理的来源，你可以改变它，你可以访问它在浏览器内存...
如果整个应用程序管理良好，一个存储就足以管理整个应用程序的状态...
c9qzyr3d7#
为什么强烈建议Redux应用只有一个商店？
REDUX有3个主要原则：
1.单一事实来源：**“整个应用程序的状态存储在单个存储区的对象树中。"
2.状态为只读：**“更改状态的唯一方法是发出描述所发生情况的操作。"
3.使用纯函数进行更改：**“您将reducer编写为纯函数，以指定状态树通过操作进行转换的具体方式。"
**因此，如果我们使用多个存储区，那么它也可能违反原则1。虽然您可以使用多个REDUCERS，但在某些情况下，它会非常非常有用。**下面列出了由于多个存储区而可能出现的一些问题
1.很难调试。
1.放慢速度。
1.它可能有多个事实来源，因此可能导致多个运行时错误。
https://www.educative.io/courses/building-teslas-battery-range-calculator-with-react-and-redux/qVZRXlwQxv7