When do you actually need a state management library?

Question

IT Interview Practice · Accepted Answer

You **don't always need one**. Modern frameworks have capable built-in state tools, and reaching for Redux/Zustand prematurely adds complexity. The honest answer: add a library only when built-in options become painful.

## Start with built-in tools

```jsx
// most state needs are met by:
const [x, setX] = useState();           // local component state
const value = useContext(MyContext);    // share across a subtree
const memo = useMemo(() => derive(), [x]); // derived values
// + a server-state library (React Query) for fetched data
```

Local state + Context + (for remote data) React Query covers the vast majority of apps. Many production apps need no global state library at all.

## Signs you might genuinely need a library

```text
✓ Lots of GLOBAL state shared across many distant components
✓ Complex state interactions / frequent updates that Context handles poorly
                       (Context re-renders all consumers on any change)
✓ You need devtools, time-travel debugging, or strict update traceability
✓ Many components both read AND write the same shared state
✓ Predictable, centralized update logic matters for a large team
```

## Why not just "always use Redux"?

```text
Cost of a library: boilerplate, learning curve, more indirection, bundle size.
For a small/medium app, that cost often outweighs the benefit.
```

## Match the tool to the need

```text
Server/remote data        → React Query / SWR (NOT a global store)
A few global values        → Context, or a tiny store (Zustand/Jotai)
Large, complex shared state→ Redux Toolkit, or Zustand for less boilerplate
Form state                 → a form library (React Hook Form), not global state
```

A huge portion of "we need Redux" is actually a server-state problem solved better by React Query, or a few values solved by Context/Zustand.

## Why it matters

Knowing *when* a state library is warranted prevents the common mistake of over-engineering — adding Redux to an app that just needs `useState` and Context.

The mature approach is to start simple, identify the *specific* pain (deep sharing, complex updates, server caching), and reach for the *right* tool for that pain (often a lightweight store or a server-state library, not a heavy global one).

Choosing the minimal solution that fits keeps apps simpler, faster to build, and easier to maintain.

Start with built-in tools

Signs you might genuinely need a library

Why not just "always use Redux"?

Match the tool to the need

Why it matters

Related questions