React Query API Design – Lecciones Aprendidas

♪ 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.

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.

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?

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.

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.

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.

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.

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.

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.