¿Por qué distinguir entre el estado de la UI y el estado del servidor?

Question

Accepted Answer

**El estado de la UI** son datos que tu aplicación posee y controla localmente (interruptores, entradas de formulario, pestaña seleccionada). **El estado del servidor** son datos que residen en un servidor y simplemente están *cacheados* en el cliente (usuarios obtenidos, productos, publicaciones). Tienen características fundamentalmente diferentes y requieren herramientas diferentes.

## Las diferencias clave

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

## Por qué tratar los datos del servidor como estado de la UI sale mal

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

Terminas reimplementando el seguimiento de carga/error, caching, refetching, deduplicación y manejo de desactualización — para cada fetch.

## La herramienta adecuada: una librería de estado de servidor

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

Estas librerías están construidas específicamente para el problema del estado de servidor — mantener un cache local sincronizado con una fuente remota.

## La división práctica

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

## Por qué es importante

Reconocer que el estado del servidor es un **cache de datos remotos** — no un estado local ordinario — es una idea clave para la arquitectura de frontend moderna.

Explica por qué simplemente depositar datos de API en Redux/useState conduce a montañas de código manual de caching/carga, y por qué existen librerías de estado de servidor dedicadas (React Query, SWR) y son tan ampliamente adoptadas.

Dividir los dos — estado de la UI en stores locales, estado del servidor en una librería de caching — simplifica dramáticamente las aplicaciones densas en datos y elimina una categoría enorme de boilerplate y bugs de desactualización.