多家商店，为什么不呢？
请注意:我已经阅读了Redux的文档(Baobab也是如此)，我在Googling和测试方面也做了相当的工作。
为什么这么强烈地建议一个Redux应用程序只有一个商店？
我理解单一商店设置和多个商店设置的优缺点(在这个主题上有很多问题)。
国际海事组织，这一架构决定属于应用程序开发人员根据他们的项目的需要。那么，为什么对Redux的建议如此强烈，几乎可以说是强制性的(尽管没有什么能阻止我们制造多家商店)？
编辑:转换为单存储后的反馈
在与redux一起工作了几个月之后，很多人会认为这是一个复杂的SPA，我可以说，单一的商店结构是一种纯粹的乐趣。
有几点可能有助于其他人理解为什么单个商店和许多商店在许多用例中都不是一个有争议的问题：
- ，这是可靠的：我们使用选择器来挖掘应用程序的状态，并获取与上下文相关的信息。我们知道所有所需的数据都在一个单一的存储中。它避免了所有关于国家问题可能会出现在哪里的疑问。
- 它是快速：我们的商店目前有近100个减速机，如果不是更多。即使在这种情况下，只有少数还原器处理任何给定调度的数据，其他的只返回以前的状态。关于大型/复杂商店(减速机的丁腈橡胶)速度慢的论点几乎没有什么意义。至少我们还没有看到任何性能问题。
- 调试友好的：虽然这是使用整个redux的最有说服力的论点，但它也适用于单个商店和多个商店。在构建应用程序时，您肯定会在过程中出现状态错误(程序员的错误)，这是正常的。当这些错误需要几个小时的调试时，才会出现皮塔。多亏了单一的存储(和redux-记录器)，我们从未在任何给定的状态问题上花费超过几分钟的时间。
几个指南针
构建redux存储的真正挑战是如何确定如何构建结构存储。首先，因为沿途改变结构只是一大痛苦。第二，因为它在很大程度上决定了您将如何使用，并查询您的应用程序数据的任何进程。关于如何建造一家商店，有许多建议。在我们的例子中，我们发现以下几点是理想的：
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}希望这些反馈能帮助到其他人。
编辑2-有用的存储工具
对于那些一直想知道如何“轻松”管理单一商店的人来说，这会很快变得复杂起来。有一些工具可以帮助隔离存储的结构依赖关系/逻辑。
有一个基于模式的诺马利兹来规范您的数据。然后，它提供一个接口来处理您的数据，并通过id获取数据的其他部分，就像字典一样。
当时我不知道Normalizr，我按照同样的思路建造了一些东西。关系-json接受一个模式，并返回一个基于表的接口(有点像数据库)。关系-json的优点是您的数据结构动态地引用了数据的其他部分(本质上，您可以像普通的JS对象一样，向任意方向遍历数据)。它没有Normalizr那么成熟，但我已经成功地在生产中使用了几个月。
回答 7
Stack Overflow用户
发布于 2015-11-10 15:41:53
在某些情况下，您可能会使用多个存储(例如，如果您在更新数千个同时在屏幕上每秒多次出现的项目的列表时存在性能问题)。尽管如此，这是一个例外，在大多数应用程序中，你永远不需要超过一个单一的商店。
为什么我们要在文档里强调这个？因为大多数来自Flux背景的人将假设多个商店是使更新代码模块化的解决方案。然而，Redux有一个不同的解决方案:还原剂组成。。
在Redux中保持更新模块的方式是将多个还原器进一步拆分成一个还原器树。如果您不认识到这一点，并且在不完全了解还原剂组成的情况下选择多个商店，那么您将失去Redux单一商店体系结构的许多好处：
- 使用还原器组合可以通过编写一个减速器手动调用其他减速器，并按照特定的顺序，在Flux中实现“依赖更新”(
waitFor)。 - 使用单一的存储，它是非常容易坚持，水合物，并读取状态。服务器呈现和数据预取非常简单，因为只有一个数据存储需要在客户机上填充和重新补充，而JSON可以描述其内容，而不必担心存储的ID或名称。
- 单一商店使Redux DevTools时间旅行功能成为可能。它还使社区扩展(如redux或redux-optimist )变得容易，因为它们是在还原器级别上操作的。这种“减速剂增强剂”不能写在商店里。
- 一个单一的存储可以保证只有在处理了分派之后才调用订阅。也就是说，在通知侦听器时，状态已经完全更新。在许多商店里，没有这样的保证。这是磁通需要
waitFor拐杖的原因之一。对于单一的商店，这并不是你首先看到的问题。 - 最重要的是，在Redux中，多个存储是不必要的(除了性能边缘情况，您应该首先分析这些情况)。我们把它作为文档中的一个重要点，因此鼓励您学习还原剂组合和其他Redux模式，而不是像使用Flux那样使用Redux，并失去它的好处。
Stack Overflow用户
发布于 2017-03-18 05:23:54
在一些大型企业应用程序中，有成百上千个精简器，将应用程序的不同区域看作完全不同的应用程序通常是有用的。在这些情况下(实际上是多个共享域名的应用程序)，我使用多个商店。
例如，我倾向于将以下公共功能领域作为单独的应用程序来处理：
- 管理员
- 对仪表板的分析/数据
- 帐单管理和采购流程
- 企业账户小组/权限管理
如果其中任何东西都是小的，就把它们作为主应用程序的一部分。如果它们变得非常大(就像一些企业帐户管理和分析工具所做的那样)，那么将它们分开。
管理非常大的应用程序的最好方法是把它们当作许多小应用的组合。
如果你的应用程序少于50k LOC，你应该忽略这个建议，转而遵循Dan的建议。
如果您的应用程序超过100万LOC，您可能应该将迷你应用分开，即使您在单次回购中维护它们。
Stack Overflow用户
发布于 2018-08-01 22:03:48
此架构决策属于应用程序开发人员根据他们的项目需求做出的决定。
你生活在你自己的世界里。我正在与使用redux的人见面，因为它每天都很流行。你甚至无法想象有多少项目是在没有任何决策的情况下开始缩减的。我讨厌redux方法，但不得不使用它，因为其他开发人员什么也不知道。这只是一个由facebook膨胀的巨大泡沫。
- --它不是可靠的，因为存储的部分并不是孤立的。
- --这是效率低下的，因为您正在克隆和遍历散列。当突变在算术上增长时，复杂性就会几何级数增长。你不能通过重构任何减速器、选择器等来修复它。
- 当变慢时，没有人想把它分割成单独的应用程序，有单独的存储。没有人愿意花钱在重构上。人们通常是，将一些智能组件转换为转储，仅此而已。您知道redux开发人员的未来是什么吗？他们会维护这些地狱。
- ，这不是调试友好的。很难调试几乎孤立的存储部分之间的连接。即使分析这些连接的数量也是非常困难的。
让我们想象一下，您有几家redux商店。您将破坏单向数据流。你会立刻意识到你在商店之间有多少联系。你可能会受到这些关系的影响，比如与圆形防御部队的战斗等等。
单一的单向流动的不可变存储并不是每一种疾病的灵丹妙药。如果您不想维护项目架构，那么无论如何您都会受到影响。
https://stackoverflow.com/questions/33619775
复制相似问题
腾讯云开发者
