El estado del servidor no es como el tuyo

En el módulo 3 cargaste datos con useEffect: tres estados, una bandera contra la race condition, manejo de error. Funciona… para una pantalla. Pero en una app real, esos datos del servidor tienen exigencias que useEffect no cubre: cachear para no repedir lo mismo, revalidar cuando el usuario vuelve, reintentar si la red falla, compartir la misma data entre componentes sin pedirla dos veces. Hoy entiendes por qué el ESTADO DEL SERVIDOR es una bestia distinta al estado local, y por qué merece su propia herramienta.

Datos prestados, no tuyos

Los cinco problemas de fetch a mano

La herramienta: una librería de datos

Una nota sobre este módulo

Mini-reto

Antes de ver la librería, razona (en papel): toma la carga de gastos del módulo 3 (fetch en useEffect con tres estados). 1) Lista qué pasaría si DOS componentes distintos de tu app necesitaran esa misma lista: ¿cuántas peticiones se harían? 2) Si el usuario agrega un gasto en una pantalla, ¿cómo se enteraría la otra pantalla? 3) Para cada uno de los cinco problemas del concepto, escribe una frase de cómo lo resolverías a mano —y siente por qué preferirías que una librería lo haga—.

Qué sigue

Ya sabes POR QUÉ existe TanStack Query. La próxima lección muestra su corazón: useQuery —el hook que reemplaza todo el patrón de useEffect + tres estados por una línea declarativa, con caché incluida—. Verás cuánto código desaparece.