Estado del servidor: es una cache

Aquí está el error conceptual que más código estropea en 2026: tratar los datos del servidor como si fueran estado de tu aplicación. No lo son. Un perfil de usuario, una lista de productos, el resultado de una búsqueda — todo eso vive en una base de datos que tú no controlas desde el cliente. Lo que tienes en el navegador no es el dato: es una copia, tomada en un instante, que empieza a envejecer en cuanto la recibes. El estado del servidor es una cache. Y cachear, como bien dice el chiste, es uno de los dos problemas difíciles de la informática.

No es tu estado: es una copia de una verdad ajena

La fuente de la verdad de un producto no está en tu componente: está en el servidor. Tú solo tienes un reflejo. Ese reflejo tiene una propiedad que el estado local y el global de cliente no tienen: puede quedar obsoleto sin que tú hagas nada, porque otro usuario, otro proceso o el propio backend cambió el original mientras tu copia dormía en memoria.

Esto lo cambia todo. El estado de cliente (local o global) es la verdad: cuando lo escribes, es cierto por definición. El estado del servidor es una hipótesis sobre algo que vive fuera de tu alcance. Por eso las preguntas que te haces son distintas: no “¿cuál es el valor?”, sino “¿cuándo lo pedí?”, “¿sigue siendo válido?”, “¿debería volver a preguntar?”. Esas son preguntas de cache, no de estado.

La distinción tiene una raíz de propiedad. Del estado de cliente eres el dueño: nadie más puede cambiarlo a tus espaldas, así que basta con guardarlo. Del estado del servidor eres solo un lector: el original puede mutar en cualquier momento por causas que no controlas ni observas, y por eso guardarlo sin más es una trampa. Necesitas, además del dato, saber cuándo dejará de ser de fiar. Ese “además” es toda la diferencia entre un store y una cache.

flowchart LR
SV[servidor: fuente de la verdad] -->|fetch| C[cache del cliente]
C -->|render inmediato| V[vista]
C -->|marca stale tras un tiempo| C
V -->|refoco o remontaje| RV[revalidar en background]
RV -->|nuevo fetch| SV
style SV fill:#f38ba8,color:#11111b
style C fill:#fab387,color:#11111b
style V fill:#a6e3a1,color:#11111b

Las propiedades que lo hacen una clase aparte

Tratar el servidor como una cache trae de golpe una lista de necesidades que el estado local jamás plantea: obsolescencia (marcar un dato como viejo tras un tiempo, staleTime), revalidación (volver a pedirlo al reenfocar la ventana o reconectar), deduplicación (dos componentes que piden el mismo recurso disparan una sola petición), caché por clave, reintentos, paginación y estados de carga y error de primera clase. Reimplementar todo eso a mano, con useEffect y useState, es reescribir mal una librería que ya existe.

import { useQuery } from '@tanstack/react-query';

function Perfil({ id }: { id: string }) {
  const { data, isPending, isError } = useQuery({
    queryKey: ['usuario', id],   // la clave de cache
    queryFn: () => fetch(`/api/usuario/${id}`).then((r) => r.json()),
    staleTime: 60_000,           // fresco 1 min; luego revalida en segundo plano
  });
  // isPending y isError vienen dados: no los gestionas tu
}

La queryKey es la identidad del dato en la cache: dos componentes con la misma clave comparten una entrada y una sola petición. staleTime codifica tu política de frescura. Nada de esto es estado de aplicación: es gestión de cache, declarada.

Dos parámetros que se confunden a diario: staleTime es cuánto tiempo una copia se considera fresca (y no se revalida); gcTime es cuánto sobrevive en memoria una entrada sin observadores antes de recolectarse. Frescura y retención son ejes distintos: un dato puede estar obsoleto pero seguir en cache, listo para mostrarse al instante mientras se revalida por detrás. Entender esa separación es la diferencia entre configurar una cache y pelearse con ella.

El servidor como estado en 2026: RSC y use

La frontera se ha movido. Con los React Server Components y el hook use, buena parte del estado del servidor ni siquiera cruza al cliente como estado: se resuelve en el servidor y llega ya renderizado, o se pasa como promesa que el cliente consume con Suspense.

import { use, Suspense } from 'react';

function Perfil({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise); // suspende hasta resolver
  return <h1>{user.nombre}</h1>;
}

// el padre pasa la promesa y delega la espera a Suspense
<Suspense fallback={<Spinner />}>
  <Perfil userPromise={fetchUser(id)} />
</Suspense>

Este modelo trae una técnica clave: el prefetch. El servidor —o un loader de ruta— pide los datos antes de renderizar y entrega al cliente la cache ya rellena, que hidrata sin un segundo viaje ni un spinner. Es la cache de servidor cruzando la frontera con el dato ya dentro, y elimina las cascadas de peticiones tan típicas del fetching hecho a mano en useEffect.

Frameworks como Next.js y TanStack Start empujan el estado del servidor hacia el propio servidor, y usan TanStack Query o SWR para la parte que sí es interactiva en cliente (listas que se refrescan, mutaciones optimistas, scroll infinito). El modelo mental no cambia: sigue siendo una cache de una verdad remota. Solo se mueve dónde vive la cache.

La mutación: escribir y reconciliar

Leer es la mitad fácil. La difícil es escribir: al enviar un POST o un PATCH, tu copia local queda desactualizada al instante, porque acabas de cambiar la verdad remota. Ahí entra la invalidación, la otra cara de la cache. Tras una mutación exitosa marcas las claves afectadas como obsoletas y la librería las revalida sola:

import { useMutation, useQueryClient } from '@tanstack/react-query';

function useRenombrar(id: string) {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: (nombre: string) => api.patch(`/usuario/${id}`, { nombre }),
    onSuccess: () => qc.invalidateQueries({ queryKey: ['usuario', id] }),
  });
}

Un paso más allá está la actualización optimista (Nivel 35): pintar el resultado esperado antes de que el servidor confirme, y revertir si falla. La cache pasa a tener, por un instante, un valor que el servidor aún no ha ratificado — una apuesta que luego se reconcilia o se deshace. Es el reconocimiento explícito de que tu cache y la verdad remota son dos cosas que hay que reconciliar, no una sola que se pueda escribir sin más. Toda esta maquinaria —invalidar, revalidar, reconciliar— es justo lo que reescribirías a mano, y peor, si metieras el servidor en el store.