When should you transfer your component’s state to a Redux store
This short article addresses the following concern: when should you add a new reducer in your Redux store to share a specific state. It assumes you know the basics about React and Redux, and are now considering whether or not you should transfer the state of a component to the store through a new reducer.
Redux in two words : shared state
Redux offers a lot, but in a nutshell, the part we are interested in is the fact that it provides a shared state that each component can tap in through a mapping to its own props. This state is the store, and it’s composed of reducers that will mutate the state depending on actions that are dispatched by components.
When should I store it
Of course, with a few React experience on big apps, having the states of all the application components extracted to a single common store seems like a bad idea (even if this common store is properly broken down into separate files). Some components (most of them probably) are sufficiently independent that their state has no benefit to be exposed in a shared store, this will on the contrary make things more complex to understand.
So the question is when do you need to share this state? My personal opinion is: when passing the state through props becomes too complex, whether because of depth (you pass the state to your grand grand grand child) or width (your use a prop and a callback to modify it so its value can be shared with siblings). A reducer is also helpful in the occasional special case where you need some external control on a component, because you are using a non-react third party library for example.
The navbar example
Let’s illustrate this with the following example : we are building a collapsible navbar.
We have an obvious Navbar component, with a state containing the boolean displayed.
The navbar itself contains a button to collapse it, so we can keep everything inside the component.
The next step is adding a button to open the navbar, it is obviously outside the component. But the button and the navbar have a common parent so we can probably put the boolean displayed and the toggle function inside this parent.
But what if the OpenNavButton is not a direct sibling of AppLayout.
Now we have several components that transmit toggleNav in their props to their children just to provide OpenNavButton access to it. And if you think about it, not only this is becoming complex, but AppLayout, AppRouter and BusinessComponent have no use of toggleNav, apart from transmitting it to their children. Working on these components for another reason than our navbar will raise a lot of questions.
This is exactly the kind of situation where it is time to make a displayNav reducer, and a toggleNav action. When you have two components or more that hold information in their props only to transmit them to their children, it’s time to put the state in the store.
Migrating progressively to Redux
This way of deciding whether or not extract a state to the store is one but many ways. However I think that it makes for a good migration strategy. If you already have a big app that is becoming more clunky by the day, you are in the same situation we were when we decided to use Redux. To make a smooth migration, we progressively extracted several states to the store by listing all the components that had unused properties they were just passing to their children. By indexing this list by property, we could then prioritise the most critical state and properties to be extracted to our Redux store. This was a very efficient way to maximize the impact of the first migration steps, which is ideal if you know you won’t have time to migrate everything but want to prevent most of the future pains related to state/props complexity.
Do you like our way of working with React? We are recruiting
