useReducer and local side effects

“How many state items do I need before I should use useReducer instead of multiple useStates?” If you’re like me, this might be a question you often ask yourself while working on local state for your React components. Upon reflection, I believe this way of thinking lacks adequate nuance.

To frame things first, we need to clarify the purpose of a reducer.

For a long time, I fundamentally understood actions and reducers as complicated setters. I was wrong. The redux website tells us that we shouldn’t think of actions as merely setters, but as events. In this way, reducers interpret actions from events which involves both logic and potentially updating multiple state values.

So to say that again in different terms. Thinking in terms of interpretation of events means:

1. Our reducers should often have logic in them.
2. Our reducers may update multiple state items for one action.

So what does this mean for our useReducer hook? It means that we now have a way of managing local state that utilizes the reducer pattern where the logic that updates state lives in the reducer, not the body of the component. Organizationally, the logic impacting state updates is now clearly tied to the state update itself in the reducer.

(By the way, this means that we can import testable functions that keep our reducers easy to read. When we add functions to the body of our component, we lose the ability to test the function in isolation with unit tests, so this is a win itself.)

Here’s a contrived example with counter (IRL, state this simple would be with useState). But the benefit with my reducer is not only that I’m avoiding multiple useStates for components with a lot of state, but also that I can organize the state update logic to exist in the reducer which is the more important benefit.