Hoe persistent en hydrateer je state?

Question

Accepted Answer

**Persisteren** van state betekent het opslaan naar opslag (localStorage, IndexedDB, een backend) zodat het paginavernieuwingen of sessies overleeft; **hydrateren** betekent het terug in de app laden bij het opstarten. Gebruikelijk voor winkelwagen, auth tokens, gebruikersvoorkeuren en conceptformulieren.

## Waarom het belangrijk is

```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];
}
```

De twee helften: lezen-en-parseren bij init (hydrateren), en serialiseren-en-schrijven bij wijziging (persisteren).

## 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
```

## Opslag kiezen

```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
```

## De belangrijke voorbehouden

```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.
```

## Waarom het belangrijk is

Persistentie levert echte UX-waarde — winkelwagens overleven vernieuwingen, voorkeuren en concepten gaan niet verloren, gebruikers blijven ingelogd.

Maar naïeve implementatie introduceert subtiele, ernstige problemen: SSR hydratatie-mismatch, verouderde/beschadigde gegevens, schema-migratiebreuk, en **beveiligingsrisico's** (tokens persisteren in XSS-leesbare opslag).

De persist/hydrate-patroon kennen, de juiste opslag voor de gegevens kiezen, en de voorbehouden respecteren (beschermen voor SSR, schema versiebeheer, geheimen niet onveilig persisteren, opnieuw op te halen serverstatus niet persisteren) is wat persistentie robuust maakt in plaats van een bron van moeilijk te diagnosticeren fouten.