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 app have only one store?
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, 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)?
EDIT: feedback after converting to single-store
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:
- 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.
a few pointers
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.
EDIT 2 – helpful store tools
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.
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.
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.
