State Management in React: When to Use What

"Which state library should I use?" is the wrong first question. Ask what kind of state you have.

1. Local UI state

Open menus, form inputs and toggles belong in useState inside the component that owns them. Most state should stay here.

2. Shared UI state

When a few components need the same value, lift it to their closest parent. If it must be reached from far apart, React Context works for low-frequency values such as the current theme or signed-in user.

Context re-renders every consumer when its value changes, so avoid putting fast-changing data in it.

3. Server state

Data that lives on a server, such as lists, profiles and orders, is not really your state. It is a cache of someone else's data. Use TanStack Query (or a similar tool) to fetch, cache, dedupe and refetch it, plus loading and error states for free.

const { data, isLoading } = useQuery({
  queryKey: ['posts', page],
  queryFn: () => api.get('/posts', { page }),
});

This removes most of what people used Redux for.

4. URL state

Filters, search text, sorting and pagination belong in the URL. Pages become shareable, and the back button works.

5. Form state

Use a form library such as React Hook Form with schema validation, instead of wiring many useState calls.

6. Global client state

For genuinely global client-only state, like a shopping cart or editor settings, a small store such as Zustand is often enough. Reach for Redux Toolkit when you need strict structure, middleware or time-travel debugging across a large team.

Decision shortcut

1. Is it from the server? Use a data-fetching library.
2. Should it survive a refresh or be shared? Use the URL.
3. Only one component cares? Use useState.
4. Many distant components care? Use a small store.

Takeaway

Classify the state first. Most apps need only local state, a data-fetching library and the URL.