¿Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande?

"¿Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande?" toca un punto muy concreto de React: cómo tomar decisiones de gestión de estado sin esconder el problema bajo una abstracción vistosa.

Una respuesta senior se nota cuando nombras qué riesgo quieres reducir con gestión de estado en React para "Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande", qué concesión aceptarías frente a estado del servidor y qué comprobarías antes de extender la decisión a todo el sistema.

Qué evalúa el entrevistador

• Si distingues qué parte de "Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande" pertenece a gestión de estado y cuál debería resolverse en estado del servidor.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si identificas la fuente de verdad, el estado derivado y los puntos donde podría aparecer sincronización manual o duplicada.

Respuesta sólida

• Nombra primero la fuente de verdad y deja claro qué datos deberían derivarse en vez de almacenarse dos veces.
• Explica dónde viviría cada pieza de estado: local si solo afecta a una interacción, compartido si cruza componentes y remoto si depende del servidor.
• Añade cómo evitarías sincronizaciones manuales, renders accidentales y errores por datos obsoletos.

Compromisos y errores comunes

• Duplicar estado entre store, formularios, URL o caché acaba generando inconsistencias que son difíciles de reproducir.
• Mover demasiado pronto una preocupación al estado global hace visible el problema, pero no lo arregla.

Ejemplo de código

Un ejemplo pequeño ayuda a ver dónde colocarías la lógica de gestión de estado en "Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande" y qué parte dejarías derivada o encapsulada.

import { memo, useMemo, useState } from 'react';

const ProductList = memo(function ProductList({ products }: { products: string[] }) {
  return <ul>{products.map((product) => <li key={product}>{product}</li>)}</ul>;
});

export function SearchPanel({ products }: { products: string[] }) {
  const [query, setQuery] = useState('');
  const visibleProducts = useMemo(
    () => products.filter((product) => product.toLowerCase().includes(query.toLowerCase())),
    [products, query],
  );

  return (
    <>
      <input value={query} onChange={(event) => setQuery(event.target.value)} />
      <ProductList products={visibleProducts} />
    </>
  );
}

Lo importante no es la API concreta, sino que la solución hace visible la fuente de verdad, el tratamiento del error y el punto exacto donde gestión de estado se sincroniza con estado del servidor dentro de "Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande" en React.

Ejemplo o caso real

Un caso creíble para "¿Cómo decidirías la frontera entre estado local, contexto, servidor y cache en una aplicación React grande?" aparece cuando una funcionalidad de React mezcla gestión de estado con estado del servidor y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

Primero aclaro qué problema resuelvo con gestión de estado y luego elijo la técnica; no al revés.