frontend-state-architecturelisted

# frontend-state-architecture Most frontend messes are state messes: server data copied into `useState` and going stale, everything crammed into one global store, or filters kept in component state so they vanish on refresh and can't be shared by URL. The fix is almost never a different library — it's putting each kind of state in the place that owns it. This skill is that decision. ## The categories (put each piece in exactly one) | Kind of state | Lives in | Examples | Owned by | | --- | --- | --- | --- | | **Server cache** | a data-fetching cache (React Query / SWR / RTK Query / Apollo) | the user list, a profile, anything from an API | the server; the client only caches it | | **URL state** | the URL (query params / route) | current tab, filters, sort, pagination, search query, selected id | the address bar | | **Form state** | a form library or local state | field values, validation, dirty/touched | the form, until submit | | **Client/UI state** | local `useState` → lift only as needed | modal open, hover, wizard step, optimistic toggles | the component(s) using it | | **Global client state** | a small global store (Zustand/Redux/context) | auth session, theme, feature flags, cross-tree UI | the app shell | The single most common mistake: **treating server data as client state.** It isn't yours — it's a cache of someone else's data. Put it in a cache library that handles staleness, refetch, dedup, and invalidation. Copying it into `useState` means you now own cache in