Win a copy of Mastering Corda: Blockchain for Java Developers this week in the Cloud/Virtualization forum!

Will Faurot

Author
+ Follow
since Jul 01, 2018
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Will Faurot

Hey DJ, I had the same question when I was picking up Redux, and here is a great set of answers I found at the time which are still relevant now (https://stackoverflow.com/questions/33619775/redux-multiple-stores-why-not / on Stack Overflow here). That SO post aligns closely with my thinking so I'll do my best to paraphrase here. It's worth noting that this post is from 2015, which makes it ancient by programming standards, but it's still relevant as it covers more high-level Redux design concepts as opposed to anything related to specific implementations.

I've personally never worked on a Redux app that required more than one store, but that's not to say it's never a good idea (like many things, in programming there are no absolutes ). Performance is an oft-cited reason to potentially use more than one store, e.g. if you have lists that contain thousands items that change often. Running each reducer on every change with that much data could theoretically be expensive enough to have a noticeable impact on performance, and splitting out stores means you can isolate the expensive bits from the rest of the app. But it's an edge case that the vast majority of apps won't have to deal with.

For me, using multiple Redux stores in a single app boils down to "You aren't gonna need it". I originally moved to Redux after using Reflux, an early implementation of the Flux pattern that normally involved multiple stores. Initially this seemed like a great way to decouple data, and components can be selective about which stores they listen to which can cut down on waste. What happened in practice was I'd inevitably develop dependencies between stores, which meant a huge amount of complexity. Some stores would need to wait for others to update ("dependent updates"), and if a component listened to multiple stores there was no guarantee that listeners only fired after all updates were complete which occasionally resulted in UI jank. These were all painful yet ultimately solvable problems, but when Redux came along it proved there was a better way.

Redux primarily being used with a single store is such a huge reduction in complexity compared to previous Flux-like solutions that I'm hard-pressed to find many use cases that would justify a break from the single store model. Most problems that could be solved with multiple stores could just as easily be solved with Reducer composition.