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

• - [ ] 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.