State Management Skill

Decision framework: classify the state before picking a tool

1. Server state (data that lives in a database, fetched over the network — products, user profile, orders): use TanStack Query (React Query) or SWR, or in Next.js, Server Components + Server Actions with revalidatePath/revalidateTag. Never mirror server data into a global client store (Redux/Zustand) — you'll fight cache invalidation forever.
2. URL state (filters, pagination, selected tab, search query — anything that should survive a refresh/be shareable/bookmarkable): keep it in the URL (useSearchParams/nuqs), not component state.
3. Global client-only state (theme, sidebar open/closed, multi-step wizard progress not tied to a URL, cart contents before checkout): Zustand for anything beyond trivial — lighter and less boilerplate than Redux for most app sizes; React Context only for low-frequency-update, small-scope state (e.g. auth user object, theme) since Context re-renders all consumers on every change.
4. Local component state: plain useState/useReducer — the default, don't reach for global state until 2+ unrelated components genuinely need the same value.

When Redux Toolkit is still the right call

Large teams with complex, deeply interdependent client state, time-travel debugging needs, or an existing Redux codebase. For most new MERN/Next.js projects in 2026, Zustand + React Query covers the same ground with far less boilerplate — default to that combination unless there's a specific reason for Redux.