State Management
Deciding where an app's changing data lives and who can update it, so two screens never disagree about the same fact.
See it
What it is
State is any data that changes while the app is running: the logged-in user, what's in the cart, whether the drawer is open. State management is the set of rules for where each piece lives and who is allowed to change it. The usual ladder: local state inside the one component that needs it, state lifted to a shared parent, a store for app-wide facts, and a cache for anything that came from the server.
Climb that ladder one rung at a time. Start local, move up only when a second component genuinely needs the same fact. Reach for a real tool (Redux Toolkit, Zustand, Jotai, Pinia, XState for anything with modes and transitions) when the update logic gets interesting enough that you want it in one testable place instead of smeared across handlers.
The big misconception: treating server data as state you own. Anything fetched from an API is a copy that goes stale the moment someone else edits the record, so it needs caching, refetching, and invalidation, not a slot in your store. Split client state (what this user is doing right now) from server state (what the database says) and most 'global state is a mess' problems evaporate.
Ask AI for it
Set up state management for this app with an explicit split. Keep ephemeral UI state (open/closed, hover, form drafts) local in useState inside the component that owns it. Put cross-cutting client state (theme, session, cart) in a single typed Zustand store with narrow selector hooks so components subscribe only to the fields they read. Put everything that comes from the API in TanStack Query with stable query keys, a staleTime, and invalidation on mutation, never copied into the store. Show me the store file, the query hooks, and one component that uses both.