Estado Local y Caché del Servidor: Encontrando un Equilibrio

¡Hola a todos! Me alegra verlos a todos hoy en este evento, y aunque realmente espero que esta conferencia sea presencial este año, desafortunadamente para todos nosotros, estoy hablando con ustedes de forma remota. nuevamente desde Ámsterdam. ¿Quizás el próximo año? ¡Esperemos que sí!

Y hoy vamos a hablar sobre un tema que es una fuente interminable de frustración para todos los desarrolladores, que es manejar un estado local de nuestra aplicación, en los casos en que necesita lidiar con comportamientos asíncronos, solicitudes de API, y todo lo demás.

Permítanme presentarme rápidamente. Mi nombre es Natalia Tepluchina. Soy miembro del equipo central de Vue.js. Trabajo principalmente en la documentación de Vue, por lo que si estás leyendo la documentación de Vue 3, hay altas probabilidades de que estés leyendo algo que yo autoricé. Trabajo como Stack Frontend Engineer en GitLab. Y allí en GitLab, por supuesto tenemos Vue en nuestro stack frontend. Pero para los gestores de estado, trabajamos tanto con Vuex, que se mencionará brevemente en esta charla, como con el Cliente Apollo, que también se mencionará brevemente en esta charla. Así que conozco los dolores de cada solución, y tengo una idea de lo que estoy hablando en esta charla en particular, y también soy experta en Tecnologías Web de Google.Net.

Entonces, comencemos a profundizar en nuestro estado global. ¿Qué es el estado global en nuestra aplicación? Estos son algunos data que queremos compartir entre diferentes componentes, diferentes vistas, diferentes rutas, y por alguna razón lo necesitamos disponible en todas partes en nuestra aplicación.

Veamos un ejemplo muy corto, breve y rápido para aquellos que nunca trabajaron con Vuex o se olvidaron de cómo se ve, y esto será Vuex 4. Así que si la sintaxis te resulta un poco desconocida, no tengas miedo. Es muy similar a Vuex 3 que usamos con Vue 2.

Así que imagina que tenemos un estado local que devuelve una sola propiedad llamada count, y esto es 0. Y necesitamos cambiar esta propiedad de alguna manera, así que añadimos una mutación. Porque todas las propiedades del estado sólo deben ser cambiadas con mutaciones. Así que tenemos una mutación para incrementar el count. Eso simplemente incrementa el count, como sugiere el nombre. Y esto ya es suficiente para usar esto en nuestro componente, pero algunas empresas como la mía tienen una convención que dice que no podemos hacer commit de mutaciones desde los componentes. Si alguna vez has oído que esto es un anti-patrón, esto es incorrecto. Puedes llamar a las mutaciones, hacer commit de las mutaciones, desde los componentes, pero puede hacer que tu factorización sea más difícil cuando necesitas un comportamiento asíncrono, por eso a veces las envolvemos en acciones. Así que esto es un boilerplate suficiente para incrementar el count.

Con lo que estamos lidiando aquí en este ejemplo en particular. En primer lugar, lidiamos con cambios sincrónicos en el estado, por eso dije que probablemente ni siquiera necesitaremos una acción. No tenemos ningún comportamiento asincrónico aquí. No es persistente, por lo que cada vez que actualizo la página, el contador volverá a ser cero. No necesitamos almacenar esto en ningún otro lugar fuera del estado de Vuex. Tiene una única fuente de cambios, por lo que esta es como nuestra mágica única fuente de verdad, que solo es responsable de los cambios de contador en nuestra aplicación. El contador puede ser cambiado en cualquier otro lugar. Se almacena solo en Vuex y se cambia solo en Vuex.

Y sí, no crea mucho código repetitivo. Este punto puede ser un poco discutible, porque tres propiedades diferentes para cambiar un contador... Aún así, es una cantidad razonable de código repetitivo para este cambio, considerando el hecho de que el contador se compartirá en toda la aplicación. Pero todo esto no es tan agradable cuando empezamos a tratar con datos del servidor. Así que añadamos algunos datos del servidor a la ecuación en nuestro estado de Vuex. Aquí, a primera vista, parece el mismo contador. Tenemos una propiedad de personajes, tenemos una imitación que cambia los personajes, y tenemos alguna acción asincrónica que obtiene data de nuestro punto final de personajes. Y después de esto, cometemos una mutación, así que todo está bien.

Pero con esto, tu aplicación no es suficiente porque obtener personajes es una operación asincrónica lo que significa que habrá un momento en tu aplicación cuando no haya personajes y estés ocioso. Estás esperando que tu API te devuelva tus data. Y por supuesto, necesitas añadir un estado de carga, porque necesitamos mostrar este bonito indicador de carga o esqueleto o lo que sea que estés mostrando en tu aplicación. Y también, estamos obteniendo data de la API. ¿Y qué pasa si la respuesta no está ahí? ¿Qué pasa si tu búsqueda no fue exitosa? Necesitamos manejar los errores, que es una super buena práctica para cualquier llamada asincrónica. Y por eso necesitamos añadir una bandera más—error—a nuestra aplicación. Y con esto, nuestra simple estructura de una-acción-una-mutación no es tan simple, porque necesitas actualizar la carga, necesitas actualizar el error, y aquí hay una convención bastante común que Gateweb también usa para manejar el comportamiento asincrónico con solicitudes gratuitas. Así que aquí tenemos como tres estados finitos—un estado de carga, un estado de éxito, y un estado de error. Y aquí estamos estableciendo la carga a verdadero, el error a falso, así que estamos en el estado de carga ahora. Luego recibimos nuestros personajes, todo está bien, la carga es falsa, el error es nulo, los personajes están aquí, y renderizamos el array de personajes, y por supuesto puede haber algún estado de error. Así que en este caso particular, establecemos la carga a falso, decimos que el error es algo que el servidor nos devuelve, seleccionamos tres mutaciones. Sí, puedes simplificarlo si tienes solo uno, pero si quieres algún tipo de estándar, usualmente las empresas vienen con algo como esto. Y ahora nuestra acción tampoco es tan simple, porque cuando empezamos una acción, entramos en este limbo de carga, solicitando un personaje, y luego tenemos personajes, cometemos la mutación de éxito, almacenando los personajes en el estado, y luego si hay un error, también cometemos una mutación de error, y si imaginas todo este código repetitivo, es bastante grande ya. Así que sí, es enorme para una sola solicitud, y si tenemos múltiples solicitudes, probablemente tengamos diferentes estados de carga, ¿o debería ser el mismo estado de carga? Cada vez que hacemos esto, necesitas repensarlo y entender si queremos compartir estados de carga entre diferentes solicitudes en nuestra aplicación, y esto todavía no responde a un montón de preguntas.

¿Cómo obtener solo cuando data no está en Vuex? Probablemente he escuchado esta solicitud unas 50 veces. ¿Cómo escribir un getter que me devolverá mis data si data está en Vuex y despachará una acción si data no está en Vuex. No existe tal getter. El getter es solo un getter, no queremos cometer un efecto secundario. Es por eso que cada vez que necesitamos implementar este comportamiento en nuestra aplicación, venimos con el mismo conjunto de ruedas. Hacemos esta verificación en el componente, está bien, si esto está en este estado, no voy a despachar una acción, o despachamos una acción, luego la acción verifica el estado, como, está bien, estamos llamando a XSELs, o simplemente regresamos, porque ya tenemos data en nuestro componente. Esto es un poco molesto, porque necesitas volver a implementar esto para un caso tan común en tu aplicación.

El segundo es cómo mantener mis data actualizados. En este caso particular, todavía estamos pensando en VueX como una única fuente de verdad, pero no lo es, porque tu fuente de verdad está en la API. Y el VueX ahora solo es un reflejo del servidor, lo llamo una caché del servidor, datos del servidor, estado del servidor. Este estado pertenece al servidor, y solo intentamos tener este reflejo en nuestro front-end. Y necesitamos mantener este reflejo actualizado.

Si tienes suerte, tienes WebSockets, por lo que en el evento WebSocket, actualizas tu estado VueX. Para aquellos de nosotros que no pueden permitirse WebSockets, hacemos sondeos. Cada 30 segundos, enviamos una solicitud al servidor, desencadenando todos estos cambios de acciones, permutaciones, estado de carga, manejo de errores, y luego actualizamos algo en VueX. Bueno, eso a veces es un desafío. ¿Y si dos componentes comienzan a buscar la misma consulta simultáneamente? Nada explotará, honestamente. Pero tendrás dos solicitudes. Porque VueX no tiene un comportamiento incorporado para desduplicar solicitudes. Ambas se resolverán, y la acción se activará dos veces.

¿Por qué está sucediendo todo esto? ¿Por qué tenemos tantos problemas con el comportamiento asíncrono en VueX? Porque ya no estamos lidiando con el estado local. Estamos lidiando con algo diferente, algo que, en primer lugar, es asíncrono, y necesitamos lidiar con todos los detalles del comportamiento asíncrono. Entonces, estado de carga, estados de error, y todos estos diferentes estados finitos en nuestra aplicación, dependiendo de este comportamiento, algo que se persiste de forma remota, algo que tiene una fuente de verdad fuera de nuestro control como desarrollador de frontend. Y por eso tiene propiedad compartida. Nuestra base de datos en el servidor puede ser actualizada desde otro lugar. Puede ser actualizada por un desarrollador de back-end, pero también puede ser actualizada desde la otra instancia de nuestro cliente frontend. Y necesitamos lidiar con este comportamiento, necesitamos reflejar los cambios del servidor a los cambios al cliente. Y desafortunadamente para nosotros, Vuex no fue diseñado con esto en mente, como Redux no fue diseñado con esto en mente para React. Este no es específicamente un problema de Vuex, es un problema para la mayoría de los administradores de estado.

No todos los estados nacen iguales. Es bueno pensar en lo que consideramos un estado global, algo que está separado de nuestro estado local, por lo que los datos sincrónicos que solo se persisten en la aplicación, algo como los datos del formulario cuando estás llenando el formulario, y la caché del servidor, algo que está presente en la API remota. Y puedes decir ¿cuáles son las alternativas a esto? Entonces, primero consideremos este rápido ejemplo de Vuex en la aplicación que construí. Así que hagamos esto. Así que tengo una aplicación en ejecución, déjame verificar rápidamente a qué dirección en particular vamos, así que empezando una tarea, sí, 3001. Aquí vamos. Y me gusta Dune, me gustan las películas recientes, así que construí una API falsa solo buscando algunos personajes de Dune. Y lo que tenemos aquí, estamos buscando la matriz de personajes en nuestra página principal, aquí va.

Y cuando voy a alguna de las rutas, obtengo un personaje más. ¿Qué está pasando en la aplicación en este momento en particular? En primer lugar, todos los personajes se almacenan en Vuex. Así que aquí va mi aplicación, y vamos a revisar nuestra tienda. Puedes ver que tengo personajes, banderas de carga y error. Estamos listos. Y tenemos este conjunto de mutaciones.

Intenté abstraer esto tanto como fue posible. Tengo el mismo estado de carga para el personaje y los personajes, y también el estado de error, por eso tengo este set loading y set error state, set characters, y set character, que es mi parte favorita, porque aquí estamos seleccionando un personaje de los personajes array por índice, y luego enriquecemos los data. ¿Por qué sucede esto? Vamos a nuestra página de personajes y veamos. Así que nuestros personajes aquí es un array de cosas que normalmente solo contiene un ID y nombre. Cada personaje. Y cuando voy a esta ruta, tengo un montón de data, como descripción, sección, cuando el personaje nació, y cuando vuelvo, tengo, como, Paul y Channing, los revisamos ambos en la aplicación, están enriquecidos por la llamada del personaje.

Y esto es súper frágil. Porque lo que estoy haciendo en mi vista de personaje es que verifico - esto es súper divertido, por cierto - necesito verificar si el personaje ya tiene una descripción, porque si la tiene, no quiero llamar a una acción para buscar personaje, exactamente lo que estaba explicando. Así que estoy verificando si la descripción está ahí, y si no está, envío fetch character y muestro el personaje en mi API. Pero estoy confiando en el hecho de que el array de personajes ya se ha obtenido. Así que creo que esta solicitud se resuelve más rápido que mi personaje. Y hasta ahora, funciona perfectamente en mi aplicación, así que si voy a poll, y puedes ver que los personajes se resuelven más rápido que el personaje individual. Pero puedo imaginar el caso en que los personajes obtienen miles de registros. ¿Y si se resuelve después? No puedo confiar en esto. Este es un comportamiento asíncrono. Construí algo súper, súper frágil en mi parte frontend.

Y también, mira esto. Cuando estoy buscando en poll, siempre obtengo esta lista de personajes primero. Ni siquiera la necesito. Solo necesito POLL o TRADE esto. ¿Por qué estoy obteniendo todos esos? Porque mi herramienta no es perfecta. ¿Cuáles son las alternativas a esto? Bueno, si trabajas con GraphQL, probablemente conozcas Apollo Client, y ya lo mencioné durante esta charla. Apollo Client es increíble si trabajas con GraphQL y si lo usas con Vue 3, la sintaxis se verá algo así. Tienes un use query de tu Apollo Composable.

Y cada vez que llamas a la API, porque esto desencadenará una llamada API en nuestra GraphQL API, tienes resultado cargando un error y muchas más propiedades, pero hasta ahora solo necesitamos esto. Y puedo mostrarlos en mi componente. La mejor parte. Esta consulta almacena la respuesta en la caché. Así que cada vez que la llamo de nuevo desde este componente o cualquier otro componente, por defecto primero golpeará la caché. Y luego si la caché está vacía o algo así, llamará a una API. Este comportamiento puede ser cambiado en la configuración del Cliente Apollo, pero por defecto todo está en caché. Es caché primero.

Si te preguntas qué es charactersQueryGQL, si nunca has trabajado con GraphQL, esto es solo una consulta GraphQL. Y el Cliente Apollo es técnicamente capaz de trabajar con API REST. Puedes crear un resolutor así que cada vez que llamas a una consulta de personajes, en lugar de eso estás simplemente haciendo la llamada para tu API REST con Axios y devolviendo algo que está correctamente formado para nuestra consulta. Lo cual sigue siendo válido, pero es un poco de código repetitivo. Y luego también puedes tener un estado local en el Cliente Apollo. Así que imagina si quieres añadir un personaje. Necesitarías hacer todo esto. Leerás la consulta de la caché, creando tu personaje, creando tu DataObject y tú, porque la Caché Apollo es inmutable, y luego escribes una consulta de vuelta a la caché.

Está bien si tu aplicación no tiene un estado local rico, si es algo super basado en server cache y solo necesitas obtener data del servidor y actualizarlos con mutaciones. Con un estado local, es cuestionable. El código repetitivo aquí es probablemente mayor que en Vuex y tus desarrolladores son más propensos a quejarse de que Vuex era mejor. El problema aquí es que no hay una talla única para todos. Tenemos Vuex que es super bueno en manejar el estado local y es un poco problemático con lidiar con el servidor como puedes ver en esta charla. Pero también tenemos el Cliente Apollo que es genial cuando trabajas con el servidor, principalmente con CraftQL API. Y es un poco más cuestionable cuando necesitamos lidiar con el estado local. Quizás nuestro deseo de tener una única fuente de verdad no es tan grande. Quizás tenemos que manejar dos entidades diferentes y sería bueno tener dos diferentes herramientas.

Entonces, si dejamos Vuex para el estado local, existe una gran herramienta para React que existe desde hace más tiempo, se llama React Query de Tanner Linsley. Pero para Vue, fue creado recientemente porque Tanner expuso el núcleo de React Query y se creó un envoltorio de consulta Vue por Damian Osipiuk. Y quiero hacer una pequeña demostración de esta herramienta ahora mismo en mi charla. Así que, voy a cambiar... Elimino esto y cambio a la rama inicial y vamos a usar Vue query aquí.

Entonces, en nuestro inicio Vue, importaremos el método llamado useQuery de nuestra biblioteca de consultas Vue y también necesitaremos nuestro método getCharacters. Así que, importaré getCharacters de api.js. Y esto es solo una llamada Axios a mi localhost. Así que aquí, comenzaré a usar mi useQuery. Primero, quiero devolver algunos data de useQuery, y aquí, el primer argumento es una clave para la consulta, personajes, y el segundo es mi función de búsqueda, getCharacters. Así que devolvamos data desde la configuración y veamos cómo se ve en nuestra aplicación.

Aquí están mis herramientas de desarrollo, voy a los personajes, y data es un objeto que contiene un array de data de 10 personajes. Así que con esto, puedo usar la magia de lo computado y decir que const characters, oh, ya está aquí, const characters es una propiedad computada basada en el valor de data, porque esto es una referencia, por favor siempre recuerda usar valor con referencias data. Y aquí va mi lista de personajes. Puedo eliminar la devolución de data aquí ahora. Y también, puedo exponer is loading e is error aquí en mi aplicación, en lugar de crear estas dos referencias. Y ahora mismo hay un momento super corto en el que puedes ver loading aquí parpadeando. Y si cometo un error en mi API. Y después de esto, dirá, okay, hay un error justo aquí en la página. Realmente me gusta la idea de los reintentos porque principalmente cuando hay problemas de conectividad, queremos algún tipo de reintento. Esto es básicamente todo para la página de personajes.

Vamos al personaje, uno solo, y hagamos algo similar. Quiero importar getCharacter aquí. Y voy a copiar y pegar el code y modificarlo ligeramente, porque para el personaje, necesitaremos pasar un parámetro adicional a getCharacter, un id. Por eso también eliminaré isError aquí. La sintaxis cambia ligeramente. El primer argumento es ahora un array donde paso props id, y esto viene del router. Y el segundo será un callback donde llamo a getCharacter con este parámetro props id. Aquí vamos.

Y copiaré y pegaré mi data valor data desde aquí. Esta es la API, y reemplazaré el personaje. Así que mi personaje es este, y ya no necesito as loading. Mi personaje se calcula en función del data valor data y hago clic aquí. ¿Qué pasó? Oh, olvidé importarlo calculado. Aquí vamos. Y aquí está Paul Atreides.

Y ahora el momento interesante, voy a los personajes, los personajes se obtienen. Voy a Paul, Paul no se obtiene. Personajes, todos. Personajes, todos porque los data ahora están en la caché de la consulta de vista. Pero aquí viene lo interesante. Tengo un tiempo definido de obsolescencia, lo que significa que todas mis consultas serán obsoletas después de los 20 segundos. Así que durante 20 segundos estamos golpeando la caché. Después de 20 segundos, todos se invalidan y se eliminan de la caché y luego tendré una llamada a la API. Así que ahora cuando voy a los personajes, tengo una solicitud de personajes. Y voy a Paul, aquí va la solicitud de Paul. Por supuesto, esto es como una parte súper pequeña de lo que nuestra consulta de vista puede manejar realmente. Pero espero que haya sido un momento interesante para observar. Y espero que te sumerjas un poco en esta biblioteca y le des una oportunidad. Gracias a todos por asistir a la masterclass. Adiós.

Genial. Muchas gracias por esta charla, Natalia. Echemos un vistazo rápido a los resultados de la encuesta justo antes de pasar a las preguntas y respuestas. Hablamos un poco al principio. Y escuché de ti que no te sorprende realmente el resultado de que la mayoría de las personas dijeron que son tradicionalistas y que usan VueX. ¿Por qué no te sorprende? Bueno, VueX es algo convencional y creo que durante mucho tiempo fue casi la única opción que podías usar Redux. Pero el 99% de las personas que conocía estaban usando VueX. Lo que me sorprende más es lo bien que está funcionando la segunda opción. Felicitaciones a Eduardo porque puedes ver que Pinnia es súper popular en este momento en comparación con VueX. Está superando a Redux, MobX, XState, lo que sea que podamos tener. Quiero decir, GraphQL depende de GraphQL, pero no esperaba que estos fueran tan altos. Siento que algunas personas quieren ser escuchadas porque veo que los porcentajes cambian. Así que parece que la gente decía, espera, no, no somos un montón de tradicionalistas. En realidad somos, realmente, sabes, estamos en la vanguardia. Vamos a darle más voz a Pinnia. Exactamente, hay como un club de fans que quiere que Pinnia lo haga mejor. Así que me encanta eso. Así que gracias a todos por participar en la encuesta. Eso es muy genial. Sí, eso es el 20% ahora, solo mira. Exactamente, ¿podemos mantener esta diapositiva? Estoy súper curioso de dónde estamos al final de las preguntas y respuestas, tengo un par de preguntas para ti, Natalia, una de ellas es, ¿estás usando Vue Query en producción ahora mismo? Creo que nadie está usando Vue Query en producción en este momento. Era súper fresco. Creo que hace unos tres meses, me pregunto si incluso tenemos versiones de Vue porque yo noté que había un núcleo de React Query expuesto. Antes era solo una biblioteca para React, como podrías adivinar por el nombre, como React Query. Expusieron el núcleo y dijeron que ahora es posible construir cualquier tipo de envoltorios para los frameworks. Como no hay, ¿debería intentarlo yo mismo, y luego descubrí que había un chico de Polonia, Damian, ya trabajando en la biblioteca. Estaba trabajando por su cuenta antes de empezar a comunicarse con React Query, pero luego él presentó un prototipo y lo convirtieron en un paquete oficial. Es súper, súper fresco y no recomendaría saltar y llevarlo directamente a producción. Pero sería bueno, creo, que la gente experimentara con él, para probar el enfoque para ver si funciona para ti o no. Porque creo que la idea detrás de esto es genial.

Estuve observando React Query durante mucho tiempo, cómo va, cómo funciona, y es algo bastante grande en el mundo de React en este momento. Así que esperemos que tal vez Vue Query sea algo en el mundo de Vue de manera similar al ecosistema de React. Interesante. Gracias.

Pasemos a algunas de las otras preguntas. Una de Organized Chaos. ¿Tienes algún consejo para decidir qué datos usar y cuándo usar la caché del lado del servidor versus usar local? Bueno, es bastante simple. Si obtienes algo de la API, es un estado del servidor. Así que simplemente va a Vue Query o estado del servidor o lo que sea, cómo quieras separarlo. Y todo lo que tienes en el lado del frontend del cliente va al estado local. Podrías decir, ¿qué pasa si necesito mezclar dos? Entonces, por ejemplo, si tengo algo como un array de propiedades, y quiero insertar una propiedad más a cada entidad, ¿verdad? Si tengo, por ejemplo, un array de libros y estoy creando una lista de libros favoritos, entonces tal vez debería insertar la propiedad es favorito. En este caso particular, diría que almacena los libros en la caché del servidor, como Vue Query. No inyectes ninguna propiedad a ellos. No es la mejor práctica, sinceramente, incluso si estás usando solo Vue. Crea un array separado de ideas como libros favoritos, ideas, y con el mapeo en el componente. Siempre puedes tener cualquier tipo de getter o propiedad computada solo para verificar si el libro es favorito sin agregar una propiedad al array inicial que estás obteniendo. Es algo que aprendí trabajando mucho con Apollo Client porque Apollo Client es muy bueno también manejando la caché del servidor. Al principio, estábamos tratando de modificar cosas en la caché de Apollo con la inserción de propiedades allí. No, no. No funciona de esta manera. Lo que quieras agregar en el cliente, crea una propiedad separada y haz el mapeo después.

Hay una pregunta de Jeroen Heijmans. ¿Cómo cambiaría la historia cuando el usuario interactúa y navega intensamente mientras las solicitudes están en progreso o en otros casos del mundo real? Me encanta esto. Rarezas del mundo real. Como las llamadas que regresan en un orden diferente al que fueron enviadas, por ejemplo. ¿Cuándo se necesitaría algo como una biblioteca extra para sagas o algo similar, si es que se necesita? Es una gran pregunta. Realmente me gusta la parte sobre las rarezas de la vida real. Sí. Para Vue Query, tiene algunos mecanismos avanzados para manejar solicitudes simultáneas y cancelar también, lo cual aparentemente es muy bueno, porque no puede hacer esto ni con Apollo client ni correctamente con Axios si estás usando Vuex, pero maneja las consultas de manera excelente. Como la duplicación, si una consulta está en progreso. Así que incluso para las rarezas de la vida real, hay algunos escenarios avanzados. Porque desafortunadamente, no tuve suficiente tiempo para mostrarlo en la práctica, pero si revisas la documentación, y recomendaría revisar la documentación de React Query en este caso particular porque la documentación de Vue Query no está completa. La gente está trabajando en ello en este momento, y agregando. Pero si revisas React Query para cancelar solicitudes, está allí.

Genial. Genial. Me encanta una de las preguntas que sigue, que es, ¿qué fuente estás usando en VSCode? ¿O qué tema estás usando? Aparentemente a la gente le está gustando. Entonces... Es una gran pregunta. La tengo en cada charla de conferencia que hago, porque a la gente o le gusta o la odia absolutamente, como, tu carácter no es legible, no puedes ni siquiera entender lo que estás escribiendo. Así que es un tema de amor u odio. Estoy usando el tema night all en VSCode de Sarah Dresner. Y la fuente es bank mono. Vale. Veo que mucha gente está cambiando su entorno de VSCode en este momento.

Veamos otra pregunta. ¿Existe una forma de refetch automáticamente los data después de 20 segundos TTL y notificar a los componentes? Creo que puedes agregar el intervalo allí de nuevo. Existe una API en React Query. Entonces puedes hacer lo mismo. Probablemente lo llamaría sondeo. Puedes hacer lo mismo con React en tu consulta. Entonces puedes especificar el intervalo de sondeo allí. Y será sondeado. Sobre notificar a los componentes, se notifica automáticamente. Debido a la reactivity. Entonces tus componentes ya están suscritos a lo que sea que esté en la caché. Puedes pensar en tu consulta en tu componente como un getter. Siempre que se actualiza una consulta, el componente también se actualiza. Porque es reactivo. Y sí, también puedes hacer sondeo. Muy genial.

Mientras esperamos que lleguen más preguntas, definitivamente quiero tocar un tema y satisfacer mi propia curiosidad, ¡GitLab se hizo público! Esta semana, creo. Fue un gran acontecimiento. Así que creo que están en orden las felicitaciones. Fue la semana pasada. Creo que fue el jueves 14. Incluso tuvimos un día libre después de esto. Así que puedes ver que la celebración es real. Gracias. Nos hicimos públicos. Todavía no puedo acostumbrarme a ser una empresa pública ahora. Y fue bastante divertido observar. Quiero decir, transmitimos en vivo el proceso de cotización. Como completamente en NASDAQ. Y fue una locura cuando estás dentro de la empresa y ves a todos celebrando, vistiendo swag, felices por ello. Entonces, sí.

Genial. ¿Así que tuviste pastel y una bebida de tu elección? Sí. Todos lo hicimos. La comida estuvo realmente buena. Eso es muy genial. ¿Esperas algún cambio en tu día a día? Creo que nos enfocamos más en no... Bueno, hay un cambio. Puedo decir con seguridad que probablemente cada empleado, incluyéndome a mí mismo ahora tiene un ticker de NASDAQ ahora revisando los precios de las opciones de acciones porque es interesante. Probablemente nos aburriremos de eso y dejaremos de revisar el precio, pero ahora es muy nuevo y es como, ¿cómo lo están haciendo allí? Entonces, y para los procesos de la empresa, creo que nada ha cambiado. Seguimos siendo una empresa remota relajada con todas las cosas geniales, como días libres limitados y así sucesivamente. No hay nada que se mueva hacia la cultura corporativa. Bueno, creo que es súper interesante y definitivamente voy a seguir y también quiero un ticker, solo por diversión. Genial. Tengo una siguiente pregunta. Tú, sí, tiene que ser una rápida porque nos estamos quedando sin tiempo. ¿Cuál elijo? Tu demo usa Vue 3, ¿podemos usar Vue query con Vue 2 también? Sí, podemos. Funciona con el plugin composition API. Fue una respuesta rápida a una pregunta rápida. Así que eso es genial. Así que muchas gracias por quedarte para la Q&A y también por satisfacer mi curiosidad. Y entonces, sí. Gracias a todos aquí, por favor únete a Natalia en su sala de conferencias en spatial.chat. Si quieres seguir haciéndole preguntas, el enlace para unirte está en la línea de tiempo en vuejslive.com. Y por favor háznoslo saber qué te pareció la charla de Natalia también, una vez que ella dejó el escenario por supuesto. Gracias por invitarme. Tú