State Management (Deep Workflow)
Most “state bugs” are ownership and lifecycle bugs: who writes, when it syncs, and what happens on failure. Guide users to explicit models instead of ad-hoc globals.
When to Offer This Workflow
Trigger conditions:
- Prop drilling pain, inconsistent UI, duplicate sources of truth
- Stale data after mutations; optimistic UI gone wrong
- Choosing a library vs Context vs server-state library (React Query, SWR, Apollo)
- SSR/hydration + client state mismatches
Initial offer:
Use six stages: (1) inventory state kinds, (2) assign ownership, (3) server vs client boundaries, (4) async & updates, (5) persistence & URLs, (6) testing & DevTools. Confirm framework and data fetching approach.
Stage 1: Inventory State Kinds
Goal: Classify what state exists before picking tools.
Categories
- Remote/server state: API responses, pagination, staleness—often not Redux-shaped
- URL state: filters, tabs, selection when shareable/bookmarkable
- Session UI state: modals, toggles, transient form drafts
- Client-derived: sorted/filtered views of remote data—avoid storing both raw and derived as writable truths
- Global cross-cutting: auth user, theme, feature flags—with clear read-only vs mutable rules
Exit condition: Table of state slices → source of truth → consumers.
Stage 2: Assign Ownership
Goal: One writer per piece of truth (or strict reducer pattern).
Rules of Thumb
- Colocate state where it’s used if not shared—don’t globalize prematurely
- Lift only when multiple subtrees need it or prop chains hurt and ownership is clear
- Avoid copying server entities into multiple stores without sync rules
Exit condition: For each slice: who sets, who reads, invalidation story.
Stage 3: Server vs Client Boundaries
Goal: Prefer server-state libraries for remote data; use client stores for true client concerns.
Guidance
- React Query / SWR / RTK Query: caching, dedupe, refetch, background refresh—use for HTTP JSON
- GraphQL clients: normalized cache + mutations with update policies
- Redux: great for predictable global client state + middleware—not every fetch response
Anti-patterns
- Storing full API JSON in Redux without normalization when Apollo/Query would fit
- Double fetch: SSR then client refetch without coordination—use hydration patterns
Exit condition: Remote data has defined cache keys, stale time, and mutation flow.
Stage 4: Async & Consistency
Goal: Loading, error, empty, and retry are first-class; optimistic updates are safe or scoped.
Practices
- Optimistic UI: rollback path; idempotent mutations; server reconciliation
- Ordering: serial vs parallel requests; race cancellation (AbortController)
- Pagination/infinite scroll: cursor stability; dedupe pages
Concurrency
- Last write wins awareness; versioning or ETags if server supports
Exit condition: User-visible failure modes handled; no silent stale success.
Stage 5: Persistence & URL
Goal: Decide what survives refresh, what is shareable, and security.
Options
- URL query for filters/tabs when users share links
- localStorage/sessionStorage for drafts—mind XSS risk (sensitive data → not localStorage)
- IndexedDB for offline—complexity tax
Exit condition: Sensitive data never persisted client-side inappropriately.
Stage 6: Testing & DevTools
Goal: State logic is unit-testable; time-travel/debug when needed.
Practices
- Pure reducers / small hooks for rules
- Integration tests for critical flows with MSW or mock server
- DevTools: Redux/Query panels—ensure team knows how to inspect cache
Final Review Checklist
Tips for Effective Guidance
- Start minimal: Context + server-state library solves many “Redux-sized” problems.
- Always ask: “What is the source of truth after mutation returns?”
- Mention React Strict Mode double-invoke when debugging weird effect behavior.
Handling Deviations
- Legacy Redux everywhere: incremental migration—feature modules first, remote data to Query next.
- Non-React: map patterns to signals/stores (Vue Pinia, Svelte stores) with same ownership discipline.
