Step 12 — Separate server state, UI state, and local data

Before choosing a state library, identify who owns each value and how long it lives. Copying one value into the URL, React state, a global store, and a cache creates several competing sources of truth.

Split state into four kinds

Do not copy a server-backed list into Zustand. Let TanStack Query keys express API resource boundaries, then invalidate only affected keys after a successful mutation. Use Zustand for small UI state shared across views, with selectors that avoid unrelated renders.

IndexedDB is a database, not a magic cache

IndexedDB needs versions and migrations. Record size, expiry, and schema version when writing, then validate again when reading. The online API must remain a fallback when the browser reclaims storage or an upgrade fails. Never keep the only copy of user-owned data in IndexedDB.

Read boundary

1

URL → query key → API response → interface

2

IndexedDB hit → validate version and expiry → interface

3

Validation failure → discard cache → API fallback

Completion evidence

• One business value is not owned by several stores.
• Query keys include user, filter, and page boundaries.
• The interface opens after migration, quota, or storage-access failure.
• Offline state and resynchronization are understandable to the user.

Related terms: Zustand, TanStack Query, IndexedDB

• Previous step
• Back to the course