React Query API Design – Lecciones Aprendidas

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

React Query es una biblioteca popular para mantener el estado asincrónico, más a menudo el estado devuelto de la obtención de datos. Ha crecido tanto en popularidad en los últimos años que ahora se utiliza en casi el 20% de todas las aplicaciones de React. En cierta medida, esto se atribuye a su facilidad de uso y a la gran experiencia del desarrollador.


En esta charla, el mantenedor de React Query, Dominik, nos guiará a través de algunas de las decisiones de diseño de la API que se tomaron en React Query para llegar a esa DX. Escucharás historias sobre cosas que salieron bien, pero también sobre compensaciones y errores que se cometieron, y qué lecciones podemos aprender todos de ellos.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

Dominik Dorfmeister
Dominik Dorfmeister
26 min
25 Oct, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Estoy muy emocionado de estar aquí hoy, dando mi primera charla en vivo en una conferencia presencial. Dominik, el mantenedor de React Query, recorre las decisiones de diseño de la API, incluidas historias de éxito, compensaciones y errores. Tener Linsley diseñó la API de consulta de tamaño mediano de React Query para ser mínima, intuitiva, poderosa y flexible. Las versiones principales en open source requieren esfuerzos de marketing, pero no principalmente para agregar nuevas características. TypeScript es crucial para construir proyectos y gestionar las demandas de los usuarios en open source puede ser un desafío. La adición de la opción de páginas máximas mejoró el rendimiento y evitó recargas innecesarias. La inversión de control da flexibilidad a los usuarios, pero pueden ocurrir errores en el diseño de la API. El open source requiere gestión del tiempo y retroalimentación de los usuarios. El diseño de la API está influenciado por la facilidad de tipado y el buen soporte de TypeScript. Involucrarse en open source implica prueba y error y unirse a plataformas comunitarias como TanStack Discord. El viaje de Dominik comenzó durante la pandemia y se le puede encontrar en Twitter, TanStack Discord y su blog.

1. Introduction to React Query API Design

Short description:

Estoy muy emocionado de estar aquí hoy, dando mi primera charla en vivo en una conferencia presencial. Me llamo Dominik, soy ingeniero de software de Viena, y he mantenido la popular biblioteca de código abierto React Query durante los últimos tres años y medio. Quiero guiarte a través de las decisiones de diseño de la API que hemos tomado, incluyendo historias de éxito, compensaciones y errores. El diseño de API es difícil, y la dulce API de React Query ha contribuido a su éxito.

♪ Estoy muy emocionado de estar aquí hoy, porque esta es realmente la primera vez que doy una charla en vivo en una conferencia presencial. Um, sí, gracias. Um... Así que pensé que quería tomar una foto rápida solo para recordar esto para siempre. Está bien. Sí, está bien. Genial, gracias.

De todos modos, me llamo Dominik. Soy ingeniero de software de Viena, donde trabajo como líder técnico de front-end en Verity. Puedes encontrarme en línea como tkdodo casi en todas partes. Y durante los últimos tres años y medio, he mantenido la bastante popular biblioteca de código abierto React Query. Lo siento, PanStack React Query, como la llamamos en estos días.

Pregunta rápida. Por favor, levanten la mano si han oído hablar de esa biblioteca antes. Sí, wow. Bien, eso es un montón de manos. Eso es genial, porque significa que tal vez realmente conozcan algunas de las APIs de las que voy a hablar hoy. Porque, ya sabes, hoy quiero guiarte a través de algunas de las decisiones de diseño de la API que hemos tomado en React Query en los últimos años. Um, contar algunas historias sobre cosas que salieron bien, pero también resaltar algunas de las compensaciones que tuvimos que hacer y, ya sabes, hubo algunos errores que cometimos. Y, sí, tal vez haya algunas lecciones que todos podamos aprender de esos. Y quiero hablar de eso principalmente por dos razones.

Una, creo que el diseño de API es difícil. Si no me crees, esa no es mi cita. Julius dijo eso. Es un tipo realmente inteligente. Mantiene TRPC. También contribuye a React Query de vez en cuando. Así que si él lo dice, probablemente tenga razón. Y la segunda razón es que creo que React Query tiene una API realmente, realmente dulce. Y es una de las razones por las que se ha vuelto tan exitosa en los últimos años.

2. Evolution of React Query API

Short description:

Tener Linsley diseñó la biblioteca con una API de consulta de tamaño medio. Necesita ser tanto mínima e intuitiva, como poderosa y flexible. La complejidad de la API debe crecer con la complejidad de la aplicación. La API useQuery proporciona muchas características de inmediato, y funciones adicionales como useMutation pueden añadirse para tareas más complejas. Como mantenedor de código abierto, he aprendido a no emocionarme con las versiones principales.

Ahora, por supuesto, no puedo atribuirme el mérito de eso. Tener Linsley creó la biblioteca, y él diseñó la mayoría de las APIs. Y de hecho tiene un tweet muy bueno que resume los objetivos de la biblioteca, donde dice que la API de consulta es en realidad de tamaño medio cuando la desglosas toda, pero la parte más importante es que puedes entender y aprender a usarla comenzando con una sola función que proporciona el 80% de toda la propuesta de valor en el primer intento. A partir de ahí, el resto de su API se puede aprender gradualmente si es necesario. Y creo que eso es lo que se necesita para que una biblioteca se vuelva popular. Necesita ser tanto mínima e intuitiva, como poderosa y flexible.

Pero para cualquier API dada, ya sabes, esas dos cosas suelen estar en lados opuestos de la misma escala. Si echamos un vistazo a los métodos de array, por ejemplo, en el lado izquierdo, tendríamos algo como array.join, ¿verdad? Un método muy simple. Hace una cosa y lo hace muy bien, y no hay sorpresas allí. Y en el otro extremo del espectro, tendríamos algo como array.reduce, que es muy poderoso. Podemos implementar todos los demás métodos de array solo con reduce. Pero ya sabes, si esto es lo único que tenemos disponible, probablemente tampoco sería genial, porque también es bastante complicado de leer de vez en cuando.

Ahora, para las bibliotecas, creo que falta la segunda escala, y esa debería ser usualmente la complejidad de la aplicación, porque a medida que la complejidad de tu aplicación crece, realmente quieres que tus APIs se vuelvan más poderosas y flexibles. Y en esa escala, pondría useQuery justo aquí, abajo a la izquierda, si lo llamamos con los argumentos mínimos requeridos, que son básicamente solo la clave de consulta y la función de consulta. Ahora, esa API, creo, sigue siendo bastante simple y fácil de usar, pero nos da muchas cosas ya de inmediato. Obtenemos cosas como almacenamiento en caché, duplicación de solicitudes, actualizaciones en segundo plano, ya sabes, recolección de basura automática, como la lista sigue y sigue. Hay muchas cosas que obtenemos solo con esta llamada de función. Y luego más tarde, podríamos añadir una llamada a useMutation, ¿verdad? para hacer una actualización y luego vincularla de nuevo con invalidar consultas.

Así que, esto ya es un poco más complicado, pero, ya sabes, podemos llegar muy lejos solo con esas dos funciones. Así que, lo pongo justo aquí. Pero a medida que pasa el tiempo y tu aplicación se vuelve más compleja, podrías querer hacer más cosas. Así que, vas a hacer una actualización optimista, tal vez de vez en cuando, o necesitas una consulta infinita. Y esas APIs son ciertamente un poco más complejas. Y hasta arriba, tenemos, por ejemplo, nuestros plugins o las suscripciones de caché, que son realmente, realmente de bajo nivel. Por ejemplo, nuestras herramientas de desarrollo están construidas con las suscripciones de caché. Pero, ya sabes, una vez que llegas a un punto donde necesitas esta complejidad, probablemente estés feliz de que esas existan también, al igual que estás feliz de usar reduce de vez en cuando. Bien, y llegamos a esta API que evoluciona contigo a través de una planificación cuidadosa, muchas iteraciones, y también un par de versiones principales. Y eso me lleva directamente al primer aprendizaje que tuve como mantenedor de código abierto, que es que ya no me emocionan las versiones principales.

3. Challenges in Open Source API Design

Short description:

El diseño de API en código abierto es desafiante debido a la dificultad de revertir decisiones. Las versiones principales en código abierto requieren esfuerzos significativos de marketing, pero no se trata principalmente de agregar nuevas características. Las características generalmente van en versiones menores. React Query versión 5 introdujo algunas características que podrían haberse retroportado a la versión 4. Desacoplar los cambios disruptivos de los eventos de marketing podría ser beneficioso. Se sugirió una versión semántica de cuatro dígitos para permitir cambios disruptivos más frecuentes. Todavía estoy emocionado con TypeScript.

El diseño de API es difícil. Creo que ya lo dije. Pero es especialmente difícil en código abierto porque no podemos revertir fácilmente las decisiones que hemos tomado. Como un ejemplo diferente, en el trabajo en Verity, tenemos un sistema de diseño que publicamos en un registro privado de NPM. Y, ya sabes, la última versión en la que está esto es en realidad 105.2.0, ¿verdad? Esos son números enormes. Pero, ya sabes, a nadie le importa porque es solo un número que sube. La mayoría de los equipos simplemente actualizarían y, ya sabes, verían que realmente no cambió nada que les afectara o fue solo como el valor predeterminado que cambió, y simplemente siguen adelante con ello. Así que no es un gran problema. Pero en código abierto, no podemos hacer esos cambios disruptivos a la ligera porque cada nueva versión principal tiene que ser realmente este tipo de evento de marketing donde tenemos tweets de anuncio y publicaciones de blog de anuncio e incluso videos. Porque si los usuarios escuchan como versión principal, tu principal, creo que suena enorme y genial. Y la pregunta que siempre surge entonces es como, ¿cuáles son las nuevas características en esta versión principal? El problema con eso es que las versiones principales no se tratan de características. Se tratan de romper cosas existentes, y las características generalmente van en menores. Así que si recuerdas los hooks de React, ¿verdad?, vinieron en la versión 16.8. No en la 16 o 17, sino específicamente en la 16.8. Y React router agregó los cargadores de rutas en la versión 6.4 y fun agregó soporte para Windows en la versión 1.1. Así que esos son solo algunos ejemplos donde las características generalmente van en menores. Por supuesto, hay excepciones cuando rediseñas algo desde cero, ya sabes, y eso te permite hacer nuevas características. Podrías tener nuevas características en una versión principal, pero generalmente, vienen en menores. Así que cuando me preguntaron cuáles son las nuevas características en React Query versión 5, en realidad comencé a sudar un poco porque no teníamos nada planeado. Estábamos planeando romper cómo llamas a un use query y básicamente todo, pero no teníamos ninguna nueva característica planeada. Así que lo que hicimos fue agregar algunas características a la versión 5 que honestamente también podríamos haber retroportado a la versión 4. Y no creo que eso sea genial porque significa que estamos reteniendo características a los usuarios solo para tener este tipo de evento de marketing o gran nueva versión. Y creo que lo que sería bueno sería desacoplar estos cambios disruptivos de los eventos de marketing. Creo que Anthony Fu tuvo una gran sugerencia sobre la versión semántica de cuatro dígitos donde tendrías un número de época delante de la versión principal que podrías usar para esas revisiones y para marketing y podríamos hacer cambios disruptivos entonces más a menudo. Creo que es una buena idea. Dudo que suceda pronto. Es solo algo en lo que pensar.

Y sí, tal vez cuando salga una nueva versión principal, en lugar de preguntar qué hay de nuevo, tal vez preguntar qué está rompiendo en la biblioteca en su lugar. OK, así que ya no me emocionan las versiones principales, pero una cosa que todavía me emociona es TypeScript. Sí, ¿tú también?

4. TypeScript and Managing User Demands

Short description:

Pensar en los tipos desde el principio y diseñar APIs teniendo en cuenta los tipos es crucial para construir nuevos proyectos. Los constructos dinámicos de JavaScript pueden ser difíciles de tipar más adelante. Las sobrecargas en TypeScript, como la función useQuery en React Query, pueden llevar a mensajes de error confusos. Al eliminar opciones innecesarias y simplificar el código, las líneas de tipos en useQuery se redujeron de 125 a 25 en la versión cinco. Gestionar las demandas de los usuarios en código abierto es un desafío, ya que agregar cada solicitud de característica puede sobrecargar la API y confundir a los recién llegados. Tomarse el tiempo para evaluar las solicitudes de características y considerar la base de usuarios más amplia es importante. Sin embargo, puede haber instancias donde se cometen errores, como la API RefetchPage en Infinite Queries. Las sugerencias y casos de uso de los usuarios ayudan a dar forma a las bibliotecas, pero los mantenedores también deben considerar el panorama general y el impacto de agregar nuevas APIs.

No te preocupes, no vamos a entrar en TypeScript a nivel de biblioteca en esta charla. Pero creo que si estás construyendo algo nuevo cuando estás comenzando, ¿verdad? , creo que ayuda enormemente pensar en los tipos desde el principio y diseñar tus APIs teniendo en cuenta los tipos. Ahora, sé que hay muchas personas que dicen, bueno, podemos simplemente hacerlo funcionar primero y siempre podemos agregar los tipos más tarde. No creo que eso sea necesariamente algo bueno de hacer porque cuando trabajamos con JavaScript, podemos tener todos esos constructos lindos y dinámicos que funcionan en tiempo de ejecución, pero que podrían ser bastante difíciles de tipar más adelante. Creo que todo es posible con suficiente magia en TypeScript, pero ya sabes, toda magia tiene un precio, y en este caso, el precio suele ser la complejidad del tipo de aplicación y la carga de mantenimiento. Realmente me gusta esta cita. No estoy seguro de quién la dijo. Si algo es difícil de entender para un compilador, también es difícil de entender para los humanos. Así que si tenemos problemas para expresar lo que queremos al compilador, ya sabes, tal vez la API que hemos elegido no sea realmente la mejor. Y uno de esos constructos lindos y dinámicos que teníamos en React Query era en realidad useQuery porque cuando comenzamos, ya sabes, podías llamarlo de tres maneras diferentes con tres argumentos posicionales diferentes. Ahora, realmente no hay una buena manera de hacer que esto funcione en TypeScript excepto con sobrecargas, que es lo que hicimos. Y las sobrecargas son problemáticas porque tienen, como, mensajes de error muy extraños de vez en cuando porque lo que hace el compilador es que intenta todas las versiones diferentes y luego muestra el mensaje de error para la última sobrecarga que intentó, y eso podría ser completamente engañoso. Además, tuvimos que hacer algunas comprobaciones en tiempo de ejecución para realmente, ya sabes, transformar lo que el usuario ingresa en un solo objeto de todos modos. Y pensamos, como, realmente, ¿quién necesita tres maneras diferentes de hacer lo mismo? Así que lo que hicimos fue que, en la versión cinco, eliminamos todas las otras opciones para hacerlo. Ahora solo puedes llamar a useQuery con el objeto de opciones y eso redujo las líneas de tipos que teníamos de 125 a solo 25 líneas de tipos. Así que una gran simplificación para nosotros también y una mejor experiencia para el desarrollador.

Y la cosa es, creo que si hubiéramos comenzado con tipos desde el principio, creo que esta es la API con la que habríamos llegado eventualmente. Bien, ahora suficiente sobre TypeScript. Una cosa que surge cuando la biblioteca se vuelve popular cada vez es que los usuarios quieren más características, ¿verdad? Y para ser honesto, creo que gestionar una base de usuarios exigente es una de las cosas más complicadas en código abierto porque, por un lado, realmente quieres implementar las características que los usuarios están sugiriendo y escuchar sus problemas y ayudarlos a resolverlos. Pero por otro lado, cuanto más agregamos a la biblioteca, como si simplemente agregas cada solicitud de característica que llega, la API se vuelve sobrecargada y la biblioteca se vuelve desenfocada y, ya sabes, eso podría reducir la adopción nuevamente para los recién llegados porque se confunden un poco sobre lo que realmente está sucediendo. Tenemos que equilibrar esto de alguna manera. Mi consejo aquí sería simplemente tomarte tu tiempo antes de agregar algo a una biblioteca. Creo que los usuarios pueden ser muy exigentes a veces, pero, ya sabes, en la relación entre usuario y mantenedor, en realidad es el trabajo del usuario decirte todo sobre los plazos y los casos de uso y lo importante que es que agregues esta característica, pero es el trabajo del mantenedor mantener el panorama general en mente, como, ¿funcionará esta API también para otros usuarios, para otros casos que el reportero original ni siquiera ha pensado? Porque recuerda, una vez que agregamos una API, realmente no podemos, como, cambiarla fácilmente sin una nueva versión principal. Ahora, una de estas cosas donde me equivoqué fue la API RefetchPage en nuestras Infinite Queries. Para contexto, Infinite Queries son nuestra manera de hacer estas páginas de desplazamiento infinito que todos odian relativamente fáciles de implementar. Lo siento mucho por eso. Pero, ya sabes, técnicamente, una Infinite Query es solo una entrada de caché que se divide en múltiples páginas donde cada página depende de la anterior. Y eso tiene el efecto de que cuando ocurre una nueva consulta, ya sabes, volvemos a consultar todas las páginas una tras otra, y algunos usuarios, ya sabes, se quejan de que quieren solo darme un método donde pueda volver a consultar, como, una sola página de estas páginas. Y pensamos, está bien, eso no es una mala idea.

5. Refetching Pages and Debouncing API Calls

Short description:

Agregar la opción de volver a consultar una sola página en InvalidateQueries planteó varios problemas, incluyendo confusión y un posible estado incorrecto de la interfaz de usuario. Después de considerar el caso de uso, introdujimos la opción max pages en la consulta infinita. Esta API permite a los usuarios limitar el número de páginas en la caché, mejorando el rendimiento y evitando consultas innecesarias. Es importante tomarse el tiempo para tomar decisiones sobre la API y considerar alternativas antes de implementarlas. Agregar un campo de número de debounce a use query no está dentro del alcance de React Query, ya que hay múltiples formas de implementar el debounce correctamente. Los usuarios pueden implementar fácilmente esta característica en Userland utilizando implementaciones existentes o escribiendo la suya propia.

Así que vamos a añadir a InvalidateQueries una opción para volver a consultar, como, una sola página. Eso sonaba bien al principio, pero en realidad tenía tres problemas. Lo descubrimos con el tiempo. Por un lado, creo que es un poco extraño y confuso porque InvalidateQueries en realidad no sabe nada sobre consultas infinitas o normales. Así que si no coincides con una consulta infinita, esta función en realidad no hace nada. Y por restricciones técnicas, también solo podríamos añadirlo a las versiones imperativas que teníamos. Y si hubiera una nueva consulta automática, aún volvería a consultar siempre todas las páginas. Y creo que también es una de las maneras más fáciles de obtener, como, un estado incorrecto en tu pantalla porque si tienes una lista de páginas que dependen unas de otras y vuelves a consultar una en el medio, ya sabes, podrías ver resultados duplicados en la pantalla si alguien más hizo una actualización en, como, la primera página o algo así. Así que la interfaz de usuario puede desincronizarse muy fácilmente.

Así que lo que hicimos fue dar un paso atrás y preguntar a los usuarios, como, ¿cuál es el caso de uso real para el que quieres usar esto? ¿Cuál es la motivación detrás de esto? Y siempre era lo mismo. Decían que, como, si tengo 100 páginas en la caché y el usuario se desplaza mucho, no quiero saturar mi servidor API con una nueva consulta. Y creo que eso es justo. Pero intentamos resolver este problema desde una perspectiva diferente en su lugar. Y finalmente, nos decidimos por la opción mucho más sencilla de max pages en la consulta infinita, que simplemente te permite limitar cuántas páginas hay en la caché en cualquier momento dado. Y creo que esta API es mucho mejor porque resuelve el problema de manera integral, pero desde un punto de vista diferente. Para todo tipo de nuevas consultas, y casualmente también puede acelerar tu renderizado si estás navegando a una página que ya tiene páginas en caché, se renderizará más rápido porque no necesita renderizar tanto. Así que mi conclusión aquí es que llegamos a una decisión de API no tan buena demasiado rápido. Y si nos hubiéramos dado más tiempo, creo que habríamos llegado a una mejor solución en su lugar. La única otra alternativa que se me ocurre es prefijar todo con inestable o experimental hasta que sepas que va a durar. No sé si eso es mejor porque no sé si la gente realmente usa APIs experimentales. Y luego, sí, recibo mensajes como este, y no sé si eso es realmente mejor.

Otra API que se solicita a menudo es poder hacer debounce a las llamadas API. Así que recibimos esa solicitud de característica mucho. Y podrías querer tener eso cuando, por ejemplo, tienes un campo de búsqueda y quieres hacer un filtrado automático. A menos que quieras hacer una solicitud API en cada pulsación de tecla, quieres alguna forma de hacer debounce a eso. Así que la sugerencia es simplemente añadir un campo de número de debounce a use query, ¿verdad? Pero este es un muy buen ejemplo de una API que no llegará a React Query porque simplemente no es responsabilidad de React Query. Hay muchas formas diferentes de hacer debounce y hacerlo correctamente. Probablemente necesite más que solo un número como opción, ¿verdad? Así que puede complicarse bastante rápido, y también aumentará el tamaño del paquete para los usuarios que no usan esto. La buena noticia aquí es que puedes implementar esto relativamente fácil en Userland. Puedes usar tu implementación favorita de useDebounce, puedes escribir una tú mismo, o simplemente puedes usar deferredValue de React.

6. Inversion of Control and API Design Mistakes

Short description:

La inversión de control es una excelente manera de dar a los usuarios flexibilidad en la implementación de características y mantener la superficie de la API pequeña. Podemos lograr esto utilizando funciones de callback para opciones y la clave de consulta. Sin embargo, incluso con un diseño cuidadoso de la API, pueden ocurrir errores. Aprendí esto con React Query Versión 4, donde los cambios en la máquina de estado principal llevaron a un comportamiento inesperado. Es importante que los usuarios prueben las versiones beta y proporcionen retroalimentación a los mantenedores para evitar tales problemas en las versiones estables.

La forma en que esto funciona es que el filtro en tu estado se usará para mostrar la entrada actual al usuario, pero tomarás el filtro con debounce y lo pasarás a la clave de consulta y luego a React Query para no hacer fetches tan a menudo. Creo que esta inversión de control es una excelente manera de dar a los usuarios la flexibilidad de implementar ciertas características por su cuenta y nos permite mantener una superficie de API pequeña.

Ahora, creo que la clave de consulta es bastante especial aquí, pero también podemos obtener inversión de control en otras opciones que tenemos simplemente haciéndolas una función. Un ejemplo es una discusión que tuve con un usuario hace un tiempo donde sintieron que la característica de refetch on window focus que tenemos activada por defecto es excelente para la mayoría de los casos, pero a veces no lo es, por ejemplo, cuando la consulta está en un estado de error. Ahora, realmente no podemos agregar otra opción a eso porque sería como, ¿qué es ese refetch on window focus si error o algo así? Es como, eso es simplemente extraño. Así que lo que hicimos fue que simplemente hicimos esta función una función de callback que acepta la consulta donde el usuario puede derivar lo que quieren de eso en Userland. Creo que eso es como un truco barato para permitir a los usuarios hacer eso. Y desde entonces hemos hecho que casi todas nuestras opciones acepten funciones de callback para que tengas más flexibilidad.

Ahora, por último, creo que incluso si mantenemos todos estos puntos en mente y no importa cuán bien intentemos diseñar una API, creo que llegará un momento en que algunas personas estarán descontentas con ella. Y esas personas pueden ser bastante ruidosas al respecto. Y creo que los mantenedores de código abierto no son inmunes a cometer errores. Así que las probabilidades son que en algún momento, podríamos lanzar una API que no sea muy bien recibida. Aprendí esta lección de la manera difícil con React Query Versión 4, donde hicimos algunos cambios en nuestra máquina de estado principal. Veamos el ejemplo de antes donde tenemos este filtro, y lo que sucede cuando intentamos manejar los estados de carga y error con las banderas derivadas isLoading e isError. Ahora, este código funcionaba perfectamente bien en la Versión 3, pero lo que sucedió en la Versión 4 fue que verías como un spinner de carga por toda la eternidad. Y eso es porque una consulta que comienza en un estado deshabilitado, porque aquí tenemos el filtro como una cadena vacía por defecto, así que enabled va a ser falso, por lo que la consulta estará deshabilitada. En la Versión 4, esto también lo pondría en el estado isLoading.

Ahora, por supuesto, hay razones para esto, y no sonaba tan mal cuando hicimos estos cambios e implementamos esta API, pero si damos un paso atrás y lo miramos objetivamente, y si no tenemos conocimiento sobre React Query, creo que este comportamiento es simplemente una API muy mala. Creo que es absolutamente horrible. No hay excusas para eso. Y resulta que mucha gente siente lo mismo, y estoy de acuerdo en que esto está mal. Y este contador de pulgares hacia arriba sigue subiendo, por cierto, todos los días, aunque ya hemos lanzado una solución en la Versión 5. Y la cuestión es que esta retroalimentación habría sido realmente buena como un par de días antes porque recibimos esto justo después del lanzamiento principal. Así que, sí, lo que me quedó es la expectativa del usuario de que los mantenedores hagan todo bien en sus diseños de API, mientras que al mismo tiempo, ya sabes, podrían no probar las versiones beta y reportar retroalimentación. Así que si hay algo que me gustaría que te lleves de esta charla, es realmente esto. Por favor, ayuda a los mantenedores de bibliotecas de código abierto que estás usando. Sí, están los otros mantenedores. Así que por favor ayuda a los mantenedores de las bibliotecas que estás usando probando versiones beta o candidatos de lanzamiento y reportando retroalimentación, porque creo que es el mejor momento para ser escuchado. Sin esas retroalimentaciones tempranas, ya sabes, errores como el que cometí podrían llegar a la versión estable. Pero, ya sabes, estable no significa libre de errores o probado en batalla.

QnA

Open Source and Balancing Day Job

Short description:

El código abierto es una calle de doble sentido, ofreciendo beneficios mutuos. Equilibrar un trabajo diario con contribuciones de código abierto requiere gestión del tiempo. Comenzar use query con tres firmas no fue mi decisión, así que no puedo responder a eso.

Simplemente significa que no podemos cambiar la API más sin una nueva versión principal. Así que el código abierto es una calle de doble sentido, y creo que esta es una de las mejores maneras de ayudar mientras también obtienes lo máximo a cambio. Sí, eso es todo lo que tengo. Muchas gracias. Felicitaciones, Dominik, increíble charla.

¿Cómo te sientes? Cuéntanos un poco sobre cómo ha sido pasar de tener estos tipos de partes de tu trabajo diario y tu vida y estos aprendizajes que has tenido y llevarlo a, en primer lugar, una increíble primera charla en una conferencia. Sí, ahora estoy relajado. Esto es muy relajado. Eso fue genial. Así que toda la tensión se ha ido. Eso es increíble, y la gente realmente lo disfrutó. La gente está vibrando. Me encanta.

Haces mucho en la comunidad de código abierto con tu trabajo diario. Haces mucho trabajo en la comunidad de código abierto, y también tienes un trabajo diario. Puedes hacerlo todo, hacer tiempo para hablar en conferencias. ¿Cómo lo equilibras, especialmente cuando tienes un trabajo diario y contribuyes a la comunidad de código abierto y mantienes un React Query? Sí, no trabajo a tiempo completo, así que trabajo como contratista. Y hago el... Mi trabajo diario es un trabajo a tiempo parcial, así que tengo suficiente tiempo para hacer código abierto. Realmente no paga las cuentas. Sabes, es un problema diferente. Pero me encanta hacerlo. Lo disfruto mucho. Y sí, creo que esto me ha ayudado, como, a mantenerme en ello, sí.

Increíble. Así que quien haya hecho esa pregunta, si quieres poder equilibrar, tal vez intentar encontrar maneras en que se superpongan y tomarte un tiempo para enfocarte en cada uno, eso es increíble. OK, así que esto ahora está más enfocado en el tipo de producto real también. ¿Por qué comenzaste tu use query con tres firmas al principio? Esa fue una pregunta que llegó. Creo que alguien tiene un ejemplo muy específico en mente. Sí, no, esto en realidad es anterior a mi participación, así que tengo que preguntarle a Tenor eso.

React Query Version and API Design

Short description:

La primera versión de React Query fue en JavaScript sin tipos. Parecía lindo tener múltiples cosas con la misma firma en JavaScript, pero no en TypeScript. La retroalimentación de los usuarios es esencial, y priorizo sus necesidades. Si una característica no es comúnmente solicitada y puede hacerse fácilmente en el lado del usuario, no se añadirá. El diseño de la API está influenciado por la facilidad de escritura para los usuarios y un buen soporte de TypeScript.

Creo que cuando React Query salió, la primera versión fue realmente en JavaScript sin ningún tipo. Esto debió haber sido antes de que TypeScript se hiciera popular. Y creo que fue solo, ya sabes, algo que podías hacer, donde simplemente pensabas, OK, tal vez los usuarios solo quieran pasar, como, una clave y una función y sin opciones, y luego eso es todo. Y, sí, creo que en JavaScript, se sentía realmente, como, lindo hacerlo. Oh, puedes hacer múltiples cosas con la misma firma. En TypeScript, no es tan bueno. Y esto tal vez plantea una pregunta diferente cuando estás hablando de la experiencia del desarrollador y construyendo una experiencia para el desarrollador, porque eres un desarrollador, y ¿cómo es fácil para ti ponerte en los zapatos de las personas que van a estar usando tu biblioteca, o tienes que esperar hasta que las cosas lleguen a beta y la gente te dé retroalimentación? Tal vez es una combinación de ambos. Sí, definitivamente es una combinación de ambos. He estado usando React Query yo mismo antes. Me involucré con la biblioteca, así que como que, sabía lo que quería de ella. Pero, por supuesto, no puedo realmente priorizar mis necesidades de ella, así que hay, como, la retroalimentación siempre es bienvenida. Por eso también estoy en todas las discusiones y tratando de entender lo que la gente quiere. Durante los primeros seis meses de mi trabajo de código abierto, no hice nada más que responder preguntas de la gente y mirar los problemas que están teniendo. Me encanta eso también, cómo comenzaste escuchando antes de dar la vuelta y comenzar a contribuir. Y eso se vincula con la siguiente pregunta que viene de Mark, que es cómo decides qué características vale la pena añadir. Obviamente, todos tienen sus propias opiniones sobre lo que debería estar en la parte superior de la lista de prioridades. ¿Cómo decides, o cómo lo hace el equipo? Escribí una entrada de blog sobre esto también, así que puedes ir a leer eso. ¿Puede la gente encontrar la entrada de blog? En tkdodo.eu. Es realmente buena. De hecho, me perdí en las entradas de blog cuando estaba investigando ayer. Pero, sí. La respuesta corta sería que creo que si algo no es muy común, así que no se solicita a menudo, y es fácilmente realizable en el lado del usuario con un par de líneas de código, entonces no lo vamos a añadir como una opción extra. Necesita realmente, como, superar los negativos de ampliar la superficie de la API. Y necesita ser irrealizable, o muy difícil de hacer en el lado del usuario. Algunas cosas son simplemente irrealizables debido a cómo nos integramos con React. Así que entonces necesitamos apoyarlas. Y voy a vincular esto a otra pregunta que llegó, que es sobre el diseño de la API. Así que acabas de hablar un poco sobre cómo decides cuáles, qué características van a estar en las próximas versiones y así sucesivamente. Pero, ¿tienes solo un proceso en general o un marco que usas cuando estás pensando en el diseño de la API en general? Y supongo que eso es parte de ello. Así que creo que necesita ser fácil de escribir para los usuarios. Así que creo que tener un buen soporte de TypeScript como que, me guía a través de cómo debería ser la API.

Getting Involved in Open Source

Short description:

El ensayo y error es una gran parte del proceso, junto con discutir con otros que han trabajado en APIs similares. Unirse a plataformas comunitarias como TanStack Discord puede ser una excelente manera de involucrarse en el código abierto. Mi viaje comenzó durante la pandemia cuando tenía más tiempo y me uní a TanStack Discord para ayudar a responder preguntas. Gradualmente me involucré más, haciendo correcciones de errores y añadiendo características. Puedes encontrarme en Twitter, TanStack Discord y mi blog.

Aparte de eso, hay mucho ensayo y error. Así que tengo que admitir eso. Y hablar con otras personas que han hecho APIs similares. Hablé con Mark ayer sobre consultas infinitas y cómo lo están haciendo, cómo quieren hacerlo en otras bibliotecas. Así que hay mucho intercambio con trabajos previos también.

Eso es increíble. Y ahora esto es más una pregunta sobre tu viaje. Muchas personas quieren involucrarse más en el espacio de código abierto, pero tal vez están un poco nerviosas o tal vez están tratando de averiguar la mejor manera de hacerlo. ¿Puedes contarnos un poco sobre tu viaje en el espacio de código abierto?

Y luego añadiré a esto pidiéndote que des algún consejo para alguien que tal vez esté tratando de entrar o que recién esté comenzando en el código abierto. Creo que el viaje es totalmente diferente para cada uno. No hay un solo camino de cómo va. La forma en que fue para mí es que, como durante la pandemia, no tenía muchas cosas que hacer. No había a dónde ir. Así que pensé en unirme a TanStack Discord e intentar ayudar respondiendo preguntas, intentar devolver un poco a la comunidad porque ya estábamos usando, creo, tres bibliotecas diferentes de TanStack en ese momento. Y estaba tan enfocado en responder preguntas que a veces no sabía cuál era el problema. Así que lo busqué, miré el código fuente y luego me fui adentrando más y más hasta que hice mi primera corrección de errores y luego mi primera característica. Y luego, sí, como que conocía bastante bien la biblioteca en ese momento.

Así que entonces, sí, así fue como sucedió. Increíble. Ahora estoy seguro de que la gente quiere preguntar más, pero se nos acabó el tiempo. ¿Dónde puede encontrarte la gente en línea? Sí, TKdodo es mi manejador en línea. Estoy mucho en Twitter. TanStack Discord es un buen lugar para contactarme. Es mejor que los DMs de Twitter. Son terribles. Sí. Y mi blog, por supuesto. Increíble. Muchas gracias. Denle un aplauso una vez más.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Query: ¡Es hora de romper con tu "Estado Global"!
React Summit Remote Edition 2020React Summit Remote Edition 2020
30 min
React Query: ¡Es hora de romper con tu "Estado Global"!
Top Content
Global state management and the challenges of placing server state in global state are discussed. React Query is introduced as a solution for handling asynchronous server state. The Talk demonstrates the process of extracting logic into custom hooks and fixing issues with state and fetching logic. Optimistic updates with mutation are showcased, along with the benefits of using React Query for data fetching and mutations. The future of global state management is discussed, along with user feedback on React Query. The Talk concludes with an invitation to explore React Query for server state management.
Gestión del Estado de React: 10 Años de Lecciones Aprendidas
React Day Berlin 2023React Day Berlin 2023
16 min
Gestión del Estado de React: 10 Años de Lecciones Aprendidas
Top Content
This Talk focuses on effective React state management and lessons learned over the past 10 years. Key points include separating related state, utilizing UseReducer for protecting state and updating multiple pieces of state simultaneously, avoiding unnecessary state syncing with useEffect, using abstractions like React Query or SWR for fetching data, simplifying state management with custom hooks, and leveraging refs and third-party libraries for managing state. Additional resources and services are also provided for further learning and support.
SolidJS: ¿Por qué tanto Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: ¿Por qué tanto Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
Una Guía Práctica para Migrar a Componentes de Servidor
React Advanced 2023React Advanced 2023
28 min
Una Guía Práctica para Migrar a Componentes de Servidor
Top Content
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
React Query - Las partes malas
React Day Berlin 2024React Day Berlin 2024
30 min
React Query - Las partes malas
Top Content
React Query is a popular library with significant weekly downloads and positive user sentiment. It may have trade-offs like bundle size, but the actual size shipped is smaller. Bundle size optimization can be achieved by exporting only necessary features. React Query's declarative approach eliminates the need for custom data fetching solutions. It offers caching, request duplication, background updates, and more. RackQuery doesn't support normalized caching, but refetching after invalidation works fine. React's vision includes suspense architecture and server components. The documentation could be improved with a more structured flow. TensorStack Query can be a good choice for Next.js apps, but not necessary with mature frameworks. The 10 stack query and router concepts were discussed. Combining React Query with HTTP caching provides a robust caching solution.
React Query y Auth: ¿Quién es responsable de qué?
React Advanced 2021React Advanced 2021
19 min
React Query y Auth: ¿Quién es responsable de qué?
Top Content
This talk introduces React Query and Auth, discussing how React Query maintains server state on the client and handles mutations and data updates. The day spa app example demonstrates the use of React Query to fetch data and handle user authentication. React Query is also useful for managing user data and ensuring accurate data from the server. The talk highlights the importance of addressing the three main players in user data: React Query, Auth Functions, and persistence across sessions.

Workshops on related topic

Repensando el Estado del Servidor con React Query
React Summit 2020React Summit 2020
96 min
Repensando el Estado del Servidor con React Query
Top Content
Featured Workshop
Tanner Linsley
Tanner Linsley
La distinción entre el estado del servidor y el estado del cliente en nuestras aplicaciones puede ser un concepto nuevo para algunos, pero es muy importante entenderlo cuando se entrega una experiencia de usuario de primera calidad. El estado del servidor viene con problemas únicos que a menudo se cuelan en nuestras aplicaciones sorpresa como:
- Compartir datos entre aplicaciones- Caché y Persistencia- Deduplicación de Solicitudes- Actualizaciones en segundo plano- Gestión de Datos "Obsoletos"- Paginación y Recuperación Incremental- Memoria y Recolección de Basura- Actualizaciones Optimistas
Los gestores tradicionales de "Estado Global" pretenden que estos desafíos no existen y esto finalmente resulta en que los desarrolladores construyan sus propios intentos sobre la marcha para mitigarlos.
En esta masterclass, construiremos una aplicación que expone estos problemas, nos permite entenderlos mejor, y finalmente los convierte de desafíos a características usando una biblioteca diseñada para gestionar el estado del servidor llamada React Query.
Al final de la masterclass, tendrás una mejor comprensión del estado del servidor, el estado del cliente, la sincronización de datos asíncronos (un bocado, lo sé), y React Query.
Fetch, useEffect, React Query, SWR, ¿qué más?
React Advanced 2023React Advanced 2023
102 min
Fetch, useEffect, React Query, SWR, ¿qué más?
Top Content
WorkshopFree
Ondrej Polesny
Ondrej Polesny
En esta masterclass, primero, repasaremos las diferentes formas en que puedes consumir APIs en React. Luego, probaremos cada una obteniendo contenido de un CMS sin cabeza (tanto con REST como con GraphQL) y verificando en detalle cómo funcionan.
Aunque no se requiere un conocimiento avanzado de React, esta será una sesión práctica, por lo que necesitarás clonar un repositorio de GitHub preconfigurado y utilizar tu editor de programación React preferido, como VS Code.
Aprenderás:- Qué diversas opciones de obtención de datos hay en React- Cuáles son las ventajas y desventajas de cada una- Cuáles son los casos de uso típicos y cuándo cada estrategia es más beneficiosa que otras