Where should application state live ?
This part focuses on the way to manage state in React when using the Flux pattern. It focuses on one question you must already have encountered : "Should I put this piece of state inside of my component, or make it available globally in a state store ?". Note that we have chosen to make this part as independent from the Flux implementation as possible, and to discuss about the patterns we implemented when working with Redux in the next part.
As the development of your app went along, our state store became more and more complicated, to the point it became easier to add new parts to it instead of re-using the data already stored in it. We then decided to rethink the way our state was managed, and to try and put more state data inside of our components, and less in our state store. The following article
Questions instead of an absolute answer
It's impossible to give an absolute answer to this question. However, we thought of a few question you may ask yourself to make a better decision. Let's also keep in mind that after that decision has been made, it is always possible to change it without too much hassle. However, it might require a bit of time, due to the tight bond between the state and the presentation layer that React introduces. To help with this kind of refactors, typing your state with Flow might help a lot, along with using a few of the patterns described in the next part.
Is my state made of business data or interface state ?
What we call "interface state" here is the part of state that mostly derives from interaction with the user, keeping track whether a modal is opened, a menu is collapsed, a search filter is enabled... In the other hand, business data is "pure" data, that is (most of the time) fetched from your back-end, and often normalized and quite raw.
What we can assert is that business data should be stored in the state store. This makes it available from anywhere in your app by connecting any components to the state store, and allows to keep business data in its simplest form, with as few redundancies as possible.
Interface state, on the other hand, is harder to deal with. Sometimes, you will need other components to be aware of the state of a component, and sometimes, that state can be internal to said component. In the process of "lifting state up" to make other parts of your app aware of the state, you will sometimes find out that a part of state would need to be at the top of your components tree to make others component aware of it. This is often a good sign that such state should be in the state store.
Should this part of state persist after the component is unmounted ?
One typical use case we encountered with this question was in developing an edition component. The component took
the current data and a onSave handler as props. It contained a Save button, which, when clicked, called the onSave
prop, passing it the edited data. At first, we use our state store to store the edited data, but we realised that this
was quite useless, and it added unneeded complexity to our state store. We rewrote this component so that it would
contain the edited data inside its own state, because we did not need this data to be available anywhere else in
the components tree, and we did not need it to persist after the edition component was unmounted.
Where should I put this piece of data inside my state store ?
This question is rather hard to reply without being too implementation-specific, so we suggest you to go on to the next part, where we will discuss it, along with other Redux implementation patterns.
Useful resources
When thinking about this problem, and when writing this article, we found several resources to be quite useful for our reflection. If you want to go further, you might be interested in looking at them :