Cómo implementamos SWR en un proyecto y por qué nos encantó

¿Por qué SWR?

Recientemente, en SDH tuvimos la oportunidad de desarrollar un proyecto con React y soporte de Redux/Toolkit. El tema es que, aunque los datos se guardaban y se obtenían desde el store, la app no tenía ningún mecanismo de caché implementado.  Y mantener decenas de respuestas en el estado no me parece precisamente buena idea. En cualquier caso, pronto se volvió demasiado fácil perderse entre tantos slices de estado, a pesar de usar Toolkit.  

Además, en ese momento no tenía ninguna influencia en el backend. Con esos bloques de datos del tamaño de un iceberg flotando por ahí, algunas peticiones tardaban una eternidad en resolverse.  Y como la UI de la aplicación consistía en largas listas de ítems con pocas operaciones CRUD,  quedó claro que algún tipo de caché vendría de perlas. Así que nos decidimos por SWR, una librería creada por los desarrolladores de Vercel (también conocidos por Next.js).

¿Qué es SWR?

Vale, ¿te gusta leer definiciones? Espero que no, porque esta será de las más cortas que hayas visto. ‘SWR es una librería de React Hooks para obtener datos remotos’. Ya está. ¿Simple? Sí, pero ahora te voy a mostrar que SWR también es muy potente. Y por si te lo preguntabas, SWR significa stale-while-revalidate, lo que ya explica cómo funciona. SWR devuelve datos de la caché (stale), envía una petición para obtener datos actualizados (revalidate) y después devuelve los nuevos datos.  Como decía, simple. 

Por qué nos encantó SWR

Es fácil ver cómo usar SWR elimina los problemas descritos al principio de este artículo. Gracias a SWR, nosotros:

• Hicimos que la UI funcionara de maravilla (tras las peticiones iniciales) gracias al almacenamiento en caché de datos 
• Eliminamos casi todos los slices que contenían datos de la API y su lógica asociada
• Simplificamos el flujo de revalidación de datos tras realizar operaciones CRUD sobre colecciones
• Aceleramos el desarrollo de nuevas funcionalidades dependientes de la API

¿Cómo implementamos realmente esta librería para lograr resultados tan mágicos? 

Cómo funciona SWR

Tras poco tiempo trabajando con SWR, quedó claro que es bastante simple y muy amigable de usar. ¿Te apetece hacer una petición a una API con SWR? Mira esto:

La única particularidad es el fetcher. No es más que tu función personalizada para obtener datos. La aplicación en la que trabajamos ya tenía axios configurado y funcionando con toda su configuración (interceptors, headers, base URL, etc.), así que simplemente envolvimos nuestra instancia de axios así para obtener nuestro propio fetcher personalizado:

Por lo tanto, el hook completo podría ser tan simple como esto (omitemos el manejo de errores en este ejemplo):

Y... ¡eso es todo! Hemos creado un hook para obtener datos de la API aprovechando todas las bondades de SWR. Cada vez que se ejecute este hook, primero devolverá los datos obtenidos previamente (si existen) y solo entonces revalidará los datos y devolverá la nueva colección.

SWR viene de serie con un buen puñado de parámetros preconfigurados (todos están listados aquí), que hacen que trabajar con él sea pan comido. Una opción favorita a mencionar es dedupingInterval.

Escenario típico: obtienes datos en un componente, sigues desarrollándolo, los hijos se multiplican sin control y, al final, un hijo de cuarto nivel necesita esos datos. Conseguir llevar esos datos al componente hijo sin demasiado esfuerzo y evitando peticiones repetidas siempre es un reto. Pero no temas: simplemente reutiliza el hook de SWR... El deduping interval no permitirá que se haga la petición de nuevo dentro de un tiempo determinado (2 segundos por defecto). Nada mal.

"Pero si llamo al endpoint y devuelve los mismos datos de antes, mi componente se volverá a renderizar". No: SWR implementa comparación profunda, así que solo se renderizará de nuevo cuando los datos hayan cambiado de verdad. Y la función de comparación puede, por supuesto, personalizarse. 

Mutación de datos

Pero quizá digas que hacer un GET siempre es fácil: ¿qué pasa con las mutaciones? Seguro que eso es más complicado. Pues no tanto: las mutaciones no tienen por qué ser una pesadilla, y me sorprendió lo fácil que es mutar datos usando SWR (después de haberme divertido antes con Apollo). Aquí va un ejemplo real:

En este ejemplo, mutate es una función importada de SWR y /users es la clave que le dimos en el hook useUsers (no tiene por qué ser la URL del endpoint: puedes pasar la clave y la URL por separado).

Si quieres almacenar en caché y actualizar una sola entidad (objeto) obtenida de una colección más grande, simplemente muta por su clave así:

¿Parece demasiado simple? Es simple. Pruébalo y puede que te ahorres mucho tiempo escribiendo lógica extensa de Redux y depurando tus llamadas a la API.

Integraciones de SWR

Como ves, implementar SWR es sencillo; con un par de toques,  no cuesta llevar los ejemplos anteriores a niveles más altos y abstractos. Obviamente, SWR no se limita a esto y hay un buen número de opciones e integraciones disponibles:

integración con GraphQL

manejo de errores con opciones de reintento

revalidación automática

soporte de paginación (también para carga infinita)

prefetching de datos

y muchas más (documentación)

Trabajar con SWR nos pareció súper interesante y sin duda lo consideraremos para futuros proyectos. Si quieres saber más sobre esta fantástica librería, visita su sitio oficial con documentación, configuraciones y ejemplos aquí.

¡Feliz programación!