frontend-component-architecturelisted

# Frontend component architecture Two decisions determine whether a UI codebase stays workable: **where each piece of state lives**, and **where the boundaries between components fall**. Almost everything else is recoverable. ## State: pick the narrowest home that works Walk down this list and stop at the first that fits. Skipping to the bottom is the single most common cause of unmaintainable frontends. 1. **Derived** — compute it during render. If it can be calculated from props or other state, it is not state. A `useEffect` that syncs one state to another is almost always a derivation in disguise. 2. **Local** (`useState`) — one component uses it. Open/closed, input draft, hover. 3. **Lifted** — the nearest common ancestor of the components that need it. 4. **URL** — anything a user should be able to share, bookmark, or reload into: filters, tabs, pagination, selected entity. Underused; the browser gives you persistence and back-button behaviour for free. 5. **Server cache** (React Query / SWR / RSC) — anything owned by the backend. 6. **Global store** — genuinely app-wide and client-owned: session, theme, feature flags, an editor's undo stack. Rarely more than a handful of things. **Server state is not client state.** Data from an API is a cache of something you don't own: it goes stale, it needs revalidation, refetching, and per-query loading/error states. Putting it in Redux/Zustand means hand-rolling all of that. Use a server-cache library and let i