Web State Management
Purpose
Classify every significant piece of state into the layer that owns it — local, form, shared client, server cache, URL, or persisted — and only then decide whether a shared-state library is needed at all. Prevents the everything-in-Redux failure mode.
When to Use
- After the foundation skill, before data-heavy feature work.
- When an existing app shows state sprawl (server data in a global store, filters lost on refresh).
- Not for server-data mechanics (
web-server-state) or form internals (web-forms).
Inputs
- Feature/page inventory and what each screen displays or edits.
- Framework foundation (server components shift some state server-side).
- Auth/session state expectations (
web-authentication).
Discovery Questions
- For each piece of state: who reads it, who writes it, does it survive refresh, is it shareable via link?
- What is genuinely shared client state (theme, session presence, layout prefs) vs data one page fetches?
- Which list views need URL-carried filters/pagination/sort?
- Is anything left that actually requires a store library — and how much?
Responsibilities
- Classify state into: local (component), form (
web-forms), shared client, server cache (web-server-state), URL (web-routing), persisted (localStorage/cookies — mind security for anything auth-adjacent, web-authentication).
- Route each category to its owning mechanism; keep categories from leaking into each other.
- If shared client state remains, evaluate the mechanism (Context for low-churn, Zustand/Redux Toolkit for richer needs) with justification.
- Define persistence rules: what survives refresh, what must not (secrets, volatile UI state).
Required Workflow
- Inventory state per feature/page.
- Classify each item into exactly one category.
- Confirm server data goes to the server-state layer and shareable view state to the URL.
- Size the residual shared-client-state need; select a mechanism only if justified.
- Record the map; hand category detail to the owning skills.
Decision Rules
- Server data is never "app state" — it's a cache owned by
web-server-state.
- Anything a user would bookmark, share, or expect back/forward to respect → URL.
- Start local; lift state only when a second consumer actually exists.
- Context is fine for rarely-changing values; high-frequency updates through Context are a re-render trap.
- No store library enters the project without a category of state that demonstrably needs it.
Rules
- One owner per state item; duplicating the same fact in two layers requires a sync story or a redesign.
- Persisted state gets versioning/migration thought before shipping.
- No tokens/secrets in localStorage by default (
web-authentication owns that decision).
Anti-Patterns
- Mirroring API responses into Redux/Zustand "so it's available."
- Filters and pagination in memory only — lost on refresh, unshareable.
- Global store as the first resort for what one component owns.
- Two sources of truth for the same value (URL + store) drifting apart.
Validation Checklist
Definition of Done
A recorded state map assigning every significant value to exactly one owning layer, with the shared-client mechanism (if any) justified — ready for web-server-state, web-forms, and web-routing to implement their parts.
Related Skills
web-server-state, web-forms, web-routing, web-authentication, vite-react-foundation, nextjs-foundation, ../../stack-recommendation.
Related Knowledge
../../../knowledge/ (domain model, session model).
Related References
../../../references/web/state/ (when populated).
Context Loading Guidance
- Requires: feature/page inventory, framework foundation.
- Does not require: API schemas in full, component internals.
- May load:
web-server-state next; web-forms for form-heavy flows.
- Stop when: the state map and mechanism decision are recorded.
Token Efficiency Guidance
Work from the state inventory table, not screen-by-screen prose. One line per state item: name → category → owner.
1---2name: web-state-management3description: Use to decide where each piece of web app state lives — local component, form, shared client, server cache, URL, or persisted — before picking any state library. URL state is first-class on the web; server data belongs to the server-state layer, not a global store.4---56# Web State Management78## Purpose910Classify every significant piece of state into the layer that owns it — local, form, shared client, server cache, **URL**, or persisted — and only then decide whether a shared-state library is needed at all. Prevents the everything-in-Redux failure mode.1112## When to Use1314- After the foundation skill, before data-heavy feature work.15- When an existing app shows state sprawl (server data in a global store, filters lost on refresh).16- **Not** for server-data mechanics (`web-server-state`) or form internals (`web-forms`).1718## Inputs1920- Feature/page inventory and what each screen displays or edits.21- Framework foundation (server components shift some state server-side).22- Auth/session state expectations (`web-authentication`).2324## Discovery Questions2526- For each piece of state: who reads it, who writes it, does it survive refresh, is it shareable via link?27- What is genuinely **shared client state** (theme, session presence, layout prefs) vs data one page fetches?28- Which list views need URL-carried filters/pagination/sort?29- Is anything left that actually requires a store library — and how much?3031## Responsibilities3233- Classify state into: **local** (component), **form** (`web-forms`), **shared client**, **server cache** (`web-server-state`), **URL** (`web-routing`), **persisted** (localStorage/cookies — mind security for anything auth-adjacent, `web-authentication`).34- Route each category to its owning mechanism; keep categories from leaking into each other.35- If shared client state remains, **evaluate** the mechanism (Context for low-churn, Zustand/Redux Toolkit for richer needs) with justification.36- Define persistence rules: what survives refresh, what must not (secrets, volatile UI state).3738## Required Workflow39401. Inventory state per feature/page.412. Classify each item into exactly one category.423. Confirm server data goes to the server-state layer and shareable view state to the URL.434. Size the residual shared-client-state need; select a mechanism only if justified.445. Record the map; hand category detail to the owning skills.4546## Decision Rules4748- **Server data is never "app state"** — it's a cache owned by `web-server-state`.49- Anything a user would bookmark, share, or expect back/forward to respect → URL.50- Start local; lift state only when a second consumer actually exists.51- Context is fine for rarely-changing values; high-frequency updates through Context are a re-render trap.52- No store library enters the project without a category of state that demonstrably needs it.5354## Rules5556- One owner per state item; duplicating the same fact in two layers requires a sync story or a redesign.57- Persisted state gets versioning/migration thought before shipping.58- No tokens/secrets in localStorage by default (`web-authentication` owns that decision).5960## Anti-Patterns6162- Mirroring API responses into Redux/Zustand "so it's available."63- Filters and pagination in memory only — lost on refresh, unshareable.64- Global store as the first resort for what one component owns.65- Two sources of truth for the same value (URL + store) drifting apart.6667## Validation Checklist6869- [ ] State inventory classified into the six categories.70- [ ] Server data assigned to the server-state layer, not a client store.71- [ ] URL-state decisions recorded per list/filter view.72- [ ] Shared-client mechanism chosen only for demonstrated need, with justification.73- [ ] Persistence + security rules noted for persisted items.7475## Definition of Done7677A recorded state map assigning every significant value to exactly one owning layer, with the shared-client mechanism (if any) justified — ready for `web-server-state`, `web-forms`, and `web-routing` to implement their parts.7879## Related Skills8081`web-server-state`, `web-forms`, `web-routing`, `web-authentication`, `vite-react-foundation`, `nextjs-foundation`, `../../stack-recommendation`.8283## Related Knowledge8485`../../../knowledge/` (domain model, session model).8687## Related References8889`../../../references/web/state/` (when populated).9091## Context Loading Guidance9293- **Requires:** feature/page inventory, framework foundation.94- **Does not require:** API schemas in full, component internals.95- **May load:** `web-server-state` next; `web-forms` for form-heavy flows.96- **Stop when:** the state map and mechanism decision are recorded.9798## Token Efficiency Guidance99100Work from the state inventory table, not screen-by-screen prose. One line per state item: name → category → owner.
ahtishamshahzad