El servidor no es cliente: es una cache

Hay un error que no es de sintaxis ni de rendimiento, sino de categoría, y por eso sobrevive a cualquier refactor: meter los datos del servidor en el mismo cajón que el estado propio de tu aplicación. Un perfil, una lista de pedidos, el resultado de una búsqueda no son estado tuyo. Son la copia de una verdad que vive en una base de datos que tu cliente no gobierna, tomada en un instante y condenada a envejecer desde que la recibes. Lo que tienes en el navegador no es el dato: es una hipótesis sobre el dato. Y una hipótesis sobre algo ajeno no se guarda como se guarda lo propio: se cachea, con una política que diga cuándo dejar de creerla. Este nivel nace de tomarse esa distinción en serio y seguirla hasta sus consecuencias.

Quién es dueño de la verdad

La distinción entre estado de cliente y de servidor no es de tamaño ni de origen, sino de autoridad. Del estado de cliente eres el dueño: cuando escribes que el menú está abierto, el menú está abierto; tu escritura es la verdad por definición, porque nadie más puede contradecirla.

Del estado de servidor eres, en el mejor de los casos, un lector con licencia temporal. El original vive en otra máquina, y otro usuario, otro proceso o el propio backend pueden cambiarlo mientras tu copia duerme en memoria. Tu versión es cierta solo hasta que deja de serlo, y lo grave es que deja de serlo sin avisarte.

Piénsalo como una fotografía frente a un espejo. El estado de cliente es un espejo: refleja en vivo lo que de verdad hay, porque la fuente y el reflejo son lo mismo. El estado de servidor es una fotografía: fiel en el instante del disparo y cada vez menos fiel después, porque el mundo que retrató siguió moviéndose sin ella.

Esa diferencia de autoridad cambia las preguntas que tiene sentido hacerse. Sobre el estado de cliente preguntas cuál es el valor, y la respuesta es total y presente. Sobre el estado de servidor esa pregunta es ingenua; las útiles son cuándo lo pedí, si sigue siendo válido, si debería volver a preguntar. Son preguntas sobre el tiempo y la confianza, no sobre el valor. Y son, exactamente, las que resuelve una cache.

Una copia que envejece sola

Toda copia de una verdad ajena tiene una propiedad que el estado local jamás tiene: se vuelve obsoleta sin que toques nada. No hay bug que provoque la obsolescencia; es la condición natural de una copia mientras el original sigue vivo en otra parte.

Aceptar eso introduce una variable que el estado propio ignora por completo: el tiempo. Un valor local es atemporal, vale hasta que tú lo cambies; una copia remota lleva pegada una fecha implícita de captura, y su credibilidad decae desde ese instante. Gestionar estado de servidor es, en el fondo, gestionar esa decadencia.

Quien intenta cubrir esa gestión a mano, con useEffect y useState, no está manejando estado: está reescribiendo una cache, peor y con más bugs que las que ya existen. El fragmento de abajo parece correcto y, sin embargo, no resuelve casi nada de lo que una cache resuelve.

// Parece correcto; en realidad es una cache incompleta
function Perfil({ id }: { id: string }) {
  const [data, setData] = useState<Usuario | null>(null);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    let vivo = true;
    fetch(`/api/usuario/${id}`)
      .then((r) => r.json())
      .then((u) => vivo && setData(u))
      .catch((e) => vivo && setError(e));
    return () => { vivo = false; };
  }, [id]);
  // Sin frescura, sin revalidacion, sin deduplicacion, sin invalidacion,
  // sin reintentos, y con una carrera si id cambia deprisa.
}

Ese useEffect es el retrato del problema: cada carencia del comentario final es una responsabilidad que una cache asume por diseño y que aquí queda sin cubrir. Y no son adornos; son justo las que fallan en producción, con datos viejos en pantalla y peticiones duplicadas que nadie pidió.

Las cuatro preguntas de una cache

Gobernar una copia remota es responder cuatro preguntas que un valor propio nunca plantea, y no son opcionales: si no las contestas tú, las contesta el azar, y el azar contesta mal.

La frescura pregunta cuánto tiempo confías en la copia antes de sospechar de ella, y se responde con el staleTime. La revalidación pregunta qué evento te obliga a volver a pedirla: recuperar el foco de la ventana, reconectar la red, el paso de un intervalo. La deduplicación pregunta cómo evitar que diez componentes pidiendo el mismo recurso disparen diez peticiones en vez de una. Y la invalidación pregunta, cuando tú mismo cambias el dato con una escritura, qué copias quedan mentirosas y hay que tirar.

Las cuatro se enredan en cuanto la app crece. Dos pestañas abiertas, un usuario que edita en otra ventana, una lista que se ve en tres sitios a la vez: cada escenario activa una pregunta distinta, y ninguna se resuelve guardando el dato y ya. Por eso el problema no es de almacenamiento, sino de política sobre el tiempo.

El error de categoría: el servidor en el store global

Durante años el reflejo por defecto fue: llega un dato del servidor, lo guardo en el store global. Parece inocente, porque es un dato y el store guarda datos. Pero es un error de categoría, del mismo orden que archivar una fotografía en la carpeta de documentos editables: la foto retrata algo que ya pasó y no controlas, y editarla no cambia lo retratado.

Cuando metes datos remotos en el store de cliente, heredas la obligación de hacer a mano las cuatro cosas de arriba. El slice de abajo parece código de dominio y no lo es: es una cache casera, incompleta, enterrada entre tu estado real.

// El anti-patron: el servidor disfrazado de estado de cliente
const usuariosSlice = createSlice({
  name: "usuarios",
  initialState: { lista: [], cargando: false, error: null },
  reducers: {
    pedir: (s) => { s.cargando = true; },
    llegaron: (s, a) => { s.cargando = false; s.lista = a.payload; },
    fallo: (s, a) => { s.cargando = false; s.error = a.payload; },
  },
});
// Y ahora TU mantienes a mano: caducidad, revalidacion al reenfocar,
// deduplicacion de peticiones e invalidacion tras cada escritura.

La medición del ecosistema lo confirma sin ambigüedad: buena parte de la caída de Redux entre 2020 y 2026 se explica porque una herramienta especializada, TanStack Query, se llevó justo esa responsabilidad y dejó el store para lo que de verdad es estado de cliente. No fue una derrota de prestaciones, sino de categorías: el servidor encontró un dueño mejor que el store.

flowchart LR
DB[servidor: la verdad] -->|fetch| CA[cache: copia con politica]
CA -->|render inmediato| V[vista]
CA -.->|no es lo mismo| ST[store: estado propio]
ST -->|render| V
style DB fill:#f38ba8,color:#11111b
style CA fill:#fab387,color:#11111b
style ST fill:#a6e3a1,color:#11111b
style V fill:#89b4fa,color:#11111b