How do you persist and hydrate state?

Question

Accepted Answer

**Persisting** state means saving it to storage (localStorage, IndexedDB, a backend) so it survives page reloads or sessions; **hydrating** means loading it back into the app on startup. Common for carts, auth tokens, user preferences, and draft forms.

## Basic persist + hydrate with localStorage

```jsx
function useCart() {
  // HYDRATE: initialize from storage (lazy initializer runs once)
  const [cart, setCart] = useState(() => {
    try {
      const saved = localStorage.getItem("cart");
      return saved ? JSON.parse(saved) : [];      // parse stored JSON
    } catch {
      return [];                                   // guard against corrupt data
    }
  });

// PERSIST: write to storage whenever it changes
  useEffect(() => {
    localStorage.setItem("cart", JSON.stringify(cart));
  }, [cart]);

return [cart, setCart];
}
```

The two halves: read-and-parse on init (hydrate), and serialize-and-write on change (persist).

## Library support

```js
// Zustand persist middleware — automatic persist + hydrate
const useStore = create(persist((set) => ({ ... }), { name: "app-store" }));

// redux-persist for Redux; both handle serialization + rehydration
```

## Choosing storage

```text
localStorage  → simple, synchronous, ~5–10MB, strings only (JSON) — preferences, small state
sessionStorage→ like localStorage but cleared when the tab closes
IndexedDB     → large/structured data, async — offline apps, big caches
Cookies       → sent to server; for auth (httpOnly for security)
Backend       → cross-device sync, source of truth for important data
```

## The important caveats

```text
⚠️ SSR mismatch: localStorage doesn't exist on the server → guard with typeof window,
   and beware hydration mismatches between server-rendered and client state.
⚠️ Versioning/migration: stored shape may differ from new code → version it and migrate.
⚠️ Don't persist sensitive data (tokens) in localStorage (XSS-readable) — prefer httpOnly cookies.
⚠️ Don't persist server state you can refetch (let React Query handle caching).
⚠️ Validate/guard on hydrate — stored data can be stale or corrupt.
```

## Why it matters

Persistence delivers real UX value — carts survive reloads, preferences and drafts aren't lost, users stay logged in.

But naive implementation introduces subtle, serious issues: SSR hydration mismatches, stale/corrupt data, schema-migration breakage, and **security risks** (persisting tokens in XSS-readable storage).

Knowing the persist/hydrate pattern, choosing the right storage for the data, and respecting the caveats (guard for SSR, version the schema, don't store secrets unsafely, don't persist refetchable server state) is what makes persistence robust rather than a source of hard-to-diagnose bugs.