Redux - 多个商店，为什么不呢? [英] Redux - multiple stores, why not?

问题描述

请注意:我已经阅读了 Redux(也是猴面包树)的文档，并且我已经完成了相当一部分的谷歌搜索和 Google 搜索.测试.

As a note: I've read the docs for Redux (Baobab, too), and I've done a fair share of Googling & testing.

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

我了解单店设置与多店设置的优缺点(关于此主题的 SO 有很多问答).

I understand the pros/cons of a single-store setup vs a multiple store setup (There are many Q&A on SO on this subject).

IMO，此架构决策属于应用开发人员，基于他们的项目需求.那么为什么强烈建议 Redux 使用它，几乎到了强制要求的地步(尽管没有什么能阻止我们制作多个商店)?

IMO, this architectural decision belongs to the app developers based on their projects' needs. So why is it so strongly suggested for Redux, almost to the point of sounding mandatory (though nothing is stopping us from making multiple stores)?

转换为单店后的反馈

在许多人认为是复杂的 SPA 上与 redux 合作了几个月后，我可以说单一存储结构的使用是一种纯粹的乐趣.

After a few months working with redux on what many would consider a complex SPA, I can say that the single store structure has been a pure delight to work with.

以下几点可能有助于其他人理解为什么单店与多店在许多用例中都是一个没有实际意义的问题:

A few points that might help others understand why single store vs many store is a moot question in many, many use-cases:

• 可靠:我们使用选择器来挖掘应用状态并获取上下文相关信息.我们知道所有需要的数据是在一个单一的商店.它避免了所有关于在哪里状态的问题问题可能是.
• 速度很快:我们的商店目前有近 100 个减速机，甚至更多.即便如此，也只有少数 reducer 处理数据任何给定的调度，其他的只是返回之前的状态.这一个巨大/复杂的存储(nbr of reducers)很慢的论点是几乎没有实际意义.至少我们没有看到任何性能问题来自那里.
• 调试友好:虽然这是整体使用 redux 的最有说服力的论点，但它也适用于单个存储与多个存储店铺.在构建应用程序时，您肯定会在过程(程序员错误)，这是正常的.PITA 是当那些错误需要几个小时来调试.感谢单一商店(和redux-logger) 我们从来没有在任何给定的项目上花费超过几分钟的时间状态问题.

• 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 存储的真正挑战在于决定如何构建它.首先，因为在路上改变结构只是一个主要的痛苦.其次，因为它在很大程度上决定了您将如何使用和查询您的应用程序数据以获取任何进程.有很多关于如何构建商店的建议.在我们的案例中，我们发现以下情况是理想的:

The true challenge in building your redux store is when deciding how to structure it. Firstly, because changing structure down the road is just a major pain. Secondly, because it largely determines how you'll be using, and querying your app data for any process. There are many suggestions on how to structure a store. In our case we found the following to be ideal:

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

希望此反馈能对其他人有所帮助.

Hopefully this feedback will help others.

对于那些一直想知道如何轻松"管理单个商店的人来说，这很快就会变得复杂.有一些工具可以帮助隔离商店的结构依赖性/逻辑.

For those of you who have been wondering how to "easily" manage a single store, which can quickly get complex. There are a tools that help isolate the structural dependencies/logic of your store.

Normalizr 可以根据架构规范化您的数据.然后它提供了一个接口来处理您的数据并通过 id 获取数据的其他部分，就像字典一样.

There is Normalizr which normalizes your data based on a schema. It then provides an interface to work with your data and fetch other parts of your data by id, much like a Dictionary.

当时不知道 Normalizr，我按照同样的思路构建了一些东西.relational-json 接受一个模式，并返回一个基于表的接口(有点像数据库).关系型 json 的优势在于您的数据结构动态引用数据的其他部分(本质上，您可以向任何方向遍历数据，就像普通的 JS 对象).它不如 Normalizr 成熟，但我已经在生产中成功使用它几个月了.

Not knowing Normalizr at the time, I built something along the same lines. relational-json takes a schema, and returns a Table-based interface (a little like a database). The advantage of relational-json is that your data structure dynamically references other parts of your data (essentially, you can traverse your data in any direction, just like normal JS objects). It's not as mature as Normalizr, but I've been using it successfully in production for a few months now.

推荐答案

当您可能使用多个存储时，存在一些边缘情况(例如，如果您在更新屏幕上同时显示数千个项目的列表时遇到性能问题)每秒次数).也就是说，这是一个例外，在大多数应用中，您只需要一个商店.

There are edge cases when you might use multiple stores (e.g. if you have performance problems with updating lists of thousands of items that are on screen at the same time many times per second). That said it's an exception and in most apps you never need more than a single store.

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

Why do we stress this in the docs? Because most people coming from Flux background will assume multiple stores is the solution to making update code modular. However Redux has a different solution for this: reducer composition.

将多个 reducer 进一步拆分为一个 reducer 树是您在 Redux 中保持更新模块化的方式.如果你没有认识到这一点，在没有完全理解 reducer 组成的情况下去多个 store，你就会错过 Redux 单存储架构的许多好处:

Having multiple reducers that are further split into a reducer tree is how you keep updates modular in Redux. If you don't recognize this and go for multiple stores without fully understanding reducer composition first, you will miss many benefits of Redux single store architecture:

• 使用 reducer 组合可以轻松地在 Flux 中通过 waitFor 实现依赖更新"，方法是编写一个 reducer，以特定顺序手动调用其他带有附加信息的 reducer.

• Using reducer composition makes it easy to implement "dependent updates" a la waitFor in Flux by writing a reducer manually calling other reducers with additional information and in a specific order.

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

With a single store, it's very easy to persist, hydrate, and read the state. Server rendering and data prefetching is trivial because there is just one data storage that needs to be filled and rehydrated on the client, and JSON can describe its contents without worrying about store's ID or name.

单一商店使 Redux DevTools 时间旅行功能成为可能.它还使 redux-undo 或 redux-optimist 等社区扩展变得容易，因为它们在减速器级别上运行.不能为商店编写这种reducer 增强器".

A single store makes Redux DevTools time travel features possible. It also makes community extensions like redux-undo or redux-optimist easy because they operate on the reducer level. Such "reducer enhancers" can't be written for stores.

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

A single store guarantees that the subscriptions are called only after the dispatch has been processed. That is, by the time listeners are notified, the state has been fully updated. With many stores, there are no such guarantees. This is one of the reasons Flux needs the waitFor crutch. With a single store, this is not a problem you see in the first place.

最重要的是，在 Redux 中不需要多个存储(除了性能边缘情况，无论如何你应该首先分析).我们将其作为文档中的一个重点，因此鼓励您学习 reducer 组合和其他 Redux 模式，而不是像使用 Flux 一样使用 Redux，从而失去它的好处.

Above all, multiple stores are unnecessary in Redux (except for performance edge cases which you are supposed to profile first anyway). We make it an important point in the docs so you are encouraged to learn reducer composition and other Redux patterns instead of using Redux as if it was Flux, and losing its benefits.

这篇关于Redux - 多个商店，为什么不呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！