State Management

State management answers two questions that grow painful as a UI grows: where does this piece of state live, and who is allowed to change it. Without deliberate answers, state gets duplicated across components, drifts out of sync, and every bug becomes "who changed this, when?". The discipline is classification: server data, UI state, form state and URL state are different species with different homes.

Local component state covers most things — an open dropdown, an input value. A shared store (Redux, Zustand) earns its place for genuinely cross-cutting client state: the auth session, a shopping cart, a theme. Server data — lists, detail pages, anything fetched — belongs in a server-cache library like React Query, which owns fetching, caching, deduplication and revalidation so components just declare what they need.

URL state (filters, tabs, pagination) deserves special respect: putting it in the address bar makes views shareable and the back button honest.

Global stores trade convenience for coupling: everything can read and write everything, so data flow becomes archaeology. Context re-renders every consumer on change, which is fine for a theme and terrible for rapidly-changing data. Server-cache libraries add cache-staleness semantics you must actually configure — the defaults are opinions, not laws.

Classify first: server data → React Query/SWR; cross-cutting client state → one small store (Zustand is a few lines); everything else → useState as close to its use as possible, lifted only when two components genuinely share it. Keep state minimal and derived values computed, not stored — every stored copy is a future inconsistency.