React
Diferencia estado local y server state, y explica caché, deduplicación, revalidación, sincronización y herramientas para consumir datos remotos en React.
Los datos remotos tienen propiedades distintas al estado local:
Un effect puede ser suficiente para una pantalla pequeña, pero debes manejar loading, error, cancelación y carreras.
useEffect(() => {
const controller = new AbortController();
loadProducts(controller.signal);
return () => controller.abort();
}, []);Bibliotecas como TanStack Query o soluciones del framework ofrecen:
La key debe representar todos los parámetros del recurso:
["products", { categoryId, page, query }]La selección actual de una fila es estado local. La lista de productos obtenida del servidor es server state. No deben gestionarse necesariamente con la misma herramienta.
React muestra datos; una capa de datos debe definir cómo se cargan, comparten y mantienen actualizados.
El estado local pertenece a una interacción cliente. Server state es una copia temporal de información cuya autoridad vive fuera:
servidor autoritativo
↓ fetch
caché cliente temporal
↓
componentes consumidoresPuede quedar stale sin que el usuario haga nada, porque otra persona o proceso modifica el servidor.
Una estrategia completa define:
Un useEffect con fetch cubre solo parte de este ciclo.
["products", { storeId, categoryId, page, query }]Todos los parámetros que cambian el resultado deben formar parte de la key. Si omites storeId, dos tiendas podrían compartir datos incorrectos. Usa valores serializables y consistentes.
Estas políticas pertenecen a la herramienta. No confundas stale con necesariamente incorrecto: puede ser una estrategia para mantener UI visible durante revalidación.
Si tres componentes solicitan la misma key, una capa de server state puede compartir una Promise y una entrada de caché. Effects independientes pueden producir tres requests y tres estados de loading.
mutation
↓ servidor confirma
├─ actualizar cache directamente
└─ invalidar queries relacionadasDespués de crear un producto, decide:
No limpies toda la caché por comodidad.
Un cambio optimista necesita:
Las librerías ayudan, pero las reglas del dominio siguen siendo tuyas.
Puede ser suficiente cuando:
Aun así, encapsula la carga y evita copiar el patrón por toda la aplicación.
Un router o framework puede iniciar datos antes del render de la página, evitar waterfalls y coordinar errores. Server Components pueden acceder a datos en servidor y reducir fetching cliente. La caché e invalidación concretas dependen del framework; no generalices reglas de una implementación a React base.
<ProductsContext value={products}>...</ProductsContext>Distribuir una respuesta mediante Context no crea:
Puedes distribuir un query client o configuración, pero deja el recurso en su caché especializada.
SSR puede proporcionar datos iniciales y luego hidratar la caché. Para evitar inconsistencias:
Distingue:
Un único isLoading no expresa todas las experiencias.
Reintentar GET idempotente puede ser razonable con backoff. No reintentes automáticamente una mutación no idempotente sin protección. Clasifica códigos y errores; un 400 no se arregla repitiendo.
Una caché puede mostrar datos anteriores offline. Comunica que pueden estar desactualizados y encola mutaciones solo si puedes resolver conflictos y reintentos de forma segura.
Prueba:
Mock Service Worker permite probar el límite HTTP sin simular internals de la biblioteca.
El cache cliente es visible y modificable. No almacenes secretos ni confíes en datos cacheados para autorización. El servidor valida cada operación y filtra campos según permisos.
Patrones de diseño de componentes y APIs muestra cómo consumir datos sin acoplar componentes a una implementación concreta de caché.