State Architecture: Local, Shared, Server, URL

Half of state-management pain disappears when you classify state correctly. There are four kinds, and they want different tools.

The four kinds

1. UI state — "is this dropdown open," "current form field." Lives in useState/useReducer at the lowest component that can own it. Never travels.
2. Shared client state — theme, locale, "current workspace." Genuinely global, rarely changing → context, or a small store (zustand, jotai) when updates fan out.
3. Server state — data owned by the backend: users, posts, inventory. Not yours — cached. Belongs in react-query/SWR, never in Redux. The lib handles staleness, dedupe, refetch-on-focus.
4. URL state — filters, pagination, selected tab, search query. Put it in the query string and shareable links, deep-linking, and back-button behavior come free. useSearchParams or your router's equivalent.

The most common architectural bug is putting #3 in a global store and then writing invalidation logic by hand — re-implementing react-query badly.

When you do need a store

• Multiple distant components mutate the same thing (a canvas, a draft document, a playlist).
• Updates are frequent and consumers are selective (a store with selectors re-renders only what changed).
• Event sourcing-ish flows — undo stacks, command patterns.

// zustand: a store is a hook
const useCart = create(set => ({
  items: [],
  add: (item) => set(s => ({ items: [...s.items, item] })),
}));
const items = useCart(s => s.items);   // selector — re-renders only when items change

Field notes

• State that must survive reload goes in localStorage (preferences) or the URL (shareable state) — decide which before building the feature.
• "Derived state" belongs in render or useMemo, never in a store.
• Measure before architecting: if the tree is shallow, props are fine; if it's deep but writes are rare, context is fine; a store is for the narrow middle.