Waarom onderscheid je UI-state van server-state?

Question

Accepted Answer

**UI-state** is data die je app lokaal bezit en controleert (toggles, formulierinvoer, geselecteerd tabblad). **Server-state** is data die op een server leeft en slechts *gecacht* wordt op de client (opgehaalde gebruikers, producten, berichten). Ze hebben fundamenteel verschillende kenmerken en hebben verschillende tools nodig.

## De belangrijkste verschillen

```text
                  UI state                    Server state
Ownership         you own it (client)         the server owns it; client caches
Freshness         always current              can become STALE (server changed it)
Sync needed?      no                          yes — refetch, invalidate, revalidate
Shared?           usually one client          shared across users/devices/tabs
Concerns          just set/read it            caching, loading, errors, retries, dedup
```

## Waarom server-data als UI-state behandelen fout gaat

```jsx
// ❌ treating server data as plain local state — you must hand-build everything
function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

useEffect(() => {
    fetch("/api/users")
      .then(r => r.json()).then(setUsers)
      .catch(setError).finally(() => setLoading(false));
  }, []);
  // and now: caching? refetch on focus? dedup? retries? stale data? all manual 😓
}
```

Je implementeert loading/error tracking, caching, refetching, deduplicatie en staleness handling opnieuw — voor elke fetch.

## Het juiste gereedschap: een server-state-bibliotheek

```jsx
// ✅ React Query / SWR / RTK Query handle caching, loading, errors, refetch for you
function Users() {
  const { data: users, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(r => r.json()),
  });
  // automatic: caching, background refetch, dedup, retries, stale-while-revalidate
}
```

Deze bibliotheken zijn speciaal gebouwd voor het server-state-probleem — een lokale cache synchroniseren met een externe bron.

## De praktische verdeling

```text
UI state    → useState / Zustand / Context / Redux
Server state→ React Query / SWR / RTK Query / Apollo (for GraphQL)
```

## Waarom het belangrijk is

Inzien dat server-state een **cache van externe data** is — geen normale lokale state — is een belangrijk inzicht voor moderne frontend-architectuur.

Het verklaart waarom het dumpen van API-data in Redux/useState leidt tot bergen handmatig caching/loading code, en waarom speciale server-state-bibliotheken (React Query, SWR) bestaan en zo veel worden gebruikt.

De twee scheiden — UI-state in lokale stores, server-state in een cachingbibliotheek — vereenvoudigt datazware apps dramatisch en elimineert een enorme categorie boilerplate en staleness bugs.