State management

Managing state well is the backbone of a solid React app. It’s easy to over-complicate things or lean on the wrong tool for the job. Done well, it keeps your app predictable and maintainable. Done poorly, it can quickly become a source of bugs, performance issues, and developer frustration. This section covers some common-sense guidelines to help you decide what kind of state to use, and how to keep it manageable as your app grows.

While React gives us some great built-in tools, there’s often a debate around when to use external libraries like Redux or Zustand vs just sticking to useState, useReducer, and Context.

Why state management libraries like Redux were introduced

Back when React was still growing, managing shared state across large applications was a challenge because prop drilling (passing data through many layers of components) was painful, and complex UIs needed predictable, centralized state that could be debugged and controlled. This is where libraries like Redux came in. Redux helped us:

• Maintain a single source of truth for global state.
• Control how state changes in a predictable, testable way. (via actions and reducers)
• Enable time-travel debugging and better developer tooling. (Redux DevTools)
• Avoid deeply nested props and complicated data flow.

This way, libraries like Redux solved the problems by centralizing state and enforcing strict rules for how it can be updated.

When to use React’s built-in tools? 

For small to medium projects or or well-isolated pieces of UI, React’s built-in state management is often enough:

• useState: Best for local, simple state (form inputs, toggles, counters).
• useReducer: Great for more complex local logic (multi-step forms, component-level workflows).
• Context: Useful for sharing state across multiple components (themes, authentication, settings).

Limits to keep in mind

It’s important to know their limits.

• Context Performance Issues: In our React projects, we’ve observed that using Context for state that updates frequently can lead to performance issues due to unnecessary re-renders. When a context value changes, all components consuming that context re-render, regardless of whether they depend on the changed part of the context. You may consider using the use-context-selector package which was created to mitigate this.
  • Use context selector will only re-render if the part of the context that the component is using has been changed.
  • useContextSelector also accepts an equality function as the second argument, which can be configured to check deep equality instead of the default shallow equality.
• Reducer Complexity: useReducer can get clunky if the app grows and many components need access to the same reducer or state. So instead of maintaining a single, large reducer, consider breaking down your state management into smaller, more focused reducers. This modular approach can make your state logic more manageable and your application easier to scale.

When to consider external libraries?

Start with React’s tools, but as your application grows, evaluate whether a dedicated state management solution is needed.

Consider a library if:

• You need to share frequently updated state across many parts of the app.
• State transitions become complex and harder to trace.
• You need advanced dev tooling (Redux DevTools, time-travel debugging).

You’re building features like offline caching, optimistic updates, or undo/redo. Common Libraries.

• Redux Toolkit: The modern, simplified way to use Redux. Great for large, complex apps.
• Zustand: Minimalistic, simple, and performant for medium-to-large apps.

Practical guidelines

• Start simple: React’s built-in tools are powerful and often enough.
• Add libraries only when needed: Not every app needs an external state management library.
• Think about scale and complexity: If your app is growing, a well-chosen library like Redux or Zustand can help maintain sanity.

  ┌──────────────-
               │ Do you only need local |
               │ component state?       |
               └──────────────┘
                              │
                              ▼
                    Yes ───► useState
                              │
                   No ─────┘
                              │
                              ▼
          ┌──────────────────────┐
          │ Do you need to share state across   │
          │ a few components?                   │
          └──────────────┬───────┘
                         │
                         ▼
              Yes ───► useContext (or useReducer + Context)
                         │
             No ─────┘
                         │
                         ▼
     ┌───────────────────────────┐
     │ Is the state frequently updated or complex, │
     │ causing performance issues?                 │
     └──────────────┬────────────┘
                    │
                    ▼
        Yes ───► Zustand
                    │
        No ─────┘
                    │
                    ▼
     ┌───────────────────────────┐
     │ Do you need advanced debugging, time-travel │
     │ or very large app-scale global state?       │
     └──────────────┬────────────┘
                    │
                    ▼
            Yes ───► Redux Toolkit
            No ────► Stick with Context + Reducers