state-architecturelisted

# state-architecture Use when adding any state to a React app. The wrong location is the most common architectural drift: state ends up too high (every input re-renders the page), too low (sibling components can't communicate), or in a global store when URL would have sufficed. ## The decision tree (top → bottom; use the highest that works) ``` 1. Can it live in the URL? → URL search params or path segment 2. Can the server own it? → DB / cache, render via Server Component 3. Is it ONE component's concern? → useState in that component 4. Is it ≤ 3 sibling components? → lift to closest common parent 5. Is it cross-tree client-only? → Zustand (or Jotai for atoms) 6. Is it server data with caching? → React Query (TanStack) / SWR ``` Default to (1) or (2). Reach for (5) last. Context is mentioned below but rarely the right answer. ## (1) URL state — the most under-used State that should survive a refresh, be shareable, or be back-button-friendly belongs in the URL: - Filters, sorts, pagination, tabs - "Which item is selected" in a list/detail layout - Modal open/closed when the modal is shareable (`?invite=true`) - Search queries ```tsx // Server Component reading searchParams export default function Page({ searchParams }: { searchParams: { sort?: string } }) { const sort = searchParams.sort ?? 'newest'; return <ItemList sort={sort} />; } // Client Component pushing to URL 'use client'; import { useRouter, useSearchParams