Redux - multiple stores, why not?

Question

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

Why is it so strongly suggested that a Redux a

Answer 1

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.