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.