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

问题描述

作为一个注释：我已经阅读了Redux的文档（Baobab也是如此），并且我已经完成了Googling&测试。

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

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

我理解单店设置与多店设置的优缺点（关于此主题的SO上有很多Q& A ）。

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)?

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

在使用redux工作几个月之后，人们会考虑复杂的SPA，我可以说单店结构一直是一种纯粹的喜悦。

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个减速机，如果不是更多的话。即使在那个数量上，只有少数减速器处理任何给定调度的
  数据，其他减少器只返回先前的状态。一个巨大/复杂的商店（ 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 采用模式，并返回基于表的界面（有点像数据库）。 relational-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.

将多个reducers进一步拆分为reducer树是如何在Redux中保持模块更新的。如果您没有认识到这一点并且在没有完全理解减速器组成的情况下去多个商店，那么您将会错过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中实现依赖更新la waitFor ，方法是手动调用其他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级别上运行。这样的reducer enhancers不能为商店编写。

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中不需要多个商店（性能优势除外）无论如何你应该首先介绍一下）。我们将其作为文档中的一个重点，因此我们鼓励您学习减速器组合和其他Redux模式，而不是使用Redux，就像它是Flux一样，并且失去它的好处。

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屋！