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.

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

State classified: remote vs UI vs URL vs derived
Single owner per truth; invalidation clear
Server cache strategy chosen for API data
Async/error/empty/optimistic paths specified
Persistence/security boundaries respected

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.