Estado Local y Caché del Servidor: Encontrando un Equilibrio

Rate this content
Bookmark

¿Cuántas veces has implementado el mismo flujo en tu aplicación: verificar si los datos ya se han obtenido del servidor, si es así, mostrar los datos, si no, obtener los datos y luego mostrarlos? Creo que lo he hecho más de diez veces yo mismo y he visto la pregunta sobre este flujo más de cincuenta veces. Desafortunadamente, nuestra biblioteca de gestión de estado predeterminada, Vuex, no proporciona ninguna solución para esto.

Para aplicaciones basadas en GraphQL, había una alternativa de usar Apollo Client que proporcionaba herramientas para trabajar con la caché. Pero, ¿qué pasa si usas REST? Afortunadamente, ahora tenemos una alternativa de Vue a la biblioteca react-query que proporciona una buena solución para trabajar con la caché del servidor. En esta charla, explicaré la distinción entre el estado local de la aplicación y la caché local del servidor y realizaré algunas demostraciones en vivo para mostrar cómo trabajar con esta última.

24 min
20 Oct, 2021

Video Summary and Transcription

Esta charla discute el manejo del estado local en el desarrollo de software, especialmente al tratar con comportamiento asíncrono y solicitudes de API. Explora los desafíos de gestionar el estado global y la necesidad de acciones al manejar datos del servidor. La charla también destaca el problema de obtener datos que no están en Vuex y los desafíos de mantener los datos actualizados en Vuex. Menciona herramientas alternativas como Apollo Client y React Query para manejar el estado local. La charla concluye con una discusión sobre la salida a bolsa de GitLab y la celebración que siguió.

Available in English

1. Introducción a la gestión del estado local

Short description:

¡Hola a todos! Hoy vamos a hablar sobre cómo gestionar el estado local de nuestra aplicación cuando se trata de comportamiento asíncrono y solicitudes a la API. Soy Natalia Tepluchina, miembro del equipo principal de Vue.js y ingeniera frontend de Stack en GitLab. ¡Vamos a sumergirnos en ello!

¡Hola a todos! Feliz de 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 cómo gestionar el estado local de nuestra aplicación en los casos en que necesita lidiar con comportamiento asíncrono, solicitudes a la API y cosas por el estilo.

Permítanme presentarme rápidamente. Mi nombre es Natalia Tepluchina. Soy miembro del equipo principal de Vue.js. Trabajo principalmente en la documentación de Vue, por lo que si están leyendo la documentación de Vue 3, es muy probable que estén leyendo algo que yo escribí. Trabajo como ingeniera frontend de Stack en GitLab. Y allí en GitLab, por supuesto, tenemos Vue en nuestro stack de frontend. Pero para los gestores de estado, trabajamos tanto con Vuex, que se mencionará brevemente en esta charla, como con Apollo Client, que también se mencionará brevemente en esta charla. Así que conozco las dificultades de cada solución y tengo una idea de lo que estoy hablando en esta charla en particular, y también soy una experta en tecnologías web de Google.Net.

2. Understanding Global State

Short description:

El estado global es datos que se comparten entre componentes, vistas y rutas en nuestra aplicación. Veamos un ejemplo rápido usando Vuex 4. Tenemos un estado local con una propiedad llamada count, que se puede incrementar mediante mutaciones. Algunas empresas prefieren envolver las mutaciones en acciones para un mejor factorización cuando se trata de comportamiento asíncrono.

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

Echemos un vistazo a un ejemplo muy corto y breve para aquellos que nunca han trabajado con Vuex o han olvidado cómo se ve, y esto será Vuex 4. Si la sintaxis te resulta un poco desconocida, no te preocupes. Es muy similar a Vuex 3 que usamos con Vue 2.

Imagina que tenemos un estado local que devuelve una única propiedad llamada count, y esto es 0. Y necesitamos cambiar esta propiedad de alguna manera, así que agregamos una mutación. Porque todas las propiedades del estado solo deben cambiarse con mutaciones. Entonces tenemos una mutación para incrementar el count. Que simplemente incrementa el count, como sugiere el nombre. Y esto ya es suficiente para usarlo en nuestro componente, pero algunas empresas, como la mía propia, tienen una convención que dice que no podemos realizar mutaciones desde los componentes. Si alguna vez escuchaste que esto es un anti-patrón, esto es incorrecto. Puedes llamar mutaciones, realizar mutaciones, desde los componentes, pero puede dificultar la factorización cuando necesitas comportamiento asíncrono, por eso a veces las envolvemos en acciones. Entonces, este es un boilerplate suficiente para incrementar count.

3. Handling Server Data and Asynchronous Behavior

Short description:

En este ejemplo, tratamos los cambios sincrónicos en el estado y no requerimos una acción. Sin embargo, al tratar con datos del servidor, se vuelve necesario agregar un estado de carga y manejo de errores. Esto complica la estructura simple de una-acción-una-mutación, ya que necesitamos actualizar los estados de carga y error. Múltiples solicitudes pueden requerir diferentes estados de carga, lo que plantea más preguntas.

Lo que estamos tratando aquí en este ejemplo en particular. En primer lugar, tratamos los cambios sincrónicos en el estado, por eso dije que probablemente ni siquiera necesitemos una acción. No tenemos ningún comportamiento asíncrono aquí. No es persistente, así que cada vez que actualizo la página, el recuento vuelve 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 única fuente de verdad mágica, que solo es responsable de los cambios de recuento en nuestra aplicación. El recuento puede cambiarse en cualquier otro lugar. Se almacena solo en Vuex y se cambia solo en Vuex.

Y sí, no crea mucho boilerplate. Este punto puede ser un poco discutible, porque tres propiedades diferentes para cambiar un recuento... Aun así, es una cantidad razonable de boilerplate para este cambio, considerando el hecho de que el recuento se compartirá en toda la aplicación. Pero todo esto no es tan bueno cuando comenzamos a tratar con datos del servidor. Así que agreguemos algunos datos del servidor a la ecuación en nuestro estado de Vuex. Aquí, a primera vista, parece el mismo recuento. Tenemos una propiedad de personajes, tenemos una imitación que cambia los personajes, y tenemos una acción asíncrona que obtiene datos de nuestro punto final de personajes. Y después de esto, realizamos una mutación, así que todo está bien.

Pero con esto, tu aplicación no es suficiente porque obtener personajes es una operación asíncrona , lo que significa que habrá un momento en tu aplicación en el que no haya personajes y estés inactivo. Estás esperando que tu API devuelva tus datos. Y, por supuesto, necesitas agregar un estado de carga, porque necesitamos mostrar este bonito spinner de carga o esqueleto o lo que estés mostrando en tu aplicación. Y también, estamos obteniendo datos de la API. ¿Y qué pasa si la respuesta no está ahí? ¿Qué pasa si tu solicitud no fue exitosa? Necesitamos manejar errores, lo cual es una práctica muy buena para cualquier llamada asíncrona. Y por eso necesitamos agregar una bandera más, un error, a nuestra aplicación. Y con esto, nuestra estructura simple de una-acción-una-mutación ya 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 asíncrono con solicitudes gratuitas. Entonces aquí tenemos como tres estados finitos: un estado de carga, un estado de éxito y un estado de error. Y aquí establecemos la carga en verdadero, el error en falso, así que ahora estamos en el estado de carga. 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. Entonces, en este caso particular, establecemos la carga en falso, decimos que el error es algo que el servidor nos devuelve, seleccionamos tres mutaciones de personajes. Sí, puedes simplificarlo si solo tienes uno, pero si quieres algún tipo de estándar, por lo general, las empresas llegan a algo como esto. Y ahora nuestra acción tampoco es tan simple, porque cuando comenzamos una acción, entramos en este estado de limbo de carga, solicitando un personaje, y luego tenemos personajes, realizamos la mutación de éxito, almacenando los personajes en el estado, y luego, si hay un error, también realizamos una mutación de error, y si te imaginas todo este boilerplate, es bastante grande ya. Entonces 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 haces esto, necesitas reconsiderarlo y comprender si queremos compartir estados de carga entre diferentes solicitudes en nuestra aplicación, y esto aún no responde un montón de preguntas.

4. Fetching Data Not in Vuex

Short description:

¿Cómo obtener datos que no están en Vuex? No existe un getter con este propósito, por lo que tenemos que implementar el mismo comportamiento repetidamente en nuestra aplicación. Puede ser frustrante verificar el estado y despachar acciones cada vez. Este es un problema común que requiere una re-implementación.

¿Cómo obtener datos solo cuando data no está en Vuex? Escuché esta solicitud unas 50 veces probablemente. ¿Cómo escribir un getter que me devuelva mis data si data está en Vuex y despache 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, llegamos con el mismo conjunto de ruedas. Hacemos esta verificación en el componente, si está en este estado, no voy a despachar una acción, o despachamos una acción, luego la acción verifica el estado, como, okay, estamos llamando a XSELs, o simplemente retornamos, porque ya tenemos data en nuestro componente. Esto es un poco molesto, porque necesitas re-implementarlo para un caso tan común en tu aplicación.

5. Keeping Data Up-to-Date in VueX

Short description:

En VueX, mantener los datos actualizados puede ser un desafío. Se pueden utilizar WebSockets o polling para actualizar el estado de VueX. Sin embargo, la deduplicación de solicitudes no está incorporada, lo que resulta en múltiples solicitudes resueltas. El comportamiento asíncrono en VueX plantea desafíos debido a la propiedad compartida y la necesidad de reflejar los cambios entre el servidor y el cliente. VueX no está diseñado específicamente para esto, al igual que otros administradores de estado. Es importante diferenciar entre el estado global, el estado local y la caché del servidor. Veamos un ejemplo de VueX en acción.

El segundo problema es cómo mantener mis data actualizados. En este caso particular, todavía consideramos a VueX como una única fuente de verdad, pero no lo es, porque nuestra fuente de verdad está en la API. Y VueX en este momento es solo un reflejo del servidor, lo llamo una server cache, datos del servidor, estado del servidor. Este estado pertenece al servidor, y tratamos de tener este reflejo en nuestro front-end. Y necesitamos mantener este reflejo actualizado.

Si tienes suerte, tienes WebSockets, por lo que en un evento de WebSocket, actualizas el estado de VueX. Para aquellos que no pueden permitirse WebSockets, hacemos polling. 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 desafiante. Y luego, ¿qué sucede si dos componentes comienzan a buscar la misma consulta al mismo tiempo? Nada explotará, sinceramente. Pero tendrás dos solicitudes. Porque VueX no tiene un comportamiento incorporado para la deduplicación de solicitudes. Ambas se resolverán y la acción se activará dos veces.

¿Por qué sucede todo esto? ¿Por qué tenemos tantos problemas con el comportamiento asíncrono en VueX? Porque ya no estamos tratando con el estado local. Estamos tratando con algo diferente, algo que, en primer lugar, es asíncrono y necesitamos lidiar con todas las complejidades 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 almacena de forma remota, algo que tiene una fuente de verdad fuera de nuestro control como desarrolladores frontend. Y por eso tiene una propiedad compartida. Nuestra base de datos en el servidor puede actualizarse desde otro lugar. Puede ser actualizada por un desarrollador de back-end, pero también puede ser actualizada desde otra instancia de nuestro cliente frontend. Y necesitamos lidiar con este comportamiento, necesitamos reflejar los cambios del servidor a los cambios en el cliente. Y desafortunadamente para nosotros, VueX no está diseñado teniendo esto en cuenta, al igual que Redux no fue diseñado teniendo esto en cuenta para React. Esto no es específicamente un problema de VueX, es un problema para la mayoría de los administradores de estado.

No todos los estados son iguales. Es bueno pensar en lo que consideramos un estado global, algo que está separado de nuestro estado local, como los datos sincrónicos que persisten solo en la aplicación, algo como los datos de un formulario cuando se está completando, y la server cache, algo que está presente en la API remota. Y puedes preguntar, ¿cuáles son las alternativas a esto? Así que primero consideremos este ejemplo rápido de VueX en la aplicación que construí. Así que hagamos esto. Tengo una aplicación en ejecución, permíteme verificar rápidamente a qué dirección específica vamos, así que comenzando una tarea, sí, 3001. Aquí vamos. Y me gusta Dune, me gustan las películas recientes, así que construí una API falsa que obtiene algunos personajes de Dune. Y aquí, estamos obteniendo el arreglo de personajes en nuestra página principal, aquí está.

6. Handling Character Data and Fragile Frontend

Short description:

Y cuando voy a alguna de las rutas, obtengo un personaje más. Todos los personajes se almacenan en Vuex. Tengo el mismo estado de carga para el personaje y los personajes, así como también el estado de error. Selecciono un personaje del arreglo de personajes por índice y enriquezco los datos. Esto es muy frágil. Verifico si el personaje ya tiene una descripción y, si no la tiene, despacho la solicitud de obtener el personaje. Cuando hago la solicitud de obtención, siempre obtengo primero la lista de personajes, incluso si no la necesito. Una alternativa a esto es Apollo Client si trabajas con GraphQL y Vue 3.

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

Estaba tratando de abstraer esto tanto como fuera posible. Tengo el mismo estado de carga para el personaje y los personajes, así como también el estado de error, por eso tengo estos estados de carga establecidos y estados de error establecidos, establecer personajes y establecer personaje, que es mi parte favorita, porque aquí seleccionamos un personaje del arreglo de personajes por índice y luego enriquecemos los data. ¿Qué sucede aquí? Vamos a nuestra página de personajes y veamos. Entonces, nuestros personajes aquí son un arreglo de cosas que normalmente solo contiene un ID y un nombre. Cada personaje individual. Y cuando voy a esta ruta, tengo un montón de data, como descripción, sección, cuándo nació el personaje, y cuando regreso, tengo, como, Paul y Channing, los verificamos a ambos en la aplicación, se enriquecen con la llamada al personaje.

Y esto es muy frágil. Porque lo que estoy haciendo en mi vista de personaje es verificar, esto es muy gracioso, por cierto, necesito verificar si el personaje ya tiene una descripción, porque si la tiene, no quiero llamar a una acción para obtener el personaje, exactamente lo que estaba explicando. Así que estoy verificando si la descripción está ahí, y si no lo está, despacho la solicitud de obtener el personaje y mostrar el personaje en mi API. Pero estoy confiando en el hecho de que el arreglo 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 muy bien en mi aplicación, así que si voy a la encuesta, 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 obtengan miles de registros. ¿Y si se resuelve después? No puedo confiar en esto. Este es un comportamiento asíncrono. Construí algo muy, muy frágil en mi parte del frontend.

Y también, mira esto. Cuando hago la solicitud de obtención, siempre obtengo primero esta lista de personajes. Ni siquiera la necesito. Solo necesito POLL o TRADE esto. ¿Por qué estoy obteniendo todo esto? 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 como esto. Tienes una consulta de uso desde tu Apollo Composable.

7. Handling API Calls and Local State

Short description:

Cada vez que llamas a la API, la consulta primero se guarda en la caché. Apollo Client también puede trabajar con una API REST utilizando un resolvedor. Sin embargo, manejar el estado local con Apollo Client puede ser más complicado que usar Vuex. No hay una solución única para todos. React Query es una excelente herramienta para manejar el estado local en React, y ahora también hay un envoltorio de consulta para Vue.

Y cada vez que llamas a la API, porque esto desencadenará una llamada a la API en nuestra API de GraphQL, tienes resultados de carga, error y muchas más propiedades, pero hasta ahora solo necesitamos esto. Y puedo mostrarlos en mi componente. La mejor parte. Esta consulta guarda la respuesta en la caché. Así que cada vez que la llamo desde este componente o cualquier otro componente, por defecto primero se guarda en la caché. Y luego, si la caché está vacía o algo así, se realiza una llamada a la API. Este comportamiento se puede cambiar en la configuración de Apollo Client, pero por defecto todo está en la caché. Es caché primero.

Si te preguntas qué es charactersQueryGQL, si nunca has trabajado con GraphQL, esto es solo una consulta de GraphQL. Y Apollo Client es técnicamente capaz de trabajar con una API REST. Puedes crear un resolvedor para que cada vez que llames a una consulta de personajes, en lugar de hacer la llamada a tu API REST con Axios y devolver algo que esté correctamente formateado para nuestra consulta. Lo cual sigue siendo válido, pero es un poco de código repetitivo. Y también puedes tener un estado local en Apollo Client. Así que imagina si quieres agregar un personaje. Necesitarías hacer todo esto. Leerías la consulta de la caché, crearías tu personaje, crearías tu objeto de datos y, debido a que la caché de Apollo es inmutable, luego escribirías una consulta de vuelta a la caché.

Está bien si tu aplicación no tiene un estado local complejo, si se basa principalmente en la caché del servidor y solo necesitas obtener datos del servidor y actualizarlos con mutaciones. Con un estado local, es cuestionable. Aquí el código repetitivo probablemente sea mayor que en Vuex y es probable que tus desarrolladores se quejen de que Vuex era mejor. El problema aquí es que no hay una solución única para todos. Tenemos Vuex, que es muy bueno para manejar el estado local pero tiene problemas al tratar con el servidor, como puedes ver en esta charla. Pero también tenemos Apollo Client, que es genial cuando trabajas con el servidor, principalmente con la API de CraftQL. Y es un poco más cuestionable cuando necesitamos manejar el estado local. Tal vez nuestro deseo de tener una única fuente de verdad no sea tan grande. Tal vez tengamos que manejar dos entidades diferentes y sería bueno tener dos herramientas diferentes.

Entonces, si dejamos Vuex para el estado local, hay una excelente herramienta para React que existe desde hace mucho tiempo, se llama React Query de Tanner Linsley. Pero para Vue, se creó recientemente porque Tanner expuso el núcleo de React Query y se creó un envoltorio de consulta para Vue por Damian Osipiuk. Y quiero hacer una pequeña demostración de esta herramienta ahora mismo en mi charla. Así que, cambiaré... Eliminaré esto y cambiaré a la rama inicial y usemos Vue query aquí.

8. Using useQuery to Fetch Data

Short description:

En nuestra aplicación Vue, importamos el método useQuery de la biblioteca de consultas de Vue y el método getCharacters de api.js. Usamos useQuery para obtener datos y devolverlos desde la configuración. Los datos contienen una matriz de 10 personajes, que podemos usar para crear una propiedad computada. También exponemos los estados isLoading y isError en nuestra aplicación. La función useQuery maneja los estados de carga y error, y podemos implementar reintentos para problemas de conectividad.

En nuestra página principal de Vue, importamos el método llamado useQuery de nuestra biblioteca de consultas de Vue y también necesitaremos nuestro método getCharacters. Importaré getCharacters de api.js. Y esto es solo una llamada Axios a mi localhost. Entonces aquí, comenzaré a usar mi useQuery. Primero, quiero devolver algunos datos de useQuery, y aquí, el primer argumento es una clave para la consulta, personajes, y el segundo es mi función fetcher, getCharacters. Así que vamos a devolver datos desde la configuración y ver cómo se ve en nuestra aplicación. Aquí están mis herramientas de desarrollo, voy a los personajes, y los datos son un objeto que contiene una matriz de 10 personajes. Con esto, puedo usar la magia de los cálculos y decir que const characters, oh, ya está aquí, const characters es una propiedad computada basada en el valor de datos, porque esto es una referencia, por favor, recuerda siempre usar value con referencias a datos. Y aquí va mi lista de personajes. Ahora puedo eliminar la devolución de datos aquí. También puedo exponer isLoading y isError aquí en mi aplicación, en lugar de crear estas dos referencias. Y ahora hay un momento muy corto en el que puedes ver que se está cargando aquí parpadeando. Y si cometo un error en mi API. Y después de esto, dirá, okay, hay un error aquí en la página. Realmente me gusta la idea de los reintentos porque la mayoría de las veces, cuando hay problemas de conectividad, queremos algún tipo de reintentos. Eso es básicamente todo para la página de personajes.

9. Using view query for character data

Short description:

Importemos getCharacter y modifiquemos ligeramente el código para pasar un parámetro adicional, id. El personaje se calcula en función del valor de datos. Los personajes se obtienen de la caché de la consulta de vista y, después de 20 segundos, se invalidan y eliminan. Esto es solo una pequeña parte de lo que la consulta de vista puede manejar. ¡Pruébalo!

Vamos al personaje, uno solo, y hagamos algo similar. Quiero importar getCharacter aquí. Y voy a copiar y pegar el código 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. Ahora el primer argumento es un array donde paso las props id, y esto viene del enrutador. Y el segundo será un callback donde llamo a getCharacter con este parámetro id de props. Aquí vamos.

Y copiaré y pegaré mi valor data de aquí. Esto es API, y reemplazaré character. Entonces mi personaje es este, y ya no necesito isLoading. Mi personaje se calcula en función del valor de data y hago clic aquí. ¿Qué pasó? Oh, olvidé importar computed. Aquí vamos. Y aquí está Paul Atreides.

Y ahora el momento interesante, voy a personajes, se obtienen los personajes. Voy a Paul, Paul no se obtiene. Personajes, todos. Personajes, todos porque los datos ahora están en la caché de la consulta de vista. Pero aquí viene lo interesante. Tengo un tiempo de caducidad definido, lo que significa que todas mis consultas caducarán después de 20 segundos. Así que durante 20 segundos estamos obteniendo los datos de la caché. Después de 20 segundos, se invalidan y eliminan todos de la caché y luego haré una llamada a la API. Así que ahora, cuando voy a personajes, tengo una solicitud de personajes. Y voy a Paul, aquí va la solicitud de Paul. Por supuesto, esto es solo una pequeña parte de lo que nuestra consulta de vista puede manejar. Pero espero que haya sido un momento interesante para ver. Y espero que se adentren un poco en esta biblioteca y lo prueben. Gracias a todos por asistir a la charla. Adiós.

10. Resultados de la encuesta y Vue Query

Short description:

Echemos un vistazo rápido a los resultados de la encuesta. VueX es algo común y durante mucho tiempo fue casi la única opción. Pinnia es muy popular en este momento, superando a Redux, MobX, XState e incluso GraphQL. Es genial ver cómo la gente está adoptando nuevas opciones. Gracias a todos por participar en la encuesta. Vue Query es una nueva biblioteca que permite construir envoltorios para diferentes frameworks. Aunque aún está en las primeras etapas, vale la pena experimentar con ella.

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. Ya hemos discutido un poco al respecto. Y escuché de ustedes que no están realmente sorprendidos por el resultado de que la mayoría de las personas dijeron que son tradicionalistas y usan VueX. ¿Por qué no están sorprendidos? Bueno, VueX es algo común 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 usaban VueX. Lo que me sorprende más es lo bien que está funcionando la segunda opción. Felicitaciones a Eduardo porque se puede ver que Pinnia es muy popular en este momento en comparación con VueX. Supera a Redux, MobX, XState, cualquier cosa que podamos tener. Quiero decir, GraphQL depende de GraphQL, pero no esperaba que fueran tan altos. Siento que algunas personas quieren ser escuchadas porque veo que los porcentajes cambian. Parece que la gente estaba como diciendo: espera, no somos un grupo de tradicionalistas. En realidad, somos vanguardistas. Démonos más voz a Pinnia. Exactamente, hay como un club de fans que quiere que Pinnia lo haga mejor. Me encanta eso. Así que gracias a todos por participar en la encuesta. Eso es muy genial. Sí, ahora es el 20%, solo mira. Exactamente, ¿podemos dejar esta diapositiva aquí? Estoy muy curioso por saber dónde estaremos al final de las preguntas y respuestas, tengo un par de preguntas para ti, Natalia, una de ellas es si estás usando Vue Query en producción en este momento. Creo que nadie está usando Vue Query en producción en este momento. Es muy nuevo. Creo que hace unos tres meses, me pregunto si siquiera tenemos versiones de Vue porque noté que había un núcleo de React Query expuesto. Antes era solo una biblioteca para React, como puedes imaginar 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 que no debería intentarlo yo mismo, y luego descubrí que había un chico de Polonia, Damian, que ya estaba trabajando en la biblioteca. Él estaba trabajando por su cuenta antes de comenzar a comunicarse con React Query, pero luego él trajo un prototipo y lo convirtieron en un paquete oficial. Es muy, muy nuevo y no recomendaría saltar y usarlo directamente en producción. Pero sería bueno, creo, que la gente experimente con él, pruebe el enfoque para ver si funciona para ti o no. Porque creo que la idea detrás de esto es genial.

11. React Query, Vue Query y Manejo de Datos

Short description:

He estado observando React Query durante mucho tiempo, cómo va, cómo funciona, y es algo importante en el mundo de React en este momento. Así que espero que tal vez Vue Query sea algo similar en el mundo de Vue, como el ecosistema de React. 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 en lugar de usar datos locales? Bueno, es bastante simple. Si obtienes algo de la API, es un estado del servidor. Cualquier cosa que tengas en el lado del cliente va al estado local. Si necesitas combinar los dos, crea una propiedad separada y haz el mapeo después.

He estado observando React Query durante mucho tiempo, cómo va, cómo funciona, y es algo importante en el mundo de React en este momento. Así que espero que tal vez Vue Query sea algo similar en el mundo de Vue, como el 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 en lugar de usar datos locales? Bueno, es bastante simple. Si obtienes algo de la API, es un estado del servidor. Así que simplemente va a Vue Query o al estado del servidor o como quieras separarlo. Y cualquier cosa que tengas en el lado del cliente va al estado local. Podrías decir, ¿qué pasa si necesito combinar los dos? Por ejemplo, si tengo algo como un array de propiedades y quiero insertar una propiedad más en cada entidad, ¿verdad? Si tengo, por ejemplo, un array de libros y estoy creando una lista de libros favoritos, tal vez debería insertar la propiedad esFavorito. En este caso particular, diría que almacenes los libros en la caché del servidor, como Vue Query. No inyectes ninguna propiedad en ellos. No es la mejor práctica, sinceramente, incluso si solo estás usando Vue. Crea un array separado de ideas como libros favoritos, ideas, y haz el mapeo en el componente. Siempre puedes tener algún tipo de getter o propiedad computada 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 también es muy bueno manejando la caché del servidor. Al principio, intentábamos modificar las cosas en la caché de Apollo insertando propiedades allí. No, no. No funciona de esta manera. Cualquier cosa que quieras agregar en el cliente, crea una propiedad separada y haz el mapeo después.

12. Manejo de Solicitudes Simultáneas y Cancelación

Short description:

Para Vue Query, tiene mecanismos avanzados para manejar solicitudes simultáneas y cancelarlas. Maneja las consultas de manera excelente, incluso en escenarios extraños de la vida real. Consulta la documentación de React Query para cancelar solicitudes.

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 u otras situaciones de la vida real? Me encanta esto. Extrañeza de la vida real. Como llamadas que regresan en un orden diferente al que fueron enviadas, por ejemplo. ¿Cuándo sería necesario algo como una biblioteca adicional para sagas o algo similar, si es necesario en absoluto? Es una gran pregunta. Realmente me gusta la parte sobre la extrañeza 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 el cliente Apollo 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. Entonces, incluso para situaciones extrañas de la vida real, hay algunos escenarios avanzados. Por desgracia, no tuve suficiente tiempo para mostrarlo en la práctica, pero si consultas la documentación, y recomendaría consultar la documentación de React Query en este caso particular, porque la documentación de Vue Query no está completa. Las personas están trabajando en ello en este momento y agregando. Pero si consultas React Query para cancelar solicitudes, está ahí.

13. Tema y Fuente de VSCode

Short description:

Estoy usando el tema night all en VSCode de Sarah Dresner. Y la fuente es bank mono.

Genial. Genial. Me encanta una de las preguntas que viene a continuación, que es, ¿qué fuente estás usando en VSCode? ¿O qué tema estás usando? Aparentemente a la gente le gusta. Entonces... Es una gran pregunta. La tengo en cada charla de conferencia que hago, porque a la gente le gusta o la odia , como, absolutamente, como, tu carácter no es legible, ni siquiera puedes 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. De acuerdo. Veo a mucha gente cambiando su entorno de VSCode en este momento.

14. Automated Data Refetch and Component Notification

Short description:

¿Existe alguna forma de volver a obtener automáticamente los datos después de un TTL de 20 segundos y notificar a los componentes? Sí, puedes lograr esto utilizando la opción de intervalo en React Query. Al especificar el intervalo de sondeo en tu consulta, los datos se volverán a obtener automáticamente. Los componentes se notifican automáticamente debido a la reactividad, ya que están suscritos a la caché. Esto permite que los componentes se actualicen cada vez que se actualiza la consulta. El sondeo es una función genial que se puede implementar.

Veamos otra pregunta. ¿Existe alguna forma de volver a obtener automáticamente los data después de un TTL de 20 segundos y notificar a los componentes? Creo que puedes agregar el intervalo allí nuevamente. Hay una API en React query. Entonces puedes hacer lo mismo. Probablemente lo llamaría sondeo. Puedes hacer lo mismo con React en tu consulta. Así que puedes especificar el intervalo de sondeo allí. Y se realizará el sondeo. En cuanto a la notificación de los componentes, se notifica automáticamente. Debido a la reactividad. Por lo tanto, 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. Cada vez que se actualiza una consulta, el componente también se actualiza. Porque es reactivo. Y sí, también puedes hacer sondeo. Muy genial.

15. GitLab Going Public

Short description:

GitLab recientemente salió a bolsa y fue un gran acontecimiento. La empresa celebró con una transmisión en vivo del proceso de cotización en NASDAQ y el ambiente estaba lleno de emoción y felicidad. Aún es una experiencia nueva para nosotros ser una empresa pública y todos nos estamos adaptando a esta nueva realidad.

Mientras esperamos que lleguen más preguntas, quiero tocar algo y satisfacer mi propia curiosidad, ¡GitLab salió a bolsa! Creo que fue esta semana. Fue un gran acontecimiento. Así que creo que merecen 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. Salimos a bolsa. Aún no puedo acostumbrarme a esto de ser una empresa pública. Y fue bastante divertido de observar. Quiero decir, transmitimos en vivo el proceso de cotización. Completamente en NASDAQ. Y fue una especie de locura cuando estás dentro de la empresa y ves a todos celebrando, usando merchandising, siendo felices al respecto. Así que, sí.

16. GitLab Going Public Celebration

Short description:

Tuvimos pastel y bebidas para celebrar que GitLab salió a bolsa. El único cambio es que los empleados ahora tienen tickers para verificar los precios de las opciones de acciones. Los procesos de la empresa siguen siendo los mismos y seguimos siendo una empresa remota relajada. Es súper interesante y estoy emocionado de seguir adelante.

Increíble. ¿Así que tuvieron pastel y una bebida de elección? Sí. Todos lo tuvimos. La comida estuvo muy buena. Eso es 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í en este momento, tiene un ticker de NASDAQ ahora mismo para verificar los precios de las opciones de acciones porque es interesante. Probablemente nos aburriremos y dejaremos de verificar el precio, pero ahora mismo es algo nuevo y es como ver cómo lo están haciendo allí. Y en cuanto a 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 demás. No hay cambios en la cultura corporativa. Bueno, creo que es súper interesante y definitivamente voy a seguirlo y también quiero un ticker, solo por diversión. Increíble. Tengo una siguiente pregunta. Tienes, sí, tiene que ser rápida porque se nos está acabando el tiempo. ¿Cuál quiero elegir? Tu demo usa Vue 3, ¿podemos usar Vue query con Vue 2 también? Sí, podemos. Funciona con el complemento de la API de composición. Fue una respuesta rápida a una pregunta rápida. Así que eso es genial. Muchas gracias por quedarte para la sesión de preguntas y respuestas y por satisfacer mi curiosidad también. Y bueno, sí. Gracias a todos aquí, por favor únanse a Natalia en su sala de conferencias en spatial.chat. Si quieren seguir haciéndole preguntas, el enlace para unirse está en la línea de tiempo en vuejslive.com. Y por favor, hágannos saber qué les pareció la charla de Natalia también, una vez que ella se haya retirado del escenario, por supuesto. Gracias por tenerme. Tú

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

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.