Pourquoi distinguer l'état UI de l'état serveur ?

Question

Accepted Answer

**L'état UI** est une donnée que votre application possède et contrôle localement (bascules, entrées de formulaire, onglet sélectionné). **L'état serveur** est une donnée qui vit sur un serveur et est simplement *mise en cache* sur le client (utilisateurs récupérés, produits, messages). Ils ont des caractéristiques fondamentalement différentes et nécessitent des outils différents.

## Les différences clés

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

## Pourquoi traiter les données serveur comme l'état UI s'avère problématique

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

Vous finissez par réimplémenter le suivi du chargement/erreurs, la mise en cache, la réinitialisation, la déduplication et la gestion de l'obsolescence — pour chaque appel.

## Le bon outil : une bibliothèque d'état serveur

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

Ces bibliothèques sont construites spécifiquement pour le problème de l'état serveur — maintenir un cache local en synchronisation avec une source distante.

## La séparation pratique

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

## Pourquoi c'est important

Reconnaître que l'état serveur est un **cache de données distantes** — et non un état local ordinaire — est une insight majeure pour l'architecture frontend moderne.

Cela explique pourquoi mettre les données API dans Redux/useState conduit à des montagnes de code de mise en cache/chargement manuel, et pourquoi les bibliothèques d'état serveur dédiées (React Query, SWR) existent et sont si largement adoptées.

Séparer les deux — l'état UI dans des stores locaux, l'état serveur dans une bibliothèque de mise en cache — simplifie drastiquement les applications riches en données et élimine une énorme catégorie de boilerplate et de bugs de staleness.