Scaling a React app isn’t just about adding features—it’s about keeping state manageable as complexity grows. When I first built a small React app, useState felt like the perfect tool. But as the component tree got deeper and the state started depending on previous state or triggered other state updates, I realized I was spending more time wrangling state than building features. That’s when I leaned into useReducer, not just as a tool—but as a foundation for structure, predictability, and scalability.
Why scale with useReducer
At first glance, useReducer might seem like a more verbose useState, but it solves a deeper issue: managing related state transitions in a single, centralized function. I found this especially helpful in components where the state wasn’t just a single value, but a combination of flags, arrays, and booleans tied together through logic. Trying to juggle all of that with multiple useState calls became not just messy—but fragile.
With a reducer, every action has a clearly defined reaction. It brings order. You no longer have to worry if updating one piece of state will accidentally overwrite another or cause an unexpected re-render. And when debugging, all state changes are driven by a simple flow: dispatch → action → reducer → new state. That clarity becomes a lifeline in large apps.
Organizing reducers
One of the first challenges I ran into while scaling with useReducer was figuring out how to split up logic without losing track. I started modularizing reducers. If a section of the UI had specific responsibilities—like a form wizard or a shopping cart—it got its own reducer. Sometimes I even combined multiple reducers using a custom hook to mimic Redux’s combineReducers:
const combineReducers = (slices) => (state, action) =>
Object.fromEntries(
Object.entries(slices).map(([key, reducer]) => [
key,
reducer(state[key], action),
])
);
This allowed me to split logic while still managing state updates from a central place. That pattern came in handy during work on projects involving dynamic forms and configurable layouts, where different UI segments needed separate but interrelated state handling.
Defining strong action types
One of the most important steps in scaling was writing good action types. I stopped using strings like "CHANGE" or "UPDATE" and started naming actions with intent: "SET_USER", "ADD_ITEM", "CLEAR_FORM". This small change made the reducer easier to read and maintain. I could glance through the reducer and instantly understand what each block of code was supposed to handle.
In larger projects, this approach made it easier to hand off tasks to teammates or revisit my own code months later without needing to reconstruct the mental model.
Context and reducer combo
To share reducer-powered state across components, I combined it with the Context API. It’s a pattern I now default to for global state. Once I wrapped my reducer in a context provider, I could easily access the state and dispatch functions anywhere—without prop drilling.
The custom hooks I created for state and dispatch access looked like this:
export const useAppState = () => useContext(AppStateContext);
export const useAppDispatch = () => useContext(AppDispatchContext);
This setup became my go-to whenever I was building something that would scale, like quiz engines, cart systems, or component playgrounds like the one I built for Material UI + Storybook integration.
Debugging and testing
Another area where useReducer shined as the app scaled was in debugging and testing. Instead of relying on unpredictable chains of state updates, I could isolate the reducer and test its behavior:
expect(reducer({ count: 0 }, { type: 'INCREMENT' })).toEqual({ count: 1 });
This testability became especially useful when I introduced regression testing and snapshot testing later down the line. Reducers gave me the confidence that the logic would behave the same across environments.
Handling async actions
While useReducer handles sync state transitions well, scaling often means dealing with async logic like API calls or delayed operations. Initially, I tried dispatching directly inside components, but that quickly got repetitive.
So I created action creators—functions that abstract away logic before dispatching. For example:
const fetchUser = async (dispatch) => {
dispatch({ type: 'FETCH_START' });
try {
const res = await fetch('/api/user');
const data = await res.json();
dispatch({ type: 'FETCH_SUCCESS', payload: data });
} catch (err) {
dispatch({ type: 'FETCH_ERROR', error: err });
}
};
This pattern helped me clean up component logic and became even more useful in apps involving pagination, filtering, or chained API calls.
Real-world improvements
When I rebuilt my own React quiz platform—modeled after this one—I managed each quiz session through a reducer. It controlled current question, answers selected, score calculation, and navigation. Had I used useState, I would have needed multiple calls and plenty of side effects. With useReducer, each quiz action was handled predictably and traceably.
When not to use
Despite its advantages, I learned not to use useReducer for everything. If a piece of state is isolated, simple, or purely local—like toggling a modal—I stick to useState. Reducers shine when state is shared, interdependent, and driven by complex logic.
Final thoughts
Scaling a React app means thinking long-term. useReducer doesn’t just help with that—it forces it. It encourages clearer action naming, centralized logic, and testable code. Combined with context, it becomes a mini-state management system built entirely on native React tools.
As the ecosystem continues to evolve—whether with async state patterns like useActionState, or libraries like Zustand—understanding useReducer is still one of the most valuable steps in leveling up a React codebase. It gives you a structure that scales, and when things get complex, structure is everything.
