← ClaudeAtlas

frontend-statelisted

Decide where frontend state lives and how it flows, so UIs stay predictable as they grow. Use when structuring components, adding state, or untangling prop-drilling and sync bugs.
Amey-Thakur/AI-SKILLS · ★ 4 · AI & Automation · score 77
Install: claude install-skill Amey-Thakur/AI-SKILLS
# Frontend state Most frontend bugs are state bugs: two copies of one truth disagreeing. The craft is holding each piece of state in exactly one place, at the lowest level that needs it. ## Method 1. **Classify the state before placing it:** - Server state (data fetched from an API): belongs in a query cache layer with staleness rules, not copied into local variables that drift from the server. - UI state (open panel, selected tab, draft text): belongs in the component that owns the interaction, lifted only when a real second consumer appears. - Shared app state (current user, theme, active workspace): a small global store, kept small; a store that mirrors half the server is a second, worse database. - URL state (page, filters, selected item): belongs in the URL, so refresh, back, and share all work. If losing it on refresh would annoy the user, it is URL state. 2. **Derive, never duplicate.** Anything computable from existing state (counts, filtered lists, validity) is computed at render, memoized only when measured as hot. The moment a derived value is stored, it can disagree with its source. 3. **Make flows one-directional:** state flows down as props or context, changes flow up as events or actions. A child mutating a parent's data directly, or two components writing one value, is where "sometimes it doesn't update" is born. 4. **Handle the async truthfully.** Every fetch renders all three of load