Por que distinguir estado de UI do estado de servidor?

Question

Accepted Answer

**Estado de UI** é um dado que seu aplicativo possui e controla localmente (toggles, entradas de formulário, abas selecionadas). **Estado de servidor** é um dado que existe em um servidor e é meramente *cacheado* no cliente (usuários buscados, produtos, posts). Eles têm características fundamentalmente diferentes e precisam de ferramentas diferentes.

## As principais diferenças

```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 que tratar dados do servidor como estado de UI dá errado

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

Você acaba reimplementando rastreamento de carregamento/erro, cache, refetching, deduplicação e tratamento de staleness — para cada fetch.

## A ferramenta certa: uma biblioteca 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
}
```

Essas bibliotecas são construídas especificamente para o problema de estado de servidor — manter um cache local sincronizado com uma fonte remota.

## A divisão prática

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

## Por que isso importa

Reconhecer que estado de servidor é um **cache de dados remotos** — não estado local regular — é um insight importante para arquitetura de frontend moderna.

Isso explica por que despejar dados de API em Redux/useState leva a montanhas de código manual de cache/carregamento, e por que bibliotecas dedicadas de estado de servidor (React Query, SWR) existem e são tão amplamente adotadas.

Dividir os dois — estado de UI em lojas locais, estado de servidor em uma biblioteca de cache — simplifica dramaticamente aplicativos pesados em dados e elimina uma enorme categoria de código padrão e bugs de staleness.