Conceptos básicos de SWR: stale-while-revalidate

SWR significa Stale-While-Revalidate, una estrategia de caché HTTP definida en RFC 5861. La estrategia consiste en servir inmediatamente al usuario los datos obsoletos (en caché), volver a validarlos en segundo plano y actualizar la interfaz cuando lleguen datos recientes.

Este enfoque prioriza el rendimiento percibido: los usuarios ven los datos al instante en lugar de esperar un viaje de ida y vuelta a la red.

Con los patrones de carga tradicionales, los usuarios ven un indicador de carga en cada navegación. Con SWR, ven inmediatamente los últimos datos conocidos y la interfaz se actualiza silenciosamente en segundo plano si los datos han cambiado.

Esto hace que las aplicaciones parezcan mucho más rápidas y reduce la interrupción cognitiva que provocan los estados de carga.

SWR vuelve a validar los datos automáticamente cuando: la ventana del navegador recupera el foco (el usuario cambia de pestaña y regresa), se restaura la conexión de red después de estar sin conexión, se llama explícitamente a mutate(), o se activa un temporizador refreshInterval configurable.

Estos activadores automáticos mantienen los datos actualizados sin que el desarrollador tenga que administrar manualmente la lógica de refetch.

Una key de SWR puede encontrarse en uno de varios estados: loading (no hay datos en caché y la primera solicitud está en curso), revalidating (hay datos en caché y se está actualizando en segundo plano), error (la solicitud falló) o success (hay datos recientes disponibles).

Comprender estos estados le ayuda a crear skeletons de carga y UIs de error precisos.

SWR mantiene una caché global en memoria indexada por la key de la solicitud (normalmente, una cadena de URL). Cualquier componente que solicite la misma key obtiene el mismo valor en caché y participa en el mismo ciclo de revalidación.

Esta deduplicación automática permite que 10 componentes llamen a useSWR con la misma key y solo se realice una solicitud de red.

SWR separa la lógica de administración de la caché de la obtención real de datos. Usted proporciona una función fetcher: una función async que acepta la key y devuelve los datos.

El fetcher se puede cambiar: use fetch, axios, graphql-request o cualquier fuente de datos asíncrona. SWR administra la caché y la revalidación independientemente de cómo funcione el fetcher.

Envuelva su aplicación en SWRConfig con una prop value que contenga una función fetcher: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Cada llamada a useSWR que omita un argumento fetcher usará este valor predeterminado global.

Esto centraliza la configuración de la API (URL base y encabezados de autenticación) en un solo lugar, sin repetirla en cada llamada al hook.

El patrón clásico usa useEffect + useState para administrar manualmente los estados de carga, datos y error. SWR sustituye todo eso por una sola llamada al hook que administra automáticamente la caché, la deduplicación, la actualización en segundo plano y los reintentos ante errores.

La reducción de código es considerable: un componente típico de obtención de datos pasa de tener más de 20 líneas a tener 3.

La key identifica una solicitud de forma única. Use la cadena de URL en los casos sencillos. Para solicitudes parametrizadas, use una key de tipo array: [url, params], donde params es un objeto o una cadena estable. null desactiva la solicitud.

Un buen diseño de keys garantiza que las solicitudes relacionadas compartan entradas de caché y que las solicitudes no relacionadas no colisionen.

SWR administra la revalidación de forma inteligente: dedupingInterval (2 segundos de forma predeterminada) evita que se activen varias revalidaciones simultáneamente si se montan muchos componentes a la vez. Solo se envía una solicitud por key dentro de la ventana de deduplicación.

Esto evita los problemas de efecto manada (thundering herd) habituales en árboles de componentes grandes donde muchos componentes obtienen los mismos datos.

SWR está desarrollado por Vercel, la empresa responsable de Next.js, y la integración es fluida. getServerSideProps o getStaticProps pueden precargar los datos, y SWR se hidrata en el cliente a partir de ese valor precargado.

Esto le proporciona HTML inicial renderizado en el servidor, con revalidación automática en el cliente al montarse, combinando lo mejor de SSR y SWR.

¿Cuál de las siguientes acciones NO activa la revalidación de SWR de forma predeterminada?

SWR implementa la estrategia Stale-While-Revalidate: sirve inmediatamente los datos en caché, los vuelve a validar en segundo plano y actualiza la interfaz cuando hay datos recientes. Activa la revalidación al recuperar el foco, al restablecerse la conexión, al llamar a mutate y mediante polling. La caché global deduplica las solicitudes entre componentes y la función fetcher se puede sustituir por completo.

Este modelo simplifica considerablemente el código de obtención de datos y, al mismo tiempo, ofrece un mejor rendimiento percibido.