State management is one of those topics that generates way more debate than it probably deserves. Every few months there’s a new library promising to solve all your state problems, and the React community argues about it for weeks. I’ve been through enough of these cycles to have opinions.

The short version: for most applications, you need three types of state management, and trying to use one solution for everything causes more problems than it solves.

Server state is different from client state. This took me way too long to internalize. When I was learning React, the default pattern was to fetch data in useEffect, stick it in component state or Redux, and then read from that state everywhere. This is backwards.

Server state - data that lives on your backend - should be managed by something that understands server state. That means caching, revalidation, optimistic updates, error handling, all the stuff that comes with fetching and syncing data.

React Query or SWR handle this way better than Redux or Context ever could. They’re specialized tools for a specific problem. Once I started using React Query for all my server state, probably 70% of my state management complexity disappeared.

Client state - stuff that only exists in the browser - is what you actually need state management libraries for. But not all client state is the same, and this is where people get into trouble.

Form state is its own category. Don’t manage it with your global state library. Use React Hook Form or Formik or just controlled components if the form is simple. Forms have their own patterns - validation, submission, error handling - and generic state management doesn’t handle these well.

URL state is underused. A lot of stuff that people stick in Redux or Context should actually be in the URL. Filters, sort order, selected tabs, pagination - if it’s something the user might want to bookmark or share, it belongs in the URL. Use search params, don’t fight them.

That leaves actual global client state - theme settings, user preferences, UI state that needs to be shared across components, that kind of thing. This is where you might use Redux or Zustand or Context or one of the newer signal-based libraries.

Which one? Honestly, it matters less than people think. I’ve been using Zustand for the past year because the API is simple and the bundle size is small. Redux still works fine if you’re already using it. The new Context API in React 19 is good enough for simple cases. Signals are interesting but I haven’t needed them yet.

The important thing is picking one pattern and being consistent. Having some state in Redux, some in Context, some in component state, and some in URL params is fine if there’s a clear pattern for what goes where. It’s bad if it’s random.

Here’s my current pattern for new projects:

Server state goes in React Query. Every API call returns a query that handles caching, background refetching, and error states. No data from the server ever touches any other state management system.

URL state goes in search params. I use a small utility function that wraps URLSearchParams and makes it feel like state. Filter controls, pagination, sort order - all of it in the URL.

Form state uses React Hook Form if it’s complex, controlled components if it’s simple. Never global state management for forms.

Shared UI state goes in Zustand. Theme, sidebar open/closed, notification queue, anything that multiple components need to read or update. This is usually a small amount of state - maybe 5-10 values total.

Component state stays in useState for everything else. If only one component and its children need it, it doesn’t need to be global.

This pattern covers maybe 95% of my state management needs. The other 5% is weird edge cases where I might use a different pattern, but having the default pattern means I’m not making state management decisions on every component.

The signal-based libraries like Jotai or Recoil are interesting because they solve some React re-render optimization problems automatically. But I haven’t hit those problems enough to justify learning a new paradigm. Maybe on a really complex app it would matter.

Redux Toolkit made Redux much better than classic Redux. If you’re still writing action creators and switch statements in reducers, you’re doing it wrong. RTK simplifies a lot of the boilerplate. But I still think Redux is overkill for most apps now that React Query exists.

Server state was always the main thing people used Redux for, and they shouldn’t have. Redux is designed for deterministic client state management. Async data fetching with caching and revalidation is not what it’s good at.

The Context API in React 19 with the use hook is actually pretty good now. For simple state sharing, you don’t need a library. Just wrap part of your tree in a Context provider and consume it with use. This is fine for theme, user data, stuff that doesn’t change often.

Where Context falls down is performance. If you have frequently updating state in Context, every component using that context re-renders on every update. Zustand and Redux handle this better with selectors. But if your state isn’t updating frequently, it doesn’t matter.

Performance is overrated in state management discussions anyway. Unless you’re rendering thousands of components or updating state dozens of times per second, the performance difference between solutions is negligible. Developer experience matters more.

I see a lot of junior developers cargo-culting complex state management patterns because that’s what they see in tutorials or example apps. You don’t need Redux for a todo app. You don’t need Zustand for a form with three inputs. useState is fine.

The best state management is the simplest solution that solves your actual problems. Don’t add complexity because you think you might need it later. Add it when you actually need it.

One thing I’ve learned: collocate state as close to where it’s used as possible. If only one component needs it, put it in that component. If a component and its children need it, put it in the parent and pass it down. Only make it global if multiple unrelated parts of the app need it.

This principle applies to server state too. Don’t fetch data at the app root and pass it down through 10 levels of components. Fetch it in the component that needs it. React Query handles caching, so you’re not making duplicate requests.

The hardest state management problems are usually about coordinating updates across different sources of truth. When you have the same data in the URL, in a form, in a query cache, and in component state, keeping them all in sync is painful.

The solution is to have one source of truth. For server data, that’s the query cache. For UI state that needs to be bookmarkable, it’s the URL. For everything else, pick the most appropriate place and don’t duplicate it.

I’ve debugged so many state bugs that came down to having the same state in multiple places that got out of sync. Delete one copy of the state, problem solved.

Looking ahead, I think the React team’s work on server components and server actions is going to change state management patterns again. If data fetching happens on the server and you’re mostly just rendering that data, you need less client-side state management.

But we’re not there yet for most apps. Server components are still new, and a lot of applications have interactive features that need client state. So the patterns I described above should be relevant for at least another year or two.

The state management landscape will keep churning out new libraries and new patterns. Most of them solve problems that most developers don’t have. Stick with boring, proven solutions until you actually hit their limitations. Then carefully evaluate if you need something different.

Your users don’t care what state management library you use. They care if the app is fast and works correctly. Choose solutions that help you build fast, correct apps with minimal complexity. Everything else is just developer fashion.