Panel discussion: State Management

Hola, y primero que todo, hola, soy Vanessa. En comparación con esas personas hermosas a mi lado, en esta dirección, creo que no soy un miembro clave. Tampoco estoy realmente en el código abierto. Lo siento mucho, pero comencé mi viaje con Vue.js en 2017 y me ha encantado desde entonces. Supongo que como la mayoría de las personas aquí en la conferencia. Y una de mis experiencias clave fue cuando añadí Vue.x, cuando finalmente añadí Vue.x, que tenía miedo de usarlo antes porque pensé que la gestión del estado sonaba complicado. Y creo que hice muchas cosas muy complicadas antes. Simplemente hice lo simple de añadir Vue.x.

Antes de entrar en las discusiones, quiero saludar a Kia y Eduardo y empezar tal vez, Kia, contigo, puedes presentarte rápidamente y saludar a todos. Está bien. Gracias, Vanessa. Hola a todos. Soy Kia. Soy miembro del equipo central de Vue.js y estoy muy emocionado de estar aquí. Así que espero que tengamos mucha diversión. Sí. Espero que tú también. Está bien. Y hola, Eduardo. Hola. Bueno, creo que solo necesitas hablar antes. Sí. Te presentaste antes. Así que para todos los que se lo perdieron, vean la grabación de la increíble charla de Eduardo antes. Y Eduardo, así que tendría mi primera pregunta para ti.

Antes de entrar en la pregunta de detalle, pensé que comenzaríamos con la pregunta más complicada de todas. ¿Qué es la gestión del estado? La gestión del estado es una estrategia que utilizas para lidiar con un estado que está fuera de los componentes en tu aplicación. Ese es el punto clave. La pista está en el título. Así que todo lo que no pertenece a un componente, todo lo que va más allá de la vida del componente, todo lo que, no tiene que ser, no hay regla sobre las características o el negocio, la lógica pertenece a, pero se trata de especificidades es el estado que no puede estar en un componente.

Tiene que estar fuera. Así que necesitas algo para gestionarlo. Necesitas una forma, una estrategia para gestionar ese estado, interactuar con él, leer, escribir, etcétera. ¿Dirías entonces que el estado es siempre algo que es global o también puede haber un estado local? Hay un estado local. Sí, los componentes tienen estado local, ¿verdad? Tiene sentido. Está bien, y dado que ahora está Vue tres, si pienso en Vue dos, pienso en la tienda de gestión del estado, Vuex, ¿ha cambiado algo? Y sé que vimos la charla antes sobre Pinya, pero ¿ha cambiado algo en general desde que tenemos Vue tres en lo que respecta a la gestión del estado en Vue? ¿Quién debería responder esto? Kia. Está bien, está bien. Así que en términos de gestión del estado, si incluimos Vue tres dentro de la gestión del estado, hay una nueva API de composición. Así que esta API de composición, y más específicamente W3 tiene este nuevo paquete de reactividad. Y de hecho, puedes usar este paquete fuera de Vue. Y esto proporciona un sistema reactivo básico de Vue. Y hace prácticamente lo mismo que solías hacer en Vue dos. En Vue dos, tenías la API de opciones, definías como propiedad de datos y se volvía reactivo. Pero ahora puedes importar el paquete de reactividad independientemente de Vue. Y puedes definir muchos tipos de objetos reactivos como ref reactivo, computado y demás. Así que esa es una gran novedad en Vue. En términos de Vue X, de hecho hay una versión cuatro de Vue X que es compatible con la versión Vue tres. Pero no ha cambiado nada. Solo una ligera diferencia entre la versión dos de Vue es la lógica de instalación, creo. Pero otras cosas permanecen bastante iguales. Así que en términos de Vue X en este momento, no hay una gran diferencia con respecto a Vue dos. En otras palabras, puedes migrar de Vue X tres a Vue X cuatro bastante fácilmente. Puedes hacerlo de manera directa. Pero en términos de lo que viene a continuación es PNF. Actualmente está creado por Eduardo y esa es la nueva cosa. Y también Vue X cinco, estas dos comparten la misma cosa, pero esta es la nueva cosa que viene a Vue tres como una herramienta de gestión del estado global. Muy bien. Ahora hemos dicho, creo que Pinya ya 10 veces. Y haré la pregunta a, y como para todos los que no han visto la charla antes y para decir en una o dos, tres, cinco oraciones qué es en realidad. Pero lo que me gustaría saber, así que en Vue dos solo había Vue X para mí como el método de referencia para tener gestión del estado.

Intenté, como dije al principio, algunas cosas raras de antemano. Como en realidad intenté mal utilizar el elemento raíz de Vue para agregar variables globales allí hasta que descubrí que, oh, esto no es reactivo. Y hice mucho prop trailing al principio. Así que estas cosas donde tienes props, props, props son mucho mejores con Vuex. Pero cuando empiezo ahora un proyecto completamente nuevo con Vue3, ¿irías inmediatamente por Vuex? ¿Quizás por Pinia de la que hablaremos? ¿O hay también otras técnicas nuevas de las que aún no sabemos? Kia?

Bueno, en este momento, si puedes, yo creo que deberías comenzar con Pinia cuando necesites una tienda, porque esa es el futuro de Vuex o esa es la dirección a la que va Vue. Pero también, ¿por qué recomiendo Pinia? Es que es muy simple. Y creo que es la forma más simple de tienda global que proporciona Vue, y con todo el soporte de renderizado del lado del servidor y soporte de devtool, y todo listo para usar. Y no estoy diciendo que otras herramientas de gestión del estado sean malas opciones o no adecuadas para Vue.

Pero es que simplemente otras gestiones del estado suelen ser mucho más complicadas, incluso como Vuex4. Así que tal vez el nivel de dificultad sea Pinia, Vuex4 y XState y otras cosas. Así que creo que para el primer paso, creo que la gente debería acercarse a Pinia. Y si necesitan un sistema de gestión del estado más poderoso o, debería decir, un sistema de gestión del estado más opinado, entonces pueden acercarse. Si quieren una arquitectura Flux, pueden usar Vuex4. Si necesitan más como un tipo de máquina de estados en la gestión del estado, van a XState o LovatzJS. Así que creo que la primera opción debería ser Vue o Pinia. Y espero que, en el futuro, tal vez Vuex5. No lo sé.

Esa es una gran respuesta. Así que dejamos de bailar alrededor de la palabra Eduardo. ¿Qué es Pinia? Pinia es una alternativa de tienda. Así que es una biblioteca para Vue. Es como Vuex. Es una biblioteca de tienda. No es Flux. Es mucho más simple. Es incluso menos opinada que Vuex, que ya no lo es. Quiero decir, Vuex4 y anteriores. Y fue inicialmente un experimento que fue hace dos años para tener algo, así que una tienda que tiene una API que funciona con TypeScript directamente, usando la API de composición. Así que comenzó como algo para Vue 2. Y hoy funciona tanto con Vue 2 como con Vue 3. Y fue mi visión de cómo tener una solución de gestión del estado que pueda escalar. Así que puede ser utilizada para aplicaciones que crecen porque puedes tener todas las diferentes tiendas, pero también puede escalar hacia abajo de la manera que, como dice Kia, es simple, es muy simple. Así que realmente puedes ponerlo en una pequeña aplicación y no obtienes un gran overhead por ello. Incluso iría más allá que Kia y diría que incluso puedes comenzar sin usar nada. Puedes comenzar usando, si no tienes servicio al renderizar, entonces puedes simplemente usar un objeto reactivo y algunas funciones, y dividir, como estabas diciendo, el paquete de reactividad. Quiero decir, no importas de la actividad, de ti si estás en una nueva aplicación.

Así que PINIA es una biblioteca de tienda para Vue 2 y Vue 3 con un enfoque en la experiencia de desarrollo. Así que ahora que tiene, la API para definir tiendas es la misma para Vue X5, o al menos el RFC, estamos bastante alineados. Como creo que tal vez el nombre, el ID clave, porque estamos pasando como el primer parámetro, todo es lo mismo. Como podrías copiar y pegar el código y tener lo mismo, solo cambia la importación y funcionará. Y luego hay diferencias con Vue X5 es la arquitectura de plugins, el reemplazo de módulo caliente, pero probablemente Vue X5 tendrá lo mismo. Y luego las pruebas, pero creo que será muy fácil mantener algo compatible al menos para las pruebas. Los plugins, creo que necesitamos ir por un RFC, y luego adaptaré PINIA para que en algún momento, ya sea que PINIA ofrezca algo sobre Vue X, o se convierta en Vue X. Así que no tiene que ser mantenido más. Así que para aplicaciones muy pequeñas, así que no estoy seguro si soy el único, pero estoy usando Vue.js sin renderizado del lado del servidor. Lo uso como el jQuery moderno en algunos puntos. Me gustaría tener solo esta propiedad reactiva simple que uso y comparte el estado local y global con ella a través de diferentes componentes.

Lo que pensé mientras escuchaba, está bien, ahora hay Vue X y ahora hay Pinya. Eduardo, ¿tienes miedo de que pueda haber un pensamiento similar a React sobre eso como con Redux y MobX, como el equipo de Redux y el equipo de MobX? ¿Qué podríamos hacer todos para no tener dos equipos, sino simplemente decir, está bien, algunas personas trabajan mejor con Vue X y algunas personas trabajan mejor con Pinya? No, porque la diferencia entre MobX y Redux o ¿cuál era el otro que dijiste? ¿Redux? Son fundamentales, como cuál es el término en inglés. Tienen una diferencia fundamental en la forma en que piensas y organizas. La API es completamente diferente. Vue X y Pinya tienen la misma API. El objetivo de Pinya es encontrar una manera de usar, de beneficiarse de la API de composición. Y la razón por la que Vue X es tan simple o está apuntando a ser tan simple es porque no necesitas tanto. Y Kia está trabajando en el SSR, que es una de las partes más complicadas, creo, como la parte de iteración de Revs, objetos reactivos. Esa parte no es utilizada por Pinya en este momento. Así que creo que eso es algo... Incluso esa parte podré usarla igual que Vue X. Si Vue X va en esa dirección, va a ser mejor que Pinya. No va a ser peor. Va a ser tan bueno como Pinya o mejor. Así que voy a adaptar Pinya para que coincida con eso. Así que no es como si una persona que hace una tienda con Pinya tuviera algo que aprender con Vue X5, que no es el caso de MobX y Redux porque son fundamentalmente diferentes en la forma en que incluso piensas en ello. Y además, realmente no tienes que aprender mucho. Como, cuando ves una tienda definida con Vue X, Pinya, getters de estado, acciones, es bastante autoexplicativo. Si usas la API de funciones, solo estás creando un componente que no renderiza nada, ¿verdad? Es como una función de configuración. Así que solo creas un computador de Redux dentro de tu watch, lo que quieras. Entendido. Así que estamos mirando hacia un futuro brillante sin guerras entre dos equipos. Sí. Eduardo, ¿qué responderías, o qué les dirías a las personas si ahora están en su empresa hablando con sus colegas, teniendo como una solución segura y proponiendo usar a partir de ahora Pinya en lugar de Vue X en este cierto proyecto? Si alguien dice, sí, pero es algo nuevo, no sé si ya hay mejores prácticas. Y creo que es solo como, hay un tipo implementándolo y ¿qué pasa si decide hacer algo más ahora? Así que no es nuevo per se. Tiene dos años. Planeaba lanzar una versión estable hoy, pero surgieron todas las cosas, así que no lo hice. La razón así que no es nuevo. Tienes un soporte de tipo mucho mejor. Como que vas a tener una vida un poco más fácil desarrollando con Pinya que con Vue X3 y 4.

Y lo sabemos. Así que a menos que tengas, la única razón para no usar Vienya es que tienes una base de código existente. Así que para eso existe UX4. Es porque de esa manera las personas pueden migrar a Vue 3 sin tener que cambiar la tienda. Así que eso es muy importante. Pero en realidad puedes usar ambos al mismo tiempo. No se contradicen. Así que puedes hacer una migración parcial. He visto aplicaciones que hacen una migración parcial. Sí, una migración parcial, así que usan ambos. Honestamente, como decimos con tantas cosas, pruébalo. Solo mira a los perros y pruébalo tú mismo. Y cuando veas todas esas cosas también en conflicto sin que tengas que escribir nada, comenzarás a disfrutar de la biblioteca y a preguntarte, está bien, ¿por qué no comenzamos antes a usar esto? También funciona para Vue, por cierto.

Genial. Así que también para sacar la siguiente pregunta del camino, tanto Vuex como Pinja funcionan para cualquier tipo de tamaño para los proyectos, como entendí ahora desde aplicaciones pequeñas hasta grandes páginas de comercio electrónico. Así que no hay una decisión como, está bien, tomo Vuex para aplicaciones grandes, y Pinja solo para las pequeñas. Sí, no, es lo mismo. Otra cosa. No sé qué quieres decir, qué piensas. Creo que sí. Uno u otro. Sí, todo depende de lo que estés construyendo, realmente. Y cuando hablamos de gestión del estado, creo que la gente tiende a pensar que para aplicaciones grandes, necesitamos gestión del estado. Y para las aplicaciones pequeñas, no necesitamos gestión del estado o no deberías usar gestión del estado. Pero en parte no estoy de acuerdo con esto porque estoy de acuerdo en que cuanto más grande se vuelve la aplicación, se vuelve más complicada. Así que hay una alta probabilidad de que se necesite una tienda global, pero no es 100% el caso, ¿verdad? E incluso si tienes una aplicación muy, muy pequeña, podría tener un estado global simple, por ejemplo, como la configuración de la aplicación, o tal vez alguna información de sesión, como el usuario que ha iniciado sesión ahora o no. Así que para esa información, creo que incluso si tu aplicación es tan pequeña, aún necesitas una tienda. Y en esa situación, creo que Pinior o BX Five, y esas pequeñas gestiones de estado simples se vuelven muy útiles, puedes simplemente usarlas y obtienes todos los beneficios. E incluso si tu aplicación se vuelve tan enorme, si tu aplicación es tal vez, digamos, como una aplicación muy funcional, donde no hay mucho estado, todo lo que haces es cálculo, y aunque la aplicación sea enorme, no hay tanto estado en la aplicación, entonces tal vez no necesites ninguna gestión del estado, ¿verdad? Así que realmente depende de qué tipo de gestión del estado requiere tu aplicación. Y creo que Vue se está moviendo actualmente hacia lo que se convertirá en algo más simple.

Así que actualmente Vue 2, cuando necesitas una tienda global, necesitamos usar VueX, y VueX actualmente tiene esta arquitectura Flux. Así que hay una gran, esta brecha tecnológica, ¿verdad? Vas del estado local de Vue a la arquitectura Flux. Así que ahora tienes que aprender la arquitectura Flux solo para hacer una gestión de tienda super simple. Pero estamos tratando de bajar esta barrera. Para PINIA y VueX 5, vamos a hacer que la gestión del estado sea mucho, mucho más simple y fácil de usar. Pero no necesariamente, estamos diciendo que la arquitectura Flux es mala o algo así. Es solo que la arquitectura Flux es más opinativa, tiene más reglas. Tiene ciertas formas de usar la tienda, y podría ser la mejor opción para tu proyecto y tal vez no, pero la clave es que tienes que elegir para tu proyecto, ¿verdad? Qué tipo de gestión para la gestión del estado necesitas. Así que creo que es una cuestión de elección, y estamos tratando de agregar una opción más simple entre ir a la arquitectura Flux completa y la gestión de tienda simple. Y creo que esto va a hacer que este ecosistema de tienda sea mucho, y los costos de aprendizaje y todo mucho más lineales, creo que para las vistas gratis.

Así que pasando de la decisión, todos allá afuera usen lo que les guste. Prueben ambos, y también háganos saber en Twitter y en todas partes por qué opción van a elegir. Pero ya que ahora estamos hablando de Ikea, lo que acabas de decir sobre que a veces aplicaciones muy pequeñas necesitan gestión del estado, y a veces las más grandes pueden no necesitarlo en absoluto. ¿Diferencias entre el estado de UI y el estado de lógica de negocio de datos, como si obtienes algo de los endpoints, lo almacenas en un lugar diferente cuando tu lógica de UI, como, está bien, se está cargando, se hizo clic, se mostró, el usuario ha iniciado sesión, etcétera?

Bueno, yo diferencio el estado de datos y el estado de UI, pero creo que a veces es difícil diferenciar dentro de la tienda. Por ejemplo, tiendo a gestionar todo el estado de UI dentro del componente de Vue, pero por ejemplo, hay algún componente de UI global, como, por ejemplo, un snack bar, mostrado en el botón de luz roja en la ventana, como cosas de notificación. Y esas cosas son como UI global, porque la notificación ocurre, y no importa lo que hagas en la UI, tiene que quedarse ahí. Así que realmente no puedes poner este estado en el componente, ¿verdad? Necesitas tener este estado en la tienda. En ese sentido, a veces algunos estados de UI tienen que ir a la tienda, pero aparte de eso, la mayor parte del tiempo, siempre trato de poner el estado de UI en el componente y nunca ponerlos en la tienda de Vuexel, a menos que sea absolutamente necesario. Y para los datos, porque soy el autor de Vuexel, generalmente pongo todos los datos, por ejemplo, como usuarios o publicaciones o cualquier tipo de datos en la tienda, porque generalmente esos datos provienen del lado del servidor, lo que llamas la API, y obtienes los datos del servidor.

Y cuando lo piensas, el servidor es estado global, ¿verdad? No sabes qué vas a obtener hasta que accedes a la API. Así que para mí, realmente tiene sentido almacenar esos datos en la tienda global porque es estado global, quiero decir, en el estado del lado del servidor. Pero creo que todo se reduce a preferencias, pero eso es lo que a menudo hago con mi propio proyecto, sí.

Eduardo, ¿te gustaría agregar algo a la pregunta? Estoy de acuerdo con el estado de UI, puedo hacer lo mismo. A veces, en casos muy específicos, sales del componente, pero tanto como sea posible, en algunos de los componentes, las llamadas a la API dependen de la aplicación. Significa que algunas llamadas a la API, puedes almacenarlas en caché y usar una caché local, así que puedes hacer una revalidación escalonada de cosas para que la aplicación parezca realmente rápida. Quiero decir, o como si tuvieras los datos antiguos de inmediato y vuelves a solicitar, y así es muy fluido.

Pero muy a menudo, solo hago los componentes para aplicaciones simples. Y luego, si tengo más tráfico u otras cosas, añado una capa de caché. Generalmente, esa capa de caché. Así que hay múltiples capas de caché. La caché es un tema realmente complicado. Así que también tienes la caché del servidor, que es mucho más importante que la caché del lado del cliente. Pero también puedes usar algo de caché del lado del cliente para mejorar la experiencia del usuario. Y creo que siempre empiezo fuera de la capa del servidor de la tienda si puedo, a menos que necesite usar ese estado de inmediato en múltiples lugares o múltiples páginas. Página de usuario, por ejemplo.

Está bien. Así que la siguiente pregunta de proyectos reales allá afuera. Si tienes un componente y obtienes algo de la tienda allí, si es UX, lineal, o composable, lo que sea. Y luego tienes un par de componentes hijos que también necesitan un objeto de la tienda. ¿Preferirías, en cada componente hijo, acceder a la tienda para obtener el mismo objeto global de nuevo? ¿O preferirías, entonces, usar una propiedad para pasar este objeto hacia abajo a un componente, un componente hijo que no sabe que existe una tienda aquí? Ya tienes, te veo. Muy, muy buena pregunta. Y realmente no tengo una respuesta clara para esto. Me encantaría escuchar lo que piensa Eduardo sobre esto y cómo lo haces en tu proyecto. Pero generalmente prefiero obtener todos los datos de la tienda en el componente de la página. Así que sabes, en el componente de nivel superior y pasar esos datos al componente hijo como props. Pero a veces podrías querer tener, podrías querer acceder a la tienda desde el componente hijo. Y por ejemplo, cuando estás construyendo una página de dashboard, ¿verdad?, y tienes muchos tipos diferentes de datos mostrados en el dashboard. Y en este tipo de caso, si obtienes todos los datos en el componente padre, entonces el componente padre se vuelve realmente enorme porque este componente tiene que obtener todos los datos para su propio componente hijo, ¿verdad? Así que en estos tipos de casos, es mucho más simple crear un componente hijo que obtenga su propio estado global. Y por cierto, va exactamente igual al problema de codificación de la API. ¿Debería el componente hijo llamar a la API o el componente padre llamar a la API y pasar las props? Creo que es el mismo problema exacto pero aún no sé la respuesta pero prefiero pasar como props pero todavía estoy evaluando si es una buena idea acceder a ese estado global en el componente hijo o no. Realmente no lo sé. ¿Qué piensas Eduardo? Creo que la mayoría, como el 80% de las aplicaciones hacen unas pocas como una, dos llamadas a la API y lo haces a nivel de página. Puedes tener otras aplicaciones muy complejas pero eso ni siquiera es el 20% como el 1% de la aplicación o el 5% de las aplicaciones. Y generalmente optimizan mucho su API. Así que puedes hacer muchas llamadas a la API y luego haces esas llamadas a la API de una manera más localizada. Así que vas al componente hijo. Generalmente, en mis aplicaciones no tengo esa complejidad, creo de hacer tantas solicitudes a la API. Así que hago una a nivel de página. Creo que es mucho más fácil de manejar. Y si puedo pasarlo como una prop, lo paso como una prop. Así que ni siquiera necesito la tienda. Evito hacer lo que he visto llamado como prop, grading.

No creo una prop en un componente si no usas una prop, el componente. En Vue 3 y con una API de composición tienes un acceso más fácil para inyectar proporcionar pero prefiero evitarlas en la mayoría de los casos. Como es más, prefiero usarlo para el estado de la UI y componentes como un interactuando, por ejemplo un componente de tiempo, tal vez eso, pero no para ese tiempo. Como no para las cosas que obtienes de la API. Y si ya tienes complejidades que tienen eso y tienes una aplicación muy compleja, por ejemplo podrías tener mapas que se superponen o cosas que se superponen con mapas tal vez tengas múltiples, podría verse como múltiples mini aplicaciones funcionando juntas e interactuando entre sí. Entonces la historia probablemente sea más fácil de ver. Es probablemente más fácil tener la tienda que usar un proporcionar o tener múltiples props o hacer la obtención desde el componente hijo. Y el buen punto sobre tener los datos en la tienda es que puedes pedirle al componente que obtenga. También los hijos para obtener no es tanto como un gran problema que no tener una tienda comparado con solo usar eso diciendo, está bien solo puedo hacer obtención en mis páginas. Cuando no tienes una tienda, generalmente es un problema mayor pero si tienes una tienda, es más fácil permitirte hacer la obtención desde diferentes lugares no solo desde el componente de la página. Siempre depende la respuesta de todos modos pero en la mayoría de los casos es cierto. Página. Sí. Pero ese fue un buen punto. Tener una tienda hace que sea más fácil acceder a los datos a través del componente. Quiero decir, ese es el punto de la tienda pero hay una gran ventaja sobre pasar el flujo a través de las props, creo. Sí. Sí.

Lo que me gusta es esta idea de si solo pasas una prop a través pero ni siquiera usas esta prop en este componente intermedio es una buena regla para ver, está bien, tal vez hay un nuevo árbol que se abre en este árbol de componentes donde tiene sentido nuevamente acceder a una tienda nuevamente y vivir allí en tu propio mundo. Lo que estoy cambiando completamente de tema ahora hay algo llamado VueXORM y no estoy seguro si es conocido por todos. Así que Pia, ¿qué es este framework? ¿Cuándo necesito esto? ¿Qué hace por mí? Está bien, así que VueXORM es como su nombre sugiere, proporciona un acceso a la API similar a ORM para la tienda. Así que si alguna vez has usado como Lalabel o Lubion Rails, todos tienen registros activos o Lalabel tiene Eloquent. Así que son mapeadores de objetos de creación ORM. Así que puedes hacer cosas como user.find y pasas el ID y obtienes el ID del usuario de la base de datos amigo. Y quería hacer prácticamente lo mismo en el front end porque no podía soportar la idea de tener datos duplicados dentro de la tienda. Por ejemplo, estás obteniendo, digamos que estás tratando de obtener datos de publicaciones, datos de publicaciones de blog del servidor. Y tal vez la publicación también tenga un campo y también es un objeto de usuario, ¿verdad? Y tal vez la publicación tenga comentarios y tal vez los comentarios también tengan así como también y también es un objeto de usuario, ¿verdad? Así que cuando obtienes este tipo de árbol JSON anidado, hay una buena posibilidad de que tengas datos duplicados en todas partes. Así que tienes el mismo usuario, pero en múltiples lugares. Si almacenas estos datos en la tienda directamente, van a haber tres usuarios diferentes, pero en realidad esos son los mismos usuarios. Y si quieres actualizar esto, va a ser realmente difícil, ¿verdad? Porque tienes que mirar en cada registro individual y averiguar si esos tenían el mismo ID o no.

Al usar VxOrm, lo que va a hacer, va a deduplicar todos los datos duplicados. Y va a distraer todas las entidades de esos árboles anidados y almacenar esos datos en el Vuex, como una base de datos. Así que si dices que las publicaciones tienen comentarios que tienen usuarios a través de VxOrm, el resultado dentro de la tienda Vuex serán los usuarios de las publicaciones y los comentarios por separado. Y al obtener los datos, puedes consultar esos datos como si estuvieras usando como ordinario o como, digamos que quieres obtener todos los comentarios con usuarios o todos los comentarios con su publicación padre. Así que puedes controlar la obtención y cosas, y lo más importante, si actualizas un objeto de usuario, todos los objetos de usuario, que hacen referencia a ese usuario, se van a actualizar. Así que por ejemplo, en esa publicación de blog, si cambias el nombre de usuario en cualquier comentario, entonces ese usuario mostrado en la página con todos los nombres de los usuarios se va a actualizar. Así que eso es lo que quería lograr con VxORM. Es bastante complicado, pero si tu aplicación está usando muchas relaciones, si tu aplicación tiene muchos modelos y relaciones y cosas complicadas, entonces diría que podría ser una buena elección para tu proyecto, sabes.

Sí, la descripción también me recordó de alguna manera a Xdate. Así que también algo que suena súper complicado, pero si lo necesitas, lo necesitas. Y entonces es bastante, bastante genial. También hablé una vez con el autor de Xdate y él dijo, sí, es algo complicado. Sabes, tienes que sentarte un fin de semana y aprenderlo. ¿En qué tipo de mundo extraño estamos viviendo que alguien dice que es complicado, tienes que sentarte una semana para aprenderlo?

Así que desafortunadamente estamos fuera de tiempo ahora. Quiero agradecerles a ambos por su tiempo y su conocimiento. Si hay algo, solo diré a la audiencia ahora que te escriban en Twitter para cualquier pregunta de seguimiento. Y por supuesto, síguenos aquí en Discord y únete a nosotros para la fiesta posterior más tarde para todas las demás preguntas. Así que gracias de nuevo por su tiempo, Kier y Eduardo. Gracias, Vanessa.