Redux - multiple stores, why not?

why we can't use multiple store using redux????

This is not necessary in Redux because the separation between data domains is already achieved by splitting a single reducer into smaller reducers.

---

Can or should I create multiple stores? Can I import my store directly, and use it in components myself?

The original Flux pattern describes having multiple “stores” in an app, each one holding a different area of domain data. This can introduce issues such as needing to have one store “waitFor” another store to update.

This is not necessary in Redux because the separation between data domains is already achieved by splitting a single reducer into smaller reducers.

As with several other questions, it is possible to create multiple distinct Redux stores in a page, but the intended pattern is to have only a single store. Having a single store enables using the Redux DevTools, makes persisting and rehydrating data simpler, and simplifies the subscription logic.

Some valid reasons for using multiple stores in Redux might include:

Solving a performance issue caused by too frequent updates of some part of the state, when confirmed by profiling the app. Isolating a Redux app as a component in a bigger application, in which case you might want to create a store per root component instance. However, creating new stores shouldn't be your first instinct, especially if you come from a Flux background. Try reducer composition first, and only use multiple stores if it doesn't solve your problem.

Similarly, while you can reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.

official doc by redux

In some very large enterprise apps with hundreds or thousands of reducers, it's often useful to think of different areas of the app as entirely separate apps. In those cases (where it really is multiple apps that share a domain name), I use multiple stores.

For example, I tend to treat the following common functionality areas as separate apps:

• Admin
• Analytics / data vis dashboards
• Billing management & purchase flows
• Enterprise account team/permission management

If any of those things are small, just keep them as part of the main app. If they grow very large (as some enterprise account management & analytics tools do), split them out.

The best way to manage very large apps is to treat them like a composition of many smaller apps.

If your app is less than say ~50k LOC, you should probably ignore this advice and follow Dan's advice, instead.

If your app is more than 1 Million LOC, you should probably be splitting out mini-apps, even if you maintain them in a mono repo.

This architectural decision belongs to the app developers based on their projects' needs

You are living in your own world. I am meeting with people that uses redux, because it is popular, everyday. You couldn't even imagine how much projects was started reduxing without any decisioning. I hate redux approaches but had to use it, because other developers knows nothing else. It's just an epic bubble inflated by facebook.

• It's not reliable because parts of store are not isolated.
• It's inefficient because you are cloning and traversing hash trie. When mutations grows arithmetically - complexity grows geometrically. You couldn't fix it by refactoring any reducers, selectors, etc. You have to split your trie.
• When it become slow nobody wants to split it into separate applications with separate stores. Nobody wants to spend money on refactoring. People are usually converting some smart components into dump and that's it. Do you know what future is waiting for redux developers? They will maintain these hells.
• It's not debugging friendly. It's hard to debug connections between virtually isolated parts of store. It is very hard even to analyze the amount of these connections.

Let's imagine that you have several redux stores. You will break unidirectional data flow. You will immediately realize how much connections between stores you have. You can suffer from these connections, fighting with circular deps, etc.

Single immutable store with unidirectional flow is not an elixir for every disease. If you don't want to maintain project architecture you will suffer anyway.

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.

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.

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:

• 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.

• 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.

• 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.

• 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.

• 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.