Pensando en React Query

Hola a todos. Gracias por estar aquí hoy, donde quiero hablar sobre cómo atarse correctamente los zapatos. La mayoría de las personas no saben que hay una forma correcta y una incorrecta de atarse los zapatos. Ambas formas parecen muy similares a primera vista, pero un nudo es estable y el otro se afloja mientras caminas. Es una pequeña diferencia que podría cambiar tu vida. Manténganse sintonizados hasta el final mientras les muestro ese truco.

Al trabajar con React Query, podríamos enfrentar situaciones similares, donde un pequeño ajuste puede marcar una gran diferencia. Descubrí esto cuando comencé mi viaje de código abierto en 2020, donde principalmente estaba ayudando participando con la comunidad. Respondí muchas preguntas en diferentes plataformas, lo cual fue una excelente manera para mí de comenzar en código abierto. Resulta que las personas están realmente felices y agradecidas si les ayudas a resolver su problema. Y también aprendí mucho al tener que mirar situaciones que no había encontrado yo mismo antes. Con eso, llegué a conocer bastante bien a React Query, y fue entonces cuando me di cuenta de un patrón común entre esas preguntas. Muchas de ellas mostraban un malentendido subyacente de lo que es o hace React Query y probablemente se responderían a sí mismas con un pequeño cambio de pensamiento.

Mi nombre es Dominik y soy un ingeniero de software de Viena. Me conocen en línea casi en todas partes como TK-Dodo. Trabajo como líder técnico de front-end en Edverity y también he tenido el privilegio de mantener la biblioteca de código abierto React Query durante los últimos dos años. Entonces, hoy, lo que realmente quiero hablar es mostrarles tres formas simples de cómo abordar React Query con una mentalidad mejor. Similar a atarse los zapatos correctamente, una vez que lo sabes, espero que tenga mucho sentido y sea bastante simple de seguir. Entonces, veamos qué se necesita para pensar en React Query.

El primer punto podría sorprenderte, pero es cierto. Aunque a menudo se describe como la pieza faltante para la obtención de datos en React, React Query no es una biblioteca de obtención de datos. No realiza ninguna obtención de datos por ti, porque si echamos un vistazo rápido a un ejemplo estándar de React Query, podemos ver que necesitamos proporcionar dos cosas al hook UseQuery. Una clave de consulta única, donde React Query almacenará los datos para nosotros, y una función de consulta que se ejecutará siempre que se deban recuperar datos. Luego, por supuesto, podemos usar ese hook en un componente para renderizar datos y los diversos estados en los que puede estar la consulta. Pero si echamos un vistazo rápido a la función de consulta nuevamente, podemos ver que en este ejemplo, está implementada con Axios, porque ¿por qué no? Pero el punto es, esa es tu biblioteca de obtención de datos. Esa consulta no le importa cómo lo haces. Lo único que le importa es si estás devolviendo una promesa cumplida o rechazada. De hecho, y probablemente esto sea yo hablando como mantenedor de la biblioteca, si estás presentando un problema diciéndome que no puedes mostrar una reproducción porque tu API es privada, probablemente te estaré diciendo que esta es la forma más sencilla de implementar la función de consulta. No hay obtención de datos en absoluto. Todo lo que estamos haciendo es devolver una promesa resuelta.

Por supuesto, React Query va muy bien con las bibliotecas de obtención de data como Axios, Fetch o GraphQL Request porque todas producen promesas. Una vez que entendemos que React Query no obtiene data, esperamos que quede claro que toda una clase de preguntas sobre la obtención de data simplemente desaparecen. Preguntas como ¿cómo puedo definir una URL base con React Query? ¿Cómo puedo acceder a las cabeceras de respuesta con él? ¿O cómo puedo hacer solicitudes GraphQL con React Query? Todas las preguntas sobre la obtención de data suelen tener la misma respuesta. A React Query no le importa. Solo devuelva una promesa de alguna manera, por favor.

Bueno, una vez que entendemos eso, es justo preguntar, si React Query no es una biblioteca de obtención de data, entonces ¿qué es? Mi respuesta a esta pregunta siempre ha sido un gestor de estado asiático. Ahora es importante entender lo que queremos decir con estado asiático. Tanner Lindsley, el creador de React Query, dio una gran charla en mayo de 2020 llamada Es Hora de Romper con Tu Estado Global. La charla sigue siendo muy relevante hoy en día, así que por favor mírala si aún no lo has hecho. La esencia de ella es que, durante mucho tiempo, hemos dividido nuestro estado en donde necesitamos que viva. ¿Solo lo necesitamos en un componente? Probablemente empezaremos usando el estado local. ¿Necesitamos que esté disponible más arriba en el árbol? Entonces lo movemos hacia arriba, y potencialmente pasamos data de nuevo como props. ¿Necesitamos que esté aún más arriba, o en todas partes de nuestra aplicación? Probablemente lo moveremos a un gestor de estado global, como Redux o Zustand, que vive fuera de React y luego lo distribuye globalmente a nuestra aplicación. Y hemos estado haciendo esto para todo tipo de estado, sin importar si es el botón de alternancia que estamos haciendo clic en nuestra aplicación, o la lista de problemas que tenemos que obtener de la red. Los hemos tratado a todos exactamente igual. El cambio de pensamiento viene cuando dividimos el estado de manera diferente. No donde se utiliza, sino por qué tipo de estado es. Porque el estado que poseemos completamente, que está disponible de forma sincrónica y siempre actualizado, como cuando hago clic en ese botón de alternancia de modo oscuro, tiene necesidades totalmente diferentes que el estado que se persiste de forma remota y está disponible de forma asincrónica, como una lista de problemas. Con el estado envejecido o el estado del servidor, solo vemos una instantánea en el momento en que lo obtuvimos. Puede quedar desactualizado porque no somos los únicos propietarios de ese estado. El backend, probablemente nuestra database, lo posee. Solo lo hemos tomado prestado para mostrar esa instantánea. Podrías notar esto cuando dejas una pestaña del navegador abierta durante algún tiempo y luego vuelves a ella. ¿No sería agradable ver data frescos y precisos automáticamente? Eso significa que tenemos que mantenerlos actualizados de alguna manera porque otros usuarios también pueden hacer cambios en el mientras tanto. Y porque el estado no está disponible de forma sincrónica, la información meta alrededor de ese estado, como los estados de carga y error, también deben ser gestionados. Así que, mantener tus data actualizados automáticamente y gestionar los ciclos de vida de los agentes no es algo que obtendrías o necesitarías de un gestor de estado tradicional de propósito general. Pero como tenemos una herramienta que está orientada hacia el estado del agente, podemos hacer que todo eso suceda y más. Solo necesitamos usar la herramienta correcta para el trabajo correcto.

La segunda parte que necesitamos entender es qué es un gestor de estado y por qué React Query es uno. Lo que los gestores de estado suelen hacer es hacer que tu estado esté disponible en tu aplicación de manera eficiente.

La parte importante aquí es eficientemente. Dicho de otra manera, lo enmarcaría como queremos actualizaciones, por favor, pero no demasiadas. Si demasiadas actualizaciones no fueran un problema, todos simplemente pegaríamos nuestro estado en el contexto de React. Pero es un problema real, y muchas bibliotecas intentan resolverlo de varias maneras, algunas más mágicas que otras.

Redux y Zustand, dos populares soluciones de gestión de estado, ambas ofrecen APIs basadas en selectores. Estos aseguran que nuestros componentes solo están suscritos a partes del estado que les interesan. Si otras partes de la tienda se actualizan, a esos componentes no les importa. Y el principio es que podemos llamar a esos hooks en cualquier lugar de nuestra aplicación para obtener acceso a ese estado, porque las bibliotecas lo hacen disponible globalmente.

Ahora con React Query realmente no es tan diferente. Excepto que la parte a la que te estás suscribiendo está definida por la clave de consulta. Ahora, dondequiera que llamemos a nuestro hook personalizado use issues, obtendremos actualizaciones si algo cambió en la porción de problemas de la caché de consulta. Y si eso no es suficiente, podemos llevar esto un paso más allá porque React Query tiene selectores también. Ahora estamos hablando de suscripciones de grano fino, donde los componentes solo están interesados en resultados computados o derivados de lo que se almacena. Si cambiamos un problema de abierto a cerrado, el componente que usa el hook use issue count no se volverá a renderizar porque la longitud no ha cambiado. Y al igual que con otros gestores de estado, podemos y muy probablemente deberíamos llamar a use query donde sea que necesitemos para obtener acceso a esos datos. Esto hace que todas las soluciones que intentan ciertas cosas como llamar a use effect para sincronizar datos desde React query en otro lugar o establecer datos en el estado local en el callback de on-success sean anti-patrones. Todas estas son formas de sincronización de estado que eliminan la única fuente de verdad y son innecesarias porque React query ya es un gestor de estado. Así que no necesitamos poner ese estado en otro.

Bueno, podrías estar pensando, ahora estoy haciendo esto, y estoy llamando a use query dondequiera que lo necesite, tengo tres componentes, llamo a use issues tres veces. Pero si algunos de nuestros componentes se renderizan condicionalmente, como cuando se abre un diálogo, o porque tenemos consultas dependientes, podríamos empezar a ver muchas recuperaciones al mismo punto final.

Podrías estar pensando, ah, acabo de buscar esto hace como dos segundos. ¿Por qué ya está buscando de nuevo? Entonces recurres a las docs, y empiezas a apagar todo en todas partes y todo a la vez, solo para no saturar demasiado tu back end. Tal vez deberíamos haber puesto nuestros data en Redux después de todo. Ten paciencia conmigo por un segundo porque hay cierta lógica en esta locura.

¿Por qué ReactQuery está haciendo todas esas solicitudes? Nos lleva de vuelta a las necesidades del estado asíncrono. Puede estar desactualizado. Así que queremos actualizarlo en algún momento. Y ReactQuery hace esto por ciertos disparadores. Enfoque de la ventana, montaje del componente, recuperación de la conexión a la red y cambio de la clave de consulta. Cuando ocurre uno de estos eventos, ReactQuery volverá a buscar esa consulta automáticamente. Pero eso no es toda la historia. Lo que pasa es que ReactQuery no hará esto para todas las consultas. Solo para aquellas que se consideran obsoletas.

Y esto nos lleva al segundo punto importante del día. El tiempo obsoleto es tu mejor amigo. Porque ReactQuery también es una herramienta de sincronización de data. Pero eso no significa que volverá a buscar todas las consultas a ciegas en segundo plano. Este comportamiento se puede ajustar mediante el tiempo obsoleto, que define el tiempo hasta que los data se vuelven obsoletos. Lo opuesto a obsoleto es fresco. Dicho de otra manera, mientras los data se consideren frescos, se nos darán solo desde la caché sin una nueva búsqueda. De lo contrario, obtendremos data de la caché y una nueva búsqueda. Por lo tanto, solo las consultas obsoletas se actualizarán automáticamente. Pero el hecho es que el tiempo obsoleto se establece por defecto en cero. Sí, cero como en cero milisegundos, por lo que react query marca todo instantáneamente obsoleto. Eso es ciertamente agresivo y puede llevar a la sobreexplotación. Pero en lugar de errar en el lado de minimizar las solicitudes de red, react query erra en el lado de mantener las cosas actualizadas. Ahora, definir el tiempo obsoleto depende de ti. Depende mucho de tu recurso y tus necesidades.

También no hay un valor correcto para el tiempo obsoleto. Si estás consultando configuraciones que solo cambiarán cuando se reinicie el servidor, el tiempo obsoleto infinito puede ser una buena elección. Por otro lado, si tienes una herramienta altamente colaborativa donde varios usuarios actualizan cosas al mismo tiempo, podrías estar contento con el tiempo obsoleto cero. Por lo tanto, una parte muy importante del trabajo con React Query gira en torno a la definición del tiempo obsoleto. De nuevo, no hay un valor correcto. Lo que me gusta hacer es establecer un valor por defecto a nivel global y luego potencialmente sobrescribirlo cuando sea necesario.

Bien, volvamos rápidamente a las necesidades del estado asíncrono una vez más. Sabemos que React Query mantiene nuestra caché actualizada si los datos se consideran obsoletos. Y uno de estos eventos ocurre. El evento que probablemente es el más importante de todos y en el que quiero centrarme es el cambio de la clave de consulta. ¿Cuándo ocurriría principalmente ese evento? Bueno, eso nos lleva al último punto. Deberíamos tratar los parámetros como dependencias. Realmente quiero enfatizar esto aunque ya está descrito en la documentación y también tengo un post en el blog sobre ello. Si tienes parámetros, como los filtros en este ejemplo que quieres usar dentro de tu función de consulta para hacer una solicitud, tienes que añadirlos a la clave de consulta. Esto asegura muchas cosas que hacen que sea genial trabajar con React Query. Por un lado, asegura que las entradas se almacenan en caché por separado, dependiendo de su entrada. Así, si tenemos diferentes filtros, los almacenamos en diferentes claves de caché, lo que evita las condiciones de carrera. También permite actualizaciones automáticas cuando esos filtros cambian, porque pasamos de observar una entrada de caché a la otra. Y también evita problemas con cierres obsoletos, que suelen ser difíciles de depurar. Esto es tan importante, que hemos lanzado nuestro propio plugin de ESLint. Puede comprobar si estás usando algo dentro de la función de consulta, y te dice que lo añadas a la clave. También se puede corregir automáticamente, así que te recomiendo encarecidamente que lo uses. Si quieres, puedes pensar en la clave de consulta como el array de dependencias para useEffect, pero sin los inconvenientes, porque no tenemos que pensar en la estabilidad referencial en absoluto. No hay necesidad de useMemo o useCallback para involucrarse aquí. No para la función de consulta y no para la clave de consulta, porque React Query se encargará de esto automáticamente para nosotros.

Ahora, por último, y esto podría introducir un nuevo problema. Ahora estamos usando useQuery donde lo necesitamos a cualquier nivel en nuestra aplicación, pero ahora tenemos dependencias a nuestra consulta que solo existen en una cierta parte de la pantalla. ¿Qué pasa si no tengo acceso a los filtros donde quiero llamar a useIssues? ¿De dónde viene? La respuesta de nuevo es que a React Query no le importa. Es un problema puro de gestión del estado del cliente, porque esos filtros aplicados son estado del cliente y cómo lo gestionas depende de ti. Todavía está totalmente bien usar el estado local o un gestor de estado global para eso como veas conveniente.

Quizás escribirlo en la URL y usar eso como un gestor de estado también es una buena idea. Como ejemplo, vamos a ver cómo podría verse esto si hemos puesto los filtros en un gestor de estado como Zustand. Lo único que hemos cambiado es que en lugar de pasar los filtros como entradas a nuestro hook personalizado, lo estamos obteniendo directamente de la tienda. Esto muestra el poder de la composición al escribir hooks personalizados. Y podemos ver la clara separación entre el estado del servicio gestionado por use query y el estado del cliente, en este caso gestionado por use store. Cada vez que actualizamos el filtro en la tienda, no importa dónde, la consulta se ejecutará automáticamente o leerá los últimos data de la caché, si están disponibles. Este patrón nos permitirá usar React Query como un verdadero gestor de estado de agente. Ahora, para resumir, React Query no es una biblioteca de obtención de data. Es un gestor de estado de agente. El tiempo obsoleto es tu mejor amigo, pero tienes que configurarlo según tus necesidades. Y deberíamos tratar los parámetros como dependencias y usar nuestra regla de lint para hacer cumplir esto. Si cambiamos nuestro pensamiento para seguir estos tres puntos, tendremos un tiempo aún mejor trabajando con React Query. Al igual que un pequeño ajuste en la forma en que atamos nuestros zapatos puede ser una gran mejora en la calidad de vida. Ahora, todavía te debo la solución para atar tus zapatos correctamente. Es realmente bastante simple. Al crear el lazo, asegúrate de tirar del cordón hacia ti primero, luego tira a través del hueco. Esta pequeña diferencia resultará en un nudo que se mantendrá horizontal y no se soltará tan fácilmente. También hay un video de YouTube si quieres ir a verlo. Así que eso es todo lo que tengo. Gracias por escuchar. Asegúrate de seguirme en Twitter y suscribirte a mi blog. La versión 5 de React Query está a la vuelta de la esquina, y esta es una buena manera de mantenerse al día. Gracias.