Client State Management

“State” is not one thing. Server state needs caching, deduplication, and background sync. UI state needs fast updates and component isolation. Form state needs validation and dirty tracking. URL state needs to be shareable and SSR-able. Conflating these categories — putting API data in Redux, lifting modal flags into Zustand, or making React Hook Form responsible for filter chips — is the root cause of most “our state management is a mess” complaints. This article catalogues the categories, the tools that match them, the trade-offs that show up in production, and the patterns four well-documented engineering teams (Figma, Notion, Linear, Discord) settled on after they outgrew off-the-shelf libraries.

Abstract

Client state management reduces to one principle: match the tool to the state category.

• Server state (API data) → Use TanStack Query or SWR. These handle caching, deduplication, background refetch, and optimistic updates. Trying to manage server state with Redux or Context creates cache invalidation nightmares.
• UI state → Start with useState. Escalate to Context for cross-component sharing, Zustand for module-level state, or Jotai for fine-grained reactivity. Global state libraries are overkill for most UI state.
• Form state → Use React Hook Form for performance-critical forms (uncontrolled inputs, minimal re-renders). Built-in browser validation covers most cases.
• URL state → Store filters, pagination, and view modes in query parameters. Makes state shareable and survives refresh.
• Derived state → Compute, don’t store. Use selectors with memoization to avoid stale data and reduce state surface area.

The 2026 consensus: push server state to specialised libraries, keep global state minimal, and let URLs carry shareable state.

Mental Model: Five Buckets, One Rule

Every value the UI reads is exactly one of:

1. Server state — owned by an HTTP API or socket; cacheable, async, eventually stale.
2. UI state — owned by the component tree; synchronous, ephemeral, scoped.
3. Form state — owned by a form; needs dirty/validation/submission lifecycle.
4. URL state — owned by the browser address bar; shareable and SSR-safe.
5. Persistent state — owned by browser storage; survives reload, must be read carefully across the hydration boundary.

A sixth category — derived state — is meta: it is computed, not stored. The single rule that prevents most bugs is “match the tool to the bucket”. Conflations break in predictable ways: API arrays in Redux create cache-invalidation work that no reducer should be doing; modal flags in a global store create coupling and re-renders that no UI needs; filter chips in useState create unsharable URLs.

State Categories

Not all state is equal. Each category has distinct characteristics that dictate the right management approach.

Server State

Data fetched from APIs. Characteristics:

Why specialized tools exist: Managing server state with useState or Redux requires manually handling caching, deduplication, background refetch, cache invalidation, and optimistic updates. TanStack Query and SWR solve these problems out of the box.

UI State

Local, synchronous state for user interactions:

• Modal open/closed
• Dropdown selections
• Accordion expansion
• Animation states
• Component-specific flags

Design principle: UI state should live as close to where it’s used as possible. Lifting state to global stores creates unnecessary coupling and re-renders.

Form State

Specialized category with unique requirements:

Why form libraries exist: Native form handling with useState creates excessive re-renders (every keystroke triggers render). Libraries like React Hook Form use uncontrolled inputs to batch updates.

URL State

Query parameters and path segments that represent application state:

1/products?category=electronics&sort=price&page=2

Why URL state matters:

1. Shareable — Users can share filtered views
2. Bookmarkable — Browser back/forward works correctly
3. Server-renderable — Initial state from URL, no hydration mismatch
4. Debuggable — State visible in address bar

Persistent State

State that survives page refresh or browser close. Capacity numbers are typical caps — the Browser Constraints section below documents the exact per-engine policy and Safari’s 7-day idle eviction.

Server State Management

The Stale-While-Revalidate Pattern

SWR (the library) is named after the stale-while-revalidate HTTP Cache-Control extension defined in RFC 5861. The pattern:

1. Return cached (potentially stale) data immediately.
2. Revalidate in the background.
3. Update the UI when fresh data arrives.

Why this design: Users see instant responses while data freshness is maintained. The alternative — blocking on the network — creates perceived slowness even on fast connections. The same directive propagated into HTTP/CDN caches before client libraries adopted the name.

TanStack Query Deep Dive

As of TanStack Query v5, the core caching model uses two time-based controls — both documented in the Important Defaults page:

Critical relationship: gcTime should be ≥ staleTime. If the inactive query is garbage-collected before its staleTime would have triggered a refetch, the next mount starts cold.

The lifecycle below shows how a query moves through fresh → stale → inactive → GC, and which transitions trigger a network call.

Show 2 hidden lines3// Aggressive refetching (default): always revalidate4const defaultConfig = {5  staleTime: 0, // Data immediately stale6  gcTime: 5 * 60_000, // Keep in cache 5 minutes7}89// Conservative refetching: stable data10const stableDataConfig = {11  staleTime: 15 * 60_000, // Fresh for 15 minutesShow 8 hidden lines

When staleTime > 0 makes sense:

• User profile data (changes infrequently)
• Configuration/feature flags
• Reference data (countries, currencies)
• Data with explicit invalidation triggers

Design rationale behind staleTime: 0 default: TanStack Query chose safety over efficiency. Stale data causes bugs that are hard to trace; extra network requests are visible and debuggable.

Automatic Refetch Triggers

TanStack Query refetches stale queries on the following triggers, all defaulted on:

Production consideration: Disable refetchOnWindowFocus for data that rarely changes or where refetch is expensive:

Show 3 hidden lines4  queryKey: ["analytics", "dashboard"],5  queryFn: fetchDashboard,6  refetchOnWindowFocus: false, // Heavy query, explicit refresh only7  staleTime: 5 * 60_000,8})

Request Deduplication

TanStack Query automatically deduplicates in-flight requests:

Show 4 hidden lines5const { data } = useQuery({ queryKey: ["user", 1], queryFn: fetchUser })67// Component B (mounts at same time)8const { data } = useQuery({ queryKey: ["user", 1], queryFn: fetchUser })9// ↑ Shares the in-flight request from Component A

How it works: Query keys are serialized and compared. If a request for that key is already pending, subsequent calls wait for the same Promise.

Cache Invalidation Strategies

Invalidation marks queries as stale, triggering refetch if they’re currently rendered.

Show 3 hidden lines45// Invalidate all queries starting with 'todos'6queryClient.invalidateQueries({ queryKey: ["todos"] })78// Invalidate exact key only9queryClient.invalidateQueries({10  queryKey: ["todos", "list"],11  exact: true,12})1314// Predicate-based invalidation15queryClient.invalidateQueries({16  predicate: (query) => query.queryKey[0] === "todos" && query.state.data?.some((todo) => todo.assignee === userId),17})1819// Invalidate and refetch immediately (don't wait for render)20queryClient.invalidateQueries({21  queryKey: ["todos"],22  refetchType: "all", // Also refetch inactive queries23})

Design decision: Invalidation is separate from refetching. invalidateQueries only marks as stale—actual refetch happens when the query is rendered. Use refetchQueries for immediate network call regardless of render state.

Optimistic Updates

Update the UI immediately, roll back on error. The lifecycle is the same regardless of which library you use — the four observable steps are: snapshot, optimistic write, server round-trip, and either reconcile or roll back.

Show 5 hidden lines6  completed: boolean7}89const queryClient = useQueryClient()1011const mutation = useMutation({12  mutationFn: updateTodo,13  onMutate: async (newTodo) => {14    // Cancel outgoing refetches (they'd overwrite optimistic update)15    await queryClient.cancelQueries({ queryKey: ["todos"] })1617    // Snapshot previous value18    const previous = queryClient.getQueryData<Todo[]>(["todos"])1920    // Optimistically update21    queryClient.setQueryData<Todo[]>(["todos"], (old) => old?.map((t) => (t.id === newTodo.id ? newTodo : t)))2223    // Return snapshot for rollback24    return { previous }25  },26  onError: (err, newTodo, context) => {27    // Roll back on error28    queryClient.setQueryData(["todos"], context?.previous)29  },30  onSettled: () => {31    // Refetch to ensure server state32    queryClient.invalidateQueries({ queryKey: ["todos"] })33  },34})

Why onSettled invalidation: Even on success, the server might have modified the data (timestamps, computed fields). Invalidation ensures the cache matches server state.

React 19 useOptimistic for action-driven UI

For mutations that go through a Server Action or any async handler — not a TanStack mutation — React 19 ships useOptimistic. It expects a base state plus a reducer-like updater, and React automatically reverts the optimistic value when the surrounding action settles:

Show 3 hidden lines4  const [isPending, startTransition] = useTransition()5  const [optimisticCount, addOptimistic] = useOptimistic(count, (n: number, delta: number) => n + delta)67  return (8    <button9      disabled={isPending}10      onClick={() => {11        addOptimistic(1)12        startTransition(async () => {13          await like()14        })15      }}16    >17      {optimisticCount} likes18    </button>19  )20}

Use useOptimistic for transient UI affordances tied to a single action (a like, a vote, an inline edit) and use TanStack Query’s onMutate snapshot/rollback when the same data lives in a shared cache that other components read. The two patterns compose: a useOptimistic value can wrap a useQuery’s data while a useMutation reconciles the server state in the background.

SWR Comparison

SWR takes a more minimal approach:

When to choose SWR: simpler apps where bundle size matters, or where you prefer the smaller API surface. SWR’s mutate function covers most write paths without dedicated mutation hooks. TanStack Query wins when you need rich cache APIs (predicates, fine-grained invalidation), built-in devtools, or first-class mutation lifecycles.

Server Components, Suspense, and Hydration

React 19 finalised the Server Components model: components run only on the server, ship no JavaScript, and cannot use useState, useReducer, useEffect, useContext, or any browser API. Anything that owns client state — including every store discussed in this article — must live behind a 'use client' boundary. RSC does not eliminate client state libraries; it sharpens the boundary between what is fetched-and-rendered and what is interactive.

The Five Buckets Across the Boundary

Suspense and useSuspenseQuery

TanStack Query v5 ships dedicated Suspense hooks (useSuspenseQuery, useSuspenseQueries, useSuspenseInfiniteQuery) that integrate with <Suspense> and <ErrorBoundary>. Two consequences worth internalising:

• data is always defined when the component renders — no data?.foo ceremony, no separate loading branch.
• Errors throw to the nearest error boundary; the throwOnError option is implicit. The legacy suspense: true flag on useQuery was removed in v5.

Pair useSuspenseQuery with server-side prefetching to avoid a client waterfall:

1import { dehydrate, HydrationBoundary, QueryClient } from "@tanstack/react-query"23export default async function Page() {4  const queryClient = new QueryClient()5  await queryClient.prefetchQuery({ queryKey: ["user", 1], queryFn: fetchUser })67  return (8    <HydrationBoundary state={dehydrate(queryClient)}>9      <UserCard id={1} />10    </HydrationBoundary>11  )12}

The Page is a Server Component; UserCard is a 'use client' component that calls useSuspenseQuery({ queryKey: ["user", 1], queryFn: fetchUser }) and reads from the warm cache without a network round-trip. The advanced-SSR guide documents the streaming variant via @tanstack/react-query-next-experimental, which lets prefetches be await-free and stream as React resolves promises.

Hydration Timeline and Where It Goes Wrong

Hydration is the moment React turns server-rendered HTML into an interactive client tree. Anything the client renders must match the server-rendered HTML byte-for-byte, or React 19 logs a hydration mismatch with a diff and re-renders the affected subtree on the client.

Common state-driven causes of mismatches:

Global UI State

When Global State Is Necessary

Global state is appropriate when:

1. Multiple unrelated components need the same data
2. No common ancestor can reasonably hold the state
3. State persists across route changes

Common legitimate cases:

• Authentication state
• Theme/appearance settings
• Feature flags
• Toast/notification queue
• Modal registry

When to Avoid Global State

Server state does not belong in global stores. This was the primary mistake of early Redux applications. Patterns like “fetch in an action creator, store the array in Redux” create:

• Manual cache invalidation logic.
• No request deduplication.
• No background refetch.
• Complex loading-state management bolted on top of every reducer.

Kent C. Dodds makes the editorial argument well: most “I need a state library” instincts are really “I need to colocate state with the component that owns it, then use hooks to share it where it crosses boundaries”. The remaining cases — auth, theme, toast queues — are small, low-frequency, and a perfect fit for a single Context or a tiny external store.

React Context Limitations

Context is not optimized for frequent updates:

Show 3 hidden lines4  user: User5  theme: 'light' | 'dark'6  notifications: Notification[]7}89const AppContext = createContext<AppState | null>(null)1011function App() {12  const [state, setState] = useState<AppState>(/* ... */)1314  return (15    <AppContext.Provider value={state}>16      <Header />      {/* Re-renders when notifications change */}17      <Sidebar />     {/* Re-renders when theme changes */}18      <NotificationBell />  {/* The only component that needs notifications */}19    </AppContext.Provider>20  )21}

Problem: every consumer re-renders when any part of the provider value changes, because useContext always re-runs when the provider’s value is no longer Object.is-equal to the previous one. React.memo cannot bail out of a context update.

Solutions:

1. Split contexts — one context per concern (theme, auth, notifications).
2. Memoize values — useMemo so the provider’s value reference is stable when the underlying data hasn’t changed.
3. External stores — Zustand or Jotai with selective subscriptions.

The fan-out difference between a context provider and a selector-based external store on a single state update:

Zustand: Module-First State

Zustand is genuinely tiny — about 1.1 KB minified + gzipped for the v5 core — and provides a minimal API with selective subscriptions:

Show 2 hidden lines3interface BearStore {4  bears: number5  fish: number6  increasePopulation: () => void7  eatFish: () => void8}910const useBearStore = create<BearStore>((set) => ({11  bears: 0,12  fish: 10,13  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),14  eatFish: () => set((state) => ({ fish: state.fish - 1 })),15}))1617// Selective subscription — only re-renders when bears changes18function BearCounter() {19  const bears = useBearStore((state) => state.bears)20  return <h1>{bears} bears</h1>21}2223// Different subscription — only re-renders when fish changes24function FishCounter() {25  const fish = useBearStore((state) => state.fish)26  return <h1>{fish} fish</h1>27}

Design rationale: Zustand wraps React’s useSyncExternalStore (specifically the with-selector shim) so selectors subscribe to a specific slice, which both avoids the Context re-render problem and stays tearing-free under concurrent rendering.

Jotai: Atomic State

Jotai (bottom-up) vs Zustand (top-down):

Show 2 hidden lines3// Primitive atoms4const countAtom = atom(0)5const doubledAtom = atom((get) => get(countAtom) * 2)  // Derived67// Component only subscribes to what it reads8function Counter() {9  const [count, setCount] = useAtom(countAtom)10  return <button onClick={() => setCount(c => c + 1)}>{count}</button>11}1213// Read-only subscription (no setter in bundle)14function Display() {15  const doubled = useAtomValue(doubledAtom)16  return <span>{doubled}</span>17}1819// Write-only (no subscription, no re-render on change)20function ResetButton() {21  const setCount = useSetAtom(countAtom)22  return <button onClick={() => setCount(0)}>Reset</button>23}

When Jotai over Zustand:

• Fine-grained reactivity needed (many independent pieces)
• Derived state with complex dependency graphs
• Preference for bottom-up composition

Redux Toolkit: When Scale Demands It

Redux remains appropriate for:

• Large teams needing strict patterns
• Complex middleware requirements (sagas, thunks)
• Time-travel debugging critical
• Existing Redux investment

Modern Redux ≠ boilerplate Redux. RTK (Redux Toolkit) eliminates most ceremony:

Show 3 hidden lines4  value: number5}67const counterSlice = createSlice({8  name: "counter",9  initialState: { value: 0 } as CounterState,10  reducers: {11    increment: (state) => {12      state.value += 113    }, // Immer handles immutability14    incrementByAmount: (state, action: PayloadAction<number>) => {15      state.value += action.payload16    },17  },18})1920export const { increment, incrementByAmount } = counterSlice.actions21export default counterSlice.reducer

Decision Matrix

Form State Management

Why Form Libraries Exist

Native controlled inputs re-render on every keystroke:

Show 2 hidden lines3  const [values, setValues] = useState({ email: '', password: '' })45  return (6    <form>7      <input8        value={values.email}9        onChange={(e) => setValues(v => ({ ...v, email: e.target.value }))}10      />11      {/* Form re-renders on every keystroke */}12    </form>13  )14}

With 10+ fields and validation, this creates noticeable lag on lower-end devices.

React Hook Form

React Hook Form (about 12 KB minified + gzipped) uses uncontrolled inputs backed by refs:

Show 4 hidden lines5const schema = z.object({6  email: z.string().email(),7  password: z.string().min(8),8})910type FormData = z.infer<typeof schema>1112function LoginForm() {13  const {14    register,15    handleSubmit,16    formState: { errors, isSubmitting }17  } = useForm<FormData>({18    resolver: zodResolver(schema),19  })2021  const onSubmit = async (data: FormData) => {22    await login(data)23  }2425  return (26    <form onSubmit={handleSubmit(onSubmit)}>27      <input {...register('email')} />28      {errors.email && <span>{errors.email.message}</span>}29Show 6 hidden lines36}

Performance model: Inputs are uncontrolled (DOM holds value). Re-renders only happen when:

• formState properties you’re subscribed to change
• Explicit watch() calls
• Validation errors change

When to Use Native Forms

React Hook Form is overkill for:

• Login forms (2-3 fields)
• Search inputs
• Simple settings toggles

Native HTML validation covers basic cases:

1<input type="email" required minlength="3" pattern="[a-z]+" />

Derived State and Selectors

Compute, Don’t Store

Storing derived data creates synchronization bugs:

1// ❌ Storing derived state2interface State {3  items: Item[]4  completedItems: Item[] // Derived from items5  completedCount: number // Derived from completedItems6}78// ✅ Computing derived state9interface State {10  items: Item[]11}1213const completedItems = items.filter((i) => i.completed)14const completedCount = completedItems.length

Why computation is better:

1. Single source of truth (no sync bugs)
2. Less state to manage
3. Automatic consistency

Memoized Selectors

For expensive computations, memoize with Reselect or useMemo:

Show 3 hidden lines45const selectCompletedItems = createSelector([selectItems], (items) => items.filter((i) => i.completed))67const selectCompletedCount = createSelector([selectCompletedItems], (completed) => completed.length)89// Reselect memoizes by reference equality10// If items hasn't changed, cached result is returned

How Reselect works: input selectors run first. If their results are referentially equal (===) to the previous call, the output selector is skipped and the cached result returned².

Zustand Selectors

Show 2 hidden lines3// Component re-renders only when filtered result changes4function CompletedList() {5  const completed = useStore((state) => state.items.filter((i) => i.completed))6  // ⚠️ Creates new array every time — need memoization7}89// Better: external memoized selector10import { createSelector } from "reselect"1112const selectCompleted = createSelector(13  (state: State) => state.items,14  (items) => items.filter((i) => i.completed),15)1617function CompletedList() {18  const completed = useStore(selectCompleted) // Stable reference19}

State Machines with XState

When State Machines Are Necessary

State machines excel when:

1. States have impossible combinations — isLoading && hasError && hasData shouldn’t all be true
2. Transitions matter — Can only go from idle → loading, not idle → success
3. Complex sequences — Multi-step wizards, checkout flows
4. Parallel states — Audio playing while video loading

XState v5 Example

The setup() API makes actors, guards, and actions strongly typed against your context and events:

Show 3 hidden lines4  data: User | null5  error: Error | null6}78const fetchMachine = setup({9  types: {} as {10    context: Context11    events: { type: "FETCH"; id: string } | { type: "RETRY" }12  },13  actors: {14    fetchUser: fromPromise(async ({ input }: { input: { id: string } }) => {15      const response = await fetch(`/api/users/${input.id}`)16      if (!response.ok) throw new Error("Failed")17      return response.json()18    }),19  },20}).createMachine({21  id: "fetch",22  initial: "idle",23  context: { data: null, error: null },24  states: {25    idle: {26      on: { FETCH: "loading" },27    },28    loading: {29      invoke: {30        src: "fetchUser",31        input: ({ event }) => ({ id: event.id }),32        onDone: {33          target: "success",34          actions: assign({ data: ({ event }) => event.output }),35        },36        onError: {37          target: "failure",38          actions: assign({ error: ({ event }) => event.error }),39        },40      },41    },42    success: {43      on: { FETCH: "loading" },44    },45    failure: {46      on: { RETRY: "loading" },47    },48  },49})

The same machine drawn as a state diagram — note that success → loading and failure → loading are the only ways back into loading, which makes the impossible-state argument visual:

What XState provides:

• Type-safe transitions — TypeScript enforces valid state/event combinations.
• Visualization — export to a state diagram (the diagram above is a 1:1 mirror of the code).
• Testing — model-based testing generates traversals from the machine.
• Impossible states eliminated — you cannot be loading and failure simultaneously.

When State Machines Are Overkill

• Simple toggles (open/closed)
• Linear forms without complex validation
• CRUD operations (TanStack Query handles state)

Rule of thumb: If you can express it clearly with useState + a few conditionals, don’t add XState’s complexity.

Real-World Implementations

These examples are not endorsements of a specific library — they are evidence that state architecture is a problem you grow into. Each team picked tools that survived their specific scaling pressure.

Figma: C++/Wasm canvas + React chrome

Challenge: millions of vector objects on an infinite canvas with multiplayer editing.

Approach — documented across the Figma engineering blog:

• Editor core is C++ compiled to WebAssembly via Emscripten; the canvas renders through WebGPU (and WebGL as a fallback), bypassing the DOM entirely.
• The UI chrome (panels, menus, toolbars) is React + TypeScript, glued to the Wasm engine through a generated bindings layer.
• The document is a tree of (ObjectID, Property, Value) tuples. Figma’s multiplayer engine merges concurrent edits with a CRDT-inspired model whose conflict unit is the property-value pair.
• Server-side, each open document runs in a dedicated Rust process that brokers WebSocket updates between clients.

Key insight: at Figma’s scale, “client state” splits into a high-frequency canvas state living in C++ and a conventional React UI state living in TS. Off-the-shelf React state libraries do not touch the canvas state at all.

Notion: block-based state, sharded Postgres

Challenge: documents with tens of thousands of blocks, with real-time collaboration and granular permissions.

Approach — documented in The data model behind Notion’s flexibility:

• Every unit (a paragraph, an image, a database row, a page) is a block — a Postgres row with id, type, properties, content (ordered child IDs), and parent.
• Blocks are sharded across Postgres by workspace ID; as of Notion’s data-lake post, the production fleet runs ~96 physical Postgres instances times 5 logical shards each (~480 logical shards).
• Concurrent edits are merged with operation-based sync (transactions of block-level operations) and propagated over WebSockets.

Local update pattern:

1. User edits a block.
2. Edit is grouped into a transaction (a list of block ops).
3. Optimistic update is applied to the local block tree.
4. Transaction is sent to the server, which writes Postgres and broadcasts to other clients on the same workspace shard.

Linear: MobX-backed sync engine

Challenge: real-time project management with offline support and instant UI.

Approach — Linear’s CTO has endorsed a community reverse-engineering write-up of the architecture, and there is a public talk on scaling it:

• An in-memory object pool (issues, teams, comments — keyed by UUID) is the source of truth for the UI; MobX makes the models observable so views re-render when fields change.
• Local data is persisted to IndexedDB; the app bootstraps from disk first, then syncs deltas.
• The server pushes delta packets of SyncAction records over WebSockets, each tagged with a monotonic sync ID; clients apply them in order to the object pool and IndexedDB.
• Most fields use last-writer-wins; a few high-conflict fields (notably issue descriptions) use CRDTs.

Why MobX: observable reactivity keeps the UI in lockstep with the object graph without explicit selector wiring — the trade-off is that you opt into a specific reactivity model for the entire client.

Discord: Cassandra → ScyllaDB + Rust data services

Challenge: trillions of stored messages, spiky read/write patterns, and unpredictable hot partitions for high-traffic channels.

Architecture evolution:

1. MongoDB — initial store; scaling and operational toil pushed Discord off it early.
2. Apache Cassandra — scaled to ~177 nodes but suffered JVM GC pauses, “gossip dance” maintenance, and hot-partition latency on busy channels.
3. ScyllaDB (May 2022) — C++ rewrite of the Cassandra wire protocol with a shard-per-core model; Discord migrated trillions of messages and ended up on ~72 nodes with steady ~15 ms p99 read latency.

The state-architecture lesson sits in front of the database, not in it:

• Discord wrote a Rust data-services layer that fronts the database with consistent-hash routing and request coalescing — multiple in-flight reads for the same key dedupe into one DB query, very similar in spirit to TanStack Query’s request deduplication, just at the service tier.
• The migration itself used a custom Rust migrator that read Cassandra token ranges and double-wrote to ScyllaDB at ~3.2 M messages/second, completing in ~9 days.

The takeaway for client architecture: deduplication and coalescing are valuable at every layer, not just in the React tree. The patterns TanStack Query applies to component renders apply just as well to a service tier in front of a database.

Performance Optimization

Re-render Prevention

State Normalization

For relational data, normalize to avoid duplication:

1// ❌ Denormalized (data duplication)2interface State {3  posts: Array<{4    id: string5    author: { id: string; name: string } // Duplicated across posts6    content: string7  }>8}910// ✅ Normalized (single source of truth)11interface State {12  users: Record<string, User>13  posts: Record<string, { id: string; authorId: string; content: string }>14}

Benefits:

• O(1) lookup by ID
• Single place to update user name
• Smaller state size (no duplication)

Mobile Considerations

Mobile devices have tighter constraints:

Offline-first pattern:

1. Store critical data in IndexedDB
2. Queue mutations when offline
3. Sync when connection restored
4. Resolve conflicts (last-write-wins or merge)

Browser Constraints

Storage Quotas

Quotas are quirky and version-dependent — these are the current numbers as of 2026, with sources inline:

Practical rule: treat 5 MB of localStorage, ~50 MB of IndexedDB on the smallest device you target, and a 7-day idle-eviction window on Safari as the binding constraints — anything larger needs an explicit data-warming or re-fetch strategy.

Main Thread Budget

60fps = 16ms per frame. State updates compete with:

• Layout calculation
• Paint
• JavaScript execution
• Garbage collection

Mitigation strategies:

1. Web Workers — Heavy computation off main thread
2. requestIdleCallback — Non-critical state updates
3. Chunked updates — Split large state changes across frames

Failure Modes and Operational Implications

Each bucket fails in characteristic ways. The mitigations below are the ones worth wiring into your standards doc.

Conclusion

By 2026 the hard problems in client state are solved — the engineering challenge is selecting the right solution for each category:

1. Server state → TanStack Query / SWR. Stop managing caches manually.
2. UI state → keep it local. useState handles most cases.
3. Shared UI state → Zustand or Jotai. Reach for Redux only when you need its middleware ecosystem or strict patterns for a large team.
4. Form state → React Hook Form. Performance matters at scale; native forms are fine for two-field cases.
5. Shareable state → URL params. Users can bookmark and share, and SSR works without hydration mismatch.
6. Complex workflows → XState. When the transitions themselves are the artifact worth modelling.
7. RSC apps → push fetching server-side, prefetch into a QueryClient, hydrate through <HydrationBoundary>, render with useSuspenseQuery. Treat 'use client' as the line where every store, effect, and storage read begins.

The pattern across successful products is the same: minimise global state, specialise tools by category, push server data to purpose-built libraries — at the database tier (Discord), the document tier (Notion, Linear), or the canvas tier (Figma) — and keep the hydration boundary honest by never rendering values the server cannot produce.

Appendix

Prerequisites

• React hooks (useState, useReducer, useContext, useMemo)
• Async JavaScript (Promises, async/await)
• REST API patterns
• Basic understanding of caching concepts

Terminology

Summary

• Match tool to category: Server state needs TanStack Query/SWR, not Redux
• Server state libraries handle: Caching, deduplication, background refetch, optimistic updates
• Context re-renders all consumers: Split contexts or use external stores for frequent updates
• Zustand for modules, Jotai for atoms: Choose based on state granularity needs
• Compute derived state: Don’t store what you can calculate
• URL state is shareable state: Filters, pagination, view modes belong in query params

References

Server-state libraries:

• TanStack Query — Important Defaults — staleTime, gcTime, refetch triggers.
• TanStack Query — Migrating to v5 — cacheTime → gcTime rename and other breaking changes.
• TanStack Query — Suspense — useSuspenseQuery, error boundary contract.
• TanStack Query — Server Rendering & Hydration and Advanced Server Rendering — dehydrate / <HydrationBoundary> for SSR and RSC.
• SWR — stale-while-revalidate React data fetching.
• RFC 5861 — HTTP Cache-Control Extensions for Stale Content — origin of stale-while-revalidate.
• web.dev — Keeping things fresh with stale-while-revalidate — HTTP/CDN side of the same pattern.

UI-state libraries:

• Zustand — module-first store with selective subscriptions.
• Jotai — atomic, bottom-up state.
• Redux Toolkit — modern Redux with Immer + slices.
• React — useContext and useSyncExternalStore — the React primitives every store ultimately wraps.
• React — useOptimistic and useTransition — action-driven optimistic UI.
• React — Server Components and React 19 release notes — RSC model and hydration-mismatch reporting.

Forms, machines, and selectors:

• React Hook Form — performant form handling.
• XState v5 — setup() and machines and Actors.
• Reselect — Deriving Data with Selectors — memoised selector design.

Browser storage:

• MDN — Storage quotas and eviction criteria.
• WebKit — Updates to Storage Policy — current Safari quota model.
• web.dev — Storage for the web.
• RFC 6265 — HTTP State Management Mechanism — cookie size and lifetime.

Editorial and case studies:

• Kent C. Dodds — Application State Management with React.
• Redux — Normalizing State Shape.
• Figma — How Figma’s multiplayer technology works and Rendering Powered by WebGPU.
• Notion — The data model behind Notion’s flexibility and Building and scaling Notion’s data lake.
• Linear sync engine reverse-engineering write-up (endorsed by Linear’s CTO) and Scaling the Linear Sync Engine.
• Discord — How Discord Stores Trillions of Messages.