Redux - 多个商店，为什么不呢？

javascript redux

作为说明：我已经阅读了 Redux 的文档（也是猴面包树），并且我已经完成了相当一部分的谷歌搜索和测试。

为什么强烈建议 Redux 应用程序只有一个商店？

我了解单店设置与多店设置的优缺点（关于此主题的 SO 有很多问答）。

IMO，这个架构决定属于应用程序开发人员根据他们的项目需求。那么为什么强烈建议 Redux 使用它，几乎到了听起来是强制性的程度（尽管没有什么能阻止我们创建多个商店）？

编辑：转换为单店后的反馈

在与 redux 合作了几个月后，许多人认为这是一个复杂的 SPA，我可以说单一商店结构是一种纯粹的工作乐趣。

有几点可以帮助其他人理解为什么在很多很多用例中单店与多店是一个没有实际意义的问题：

它是可靠的：我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息。我们知道所有需要的数据都在一个存储中。它避免了所有关于状态问题可能在哪里的问题。

速度很快：我们的商店目前有将近 100 个减速器，如果不是更多的话。即使这样算，在任何给定的 dispatch 上也只有少数 reducer 处理数据，其他的只是返回之前的状态。一个巨大/复杂的存储（nbr 个减速器）速度很慢的论点几乎没有实际意义。至少我们没有看到任何性能问题来自那里。

调试友好：虽然这是作为一个整体使用 redux 的最有说服力的论点，但它也适用于单存储与多存储。在构建应用程序时，您肯定会在过程中出现状态错误（程序员错误），这很正常。 PITA 是这些错误需要数小时才能调试的时候。多亏了单个存储（和 redux-logger），我们在任何给定的状态问题上花费的时间从未超过几分钟。

一些指示

构建 redux store 的真正挑战是决定如何构建它。首先，因为在路上改变结构只是一个主要的痛苦。其次，因为它在很大程度上决定了您将如何使用以及查询您的应用程序数据以获取任何进程。关于如何构建商店有很多建议。在我们的案例中，我们发现以下是理想的：

{
  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 采用架构，并返回基于表的接口（有点像数据库）。关系 json 的优点是您的数据结构可以动态引用数据的其他部分（本质上，您可以在任何方向遍历数据，就像普通的 JS 对象）。它不像 Normalizr 那样成熟，但我已经在生产中成功使用了几个月。

我喜欢您使用的商店结构的方法；但是，您如何处理映射到组件状态更改的 api 状态更改？假设我从我的 API 接收特定领域的数据，这如何转化为可以在我的组件中找到的通用数据结构？

你的组件如何映射/使用存储数据取决于你，真的。虽然我认为我不完全理解您的问题，但您能否详细说明或开始聊天会话？

我想问题是：您的组件是从 apis 状态渲染任何内容，还是只渲染放入组件状态的任何内容。我怀疑如果您设法仅从组件的状态进行渲染，那么您已经找到了一种很好的方法来使您的组件和容器即使在存在特定于域的数据的情况下也具有高度可重用性。如果您的组件部分从 API 状态和组件状态呈现，那么我猜您正在使用特定于域的容器将 apis 中的数据映射到您的组件理解的通用列表和原语。

我将 Redux 与选择器结合使用，选择器基本上是记忆化的功能纯数据映射器。每个组件都会“做出反应”以存储更新，如果更改与它相关，它会“选择”数据并相应地呈现。所以是的，组件只根据对他们来说重要的东西进行渲染。但这不仅仅是因为 Redux 或存储结构。这是由于结合了不可变数据存储、数据更改的引用比较测试以及以组件需要的格式获取组件所需数据的纯选择器。

嘿@SebastienDaniel，您能否举例说明您如何实施检查每个组件以了解商店更新中的更改是否与其相关？我的意思是，如果您使用某种通用模式......或者如果在每个特定情况下您正在检查特定组件相关数据是否已更改。

gandreadis

在某些极端情况下，您可能会使用多个商店（例如，如果您在每秒多次同时更新屏幕上的数千个项目的列表时遇到性能问题）。也就是说，这是一个例外，在大多数应用程序中，您只需要一个商店即可。

为什么我们在文档中强调这一点？因为大多数来自 Flux 背景的人会认为多个商店是使更新代码模块化的解决方案。然而 Redux 对此有不同的解决方案：reducer 组合。

将多个 reducer 进一步拆分为一个 reducer 树是您在 Redux 中保持更新模块化的方式。如果你没有意识到这一点，并且在没有完全了解 reducer 组成的情况下就选择了多个 store，那么你将错过 Redux 单 store 架构的许多好处：

使用 reducer 组合可以很容易地在 Flux 中实现“依赖更新”，方法是编写一个 reducer，手动调用具有附加信息和特定顺序的其他 reducer。

使用单个存储，很容易持久化、补充和读取状态。服务器渲染和数据预取是微不足道的，因为只有一个数据存储需要在客户端进行填充和再水化，并且 JSON 可以描述其内容而无需担心存储的 ID 或名称。

单个商店使 Redux DevTools 时间旅行功能成为可能。它还使 redux-undo 或 redux-optimist 等社区扩展变得容易，因为它们在 reducer 级别上运行。这样的“reducer enhancers”不能写给stores。

单个商店保证仅在处理了调度后才调用订阅。也就是说，在通知侦听器时，状态已完全更新。对于许多商店，没有这样的保证。这是 Flux 需要 waitFor 拐杖的原因之一。对于一家商店，这不是您首先看到的问题。

最重要的是，在 Redux 中不需要多个存储（除非您应该首先分析性能边缘情况）。我们在文档中强调了这一点，因此鼓励您学习 reducer 组合和其他 Redux 模式，而不是像使用 Flux 一样使用 Redux，从而失去它的好处。

我承认我不了解减速器组合的全部优势/必要性。感谢您的回答，我做了更多阅读和一个示例（TodoMVC，再次）。对于这样一个小例子，很难理解减速器组合所提供的实际改进。然而，稍加思考，在大范围内，收益（现在）是显而易见的。再次感谢，很好的答案！

@Sebastien 我认为“购物车”示例对此更好。

我正在慢慢地将 redux 实施到传统（非 SPA）应用程序中。我为每个转换为 react/redux 实现的“整体”使用 multilpe 商店，直到可以修改整个应用程序以使用同一个商店。

@DanAbramov 很好奇在您的主“应用程序”运行自己的 Redux 商店并通过 npm 导入运行自己的独立 Redux 商店的独立“应用程序”的情况下，您会怎么做。例如，如果您公司中的其他团队之一拥有某种带有 UI 的消息传递服务，您希望在不使用该数据污染您的商店的情况下将其拉入。

@natlee75 “在 Redux 中使用多个商店的一些正当理由可能包括：[...] 将 Redux 应用程序隔离为更大应用程序中的组件，在这种情况下，您可能希望为每个根组件实例创建一个商店。”来自redux.js.org/docs/FAQ.html#store-setup-multiple-stores

Eric Elliott

在一些具有成百上千个 reducer 的大型企业应用程序中，将应用程序的不同区域视为完全独立的应用程序通常很有用。在那些情况下（实际上是多个应用程序共享一个域名），我使用多个商店。

例如，我倾向于将以下常见功能区域视为单独的应用程序：

行政

分析/数据访问仪表板

计费管理和采购流程

企业客户团队/权限管理

如果其中任何一个很小，只需将它们作为主应用程序的一部分。如果它们变得非常大（就像一些企业帐户管理和分析工具所做的那样），请将它们分开。

管理超大型应用程序的最佳方法是将它们视为许多较小应用程序的组合。

如果您的应用程序小于约 50k LOC，您可能应该忽略此建议并遵循 Dan 的建议。

如果您的应用程序的 LOC 超过 100 万，您可能应该拆分迷你应用程序，即使您将它们维护在单一存储库中。

puchu

此架构决策属于应用程序开发人员根据其项目的需求

你活在自己的世界里。我正在与使用 redux 的人会面，因为它很流行，每天。你甚至无法想象有多少项目是在没有任何决定的情况下开始减少的。我讨厌 redux 方法，但不得不使用它，因为其他开发人员一无所知。这只是一个由 facebook 膨胀的史诗般的泡沫。

它不可靠，因为商店的某些部分没有被隔离。

它效率低下，因为您正在克隆和遍历哈希树。当突变以算术方式增长时 - 复杂性以几何方式增长。您无法通过重构任何 reducer、选择器等来修复它。您必须拆分您的 trie。

当它变慢时，没有人愿意将其拆分为具有单独存储的单独应用程序。没有人愿意在重构上花钱。人们通常将一些智能组件转换为转储，仅此而已。你知道等待 redux 开发者的未来是什么吗？他们将维持这些地狱。

它对调试不友好。很难调试商店虚拟隔离部分之间的连接。甚至很难分析这些连接的数量。

假设您有几个 redux 商店。您将中断单向数据流。您将立即意识到您在商店之间拥有多少联系。您可能会受到这些连接的影响，与循环部门的斗争等。

具有单向流动的单一不可变存储并不是所有疾病的灵丹妙药。如果您不想维护项目架构，那么您无论如何都会受苦。

我喜欢你所说的，here我就此提出了相关问题。你介意有时间看看这个并分享你的意见吗？我在 Reddit 上提出的问题，因为这里不鼓励这样的问题。

Rizwan

为什么我们不能使用 redux 使用多个商店？？？？

这在 Redux 中不是必需的，因为数据域之间的分离已经通过将单个 reducer 拆分为更小的 reducer 来实现。

我可以或应该创建多个商店吗？我可以直接导入我的商店，并自己在组件中使用它吗？

最初的 Flux 模式描述了在一个应用程序中有多个“商店”，每个商店都保存着不同区域的域数据。这可能会引入一些问题，例如需要让一个商店“等待”另一家商店进行更新。

这在 Redux 中不是必需的，因为数据域之间的分离已经通过将单个 reducer 拆分为更小的 reducer 来实现。

与其他几个问题一样，可以在一个页面中创建多个不同的 Redux 存储，但预期的模式是只有一个存储。拥有一个单独的 store 可以使用 Redux DevTools，使持久化和再水化数据更简单，并简化订阅逻辑。

在 Redux 中使用多个商店的一些正当理由可能包括：

当通过分析应用程序确认时，解决由于状态的某些部分更新过于频繁而导致的性能问题。将 Redux 应用程序隔离为更大应用程序中的组件，在这种情况下，您可能希望为每个根组件实例创建一个存储。但是，创建新商店不应该是您的第一直觉，尤其是如果您来自 Flux 背景。先尝试reducer组合，如果它不能解决你的问题，只使用多个商店。

同样，虽然您可以通过直接导入来引用您的商店实例，但这不是 Redux 中推荐的模式。如果您创建一个商店实例并从一个模块中导出它，它将成为一个单例。这意味着将 Redux 应用程序隔离为更大应用程序的组件（如果有必要）或启用服务器渲染将更加困难，因为您希望在服务器上为每个请求创建单独的商店实例。

official doc by redux

newtonflash

多个存储在以下用例中可能会有所帮助 1. 如果您有在数据结构、行为、应用程序上下文方面相互独立的大型组件。隔离这些组件可以更轻松地管理您的数据和应用程序流。它还有助于独立开发和维护您的组件。 2.性能问题：不是典型的用例，但是如果你的一些组件更新非常频繁，对其他组件没有任何影响，可能你可以去不同的商店。

对于所有其他情况，您可能不需要拥有多个商店。正如 Dan 所说，创建深思熟虑的减速器组合物可以证明是更好的解决方案。

您的消息看起来像“除少数情况外始终使用 redux”==“除了少数情况外，您不需要项目架构”。非常接近现实，我很高兴。

Alireza

在很多情况下，在 Redux 中拥有一家商店确实是我们所需要的，我都使用过 Redux 和 Flux，并且相信 Redux 做得更好！

不要忘记 store 是在一个 JavaScript 对象中，所以当你只有一个 store 时，它可以很容易地扩展和重用，对我来说，拥有一个 store 可以更容易地使用 Redux 开发工具进行遍历并且不会混淆大应用...

此外，一间商店的概念是为我们模仿数据库，一种您可以更改它的事实来源，您可以在浏览器内存中访问它......

如果整个应用管理好，一个商店就足以管理整个应用状态...

所以每个人都应该相信单店会做得更好，没有人能解释为什么。它让我想起一件事……

Redux - 多个商店，为什么不呢？

关注公众号

想领先一步获取最新的外包任务吗？

相似问题

平台

支持

联系我们