• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
  • Himai Minh
  • Carey Brown
  • salvin francis

Redux in Action: using multiple stores

Ranch Hand
Posts: 218
VI Editor Ruby Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Almost all the examples and tutorials on Redux are implying a single store, but it seems it is possible to create multiple stores with Redux.

Is there a benefit for creating multiple stores? When should you use single or multiple stores?

Posts: 67478
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've always used a single store and partitioned it using combineReducers().

But I have yet to use Redux on a truly large-scale project, so I too am interested to hear the answer from the author. I can't think of any reason I have come across so far to use multiple stores.
Posts: 1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Normally trees don't drive trucks. Does this tiny ad have a license?
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic