Construyendo Bibliotecas Vue Compatibles con Versiones Anteriores

♪♪♪ Hola, hola, hola, hola. Muy bien, buenos días. Quiero decir, buenas tardes. ¿Cómo... Muy bien, vamos a hacer el gesto de las manos. Así que prepárense. Preparen sus manos. ¿Cuántas personas usan Vue aquí en producción? Ahí vamos. Y esto es para asegurarme de que estén despiertos. ¿Cuántas personas están cansadas? Sí, ha sido largo. Yo también. Pero estoy emocionado porque la próxima charla, después de la mía, es realmente genial. Así que hagamos la mía. Ajusto mis charlas a las personas en la sala. Así que cuando originalmente escribí esta charla, la escribí porque estaba construyendo una biblioteca. Estaba construyendo un sistema de diseño de componentes. Manos. Muy bien, tengo manos. ¿Cuántas personas están en una migración de Vue 2 a 3? Sí. Sí. ¿Es divertido? No. ¿Sí? Sí, no, es horrible. Así que mi caso es, creo que en realidad el peor caso de una migración de Vue 2 a 3. Y les mostraré la estructura de mi repositorio en un segundo. ¿La gente está construyendo aplicaciones? ¿Estamos construyendo aplicaciones o bibliotecas? Griten. Aplicaciones, muy bien. Así que en esta charla, vamos a cambiar de tema de lo que yo había planeado. Estas eran las preguntas que había planeado hacer. Un poco sobre mí. Tuve una muy buena introducción.

Trabajo a tiempo completo en código abierto en Ionic en el compilador Stencil. El compilador Stencil se supone que es una forma agnóstica de construir componentes web, en resumen, construir componentes web. Y luego enviarlos a múltiples equipos diferentes, diferentes frameworks. Suena genial. Entonces, los equipos A, B, C y D pueden escribir todos en Angular, React y View. Y el equipo del diseño del sistema no tiene que preocuparse, pueden escribir en este pequeño lenguaje meta. Eso es lo que hace Stencil.

He estado allí como cuatro semanas. Eso es todo lo que tengo. Anteriormente trabajé en Cypress. Trabajé en código abierto. ¿Han usado Cypress? Griten. ¡Woo! Sí, woo. Y construí el ejecutor de pruebas de componentes. También hice lo del núcleo de faker JS. Y he estado en el ecosistema de View JS durante un buen tiempo, tres, cuatro años. Y ahora soy un colaborador de solid JS. Me encanta la Reactividad. Así que ese soy yo.

Y luego tuve una breve temporada en el espacio de usuario nuevamente. Así que pasé de Cypress durante dos años y medio a Path AI en Boston. En realidad, en Cambridge. Lo llamo Cambridge falso, porque soy de los Estados Unidos. Y ustedes podrían ser de aquí. Entonces, en el espacio de usuario, como lo llamo yo, construir aplicaciones es diferente. Y sentí que quería reconectar. Quería reconectar después de estar en código abierto durante tanto tiempo. Pensé, ¿cuáles son los problemas reales que enfrentan las personas? Y la respuesta es, las migraciones de View 2 a 3. Me uní en julio de 2022. Y he pasado la mayor parte de ese tiempo, hasta las últimas cuatro semanas, en el espacio de usuario, tratando de migrar de View 2 a 3.

Así que tengo muchas opiniones. Mi problema era que tenía muchos equipos, muchos consumidores de la biblioteca de componentes en la que estaba trabajando. Y necesitábamos actualizar a Vue 3. Y necesitábamos hacerlo. Y esta es una distinción que aclararé muy claramente en un momento.

Éramos una empresa de tecnología médica. Teníamos todas las regulaciones que a los Estados Unidos le gusta imponer a la tecnología médica, lo cual es menos de lo que sucede en Europa y otros lugares del mundo. Pero esta es la estructura del repositorio. Tenemos cuatro aplicaciones web. Parece bueno. Tenemos una biblioteca Vue compartida. Y para cada recuadro pequeño hay un paso de compilación utilizando Vite, o Webpack, o Vue CLI, o Jest para pruebas, o Playwright para pruebas. Mantiene todas las opciones, porque fue construido por personas que no son desarrolladores front-end. Y está bien.

Pensé, si alguien puede desenredar esto, creo que puedo hacerlo. Otra vez. Otra vez. Y la razón por la que se ve así, la razón por la que se ve así es porque la FDA en los Estados Unidos requiere que, por repositorio, se delimiten los diferentes requisitos. En realidad, la forma en que esto funciona realmente es que tomas todo tu código para cada aplicación web de Vue y lo pones en una memoria USB. Sí. Lo pones en una memoria USB y alguien revisa tu código y pruebas. Y lo hacen. No, como, de manera superficial, como, se ve bien para mí. Hacen comentarios de código en tus pruebas. Como, ¿por qué estás, bromeé. Dije, si alguien alguna vez me hace comentarios de código en las pruebas de componentes de Cypress en lo que construí, no sé cómo me sentiré al respecto. Pero, este es mi problema. Esta no es la diapositiva más fea. Esta es la diapositiva más fea. Y podrías preguntarte, ¿qué diablos son estos colores? Bueno, cada recuadro es un repositorio.

Cada color representa un equipo. Y como sabemos, los equipos lanzan a diferentes ritmos. Y así cuando estás pensando, estás en la parte inferior. Yo estoy en la biblioteca de componentes VUE, en rojo, soy este equipo solitario. Teníamos siete repositorios, cinco equipos, 25 ingenieros, y cuatro productos que tenían ciclos de lanzamiento separados. Y eso es terrible. Realmente es terrible. Porque es irreal esperar que cada repositorio en el medio, son azules y amarillos, y luego al final, pequeñas cajas verdes, mantengan ramas de VUE 2.7 y VUE 3 a largo plazo. Ni siquiera consideramos VUE 2.6. Solo dijimos, está bien, VUE 2.7, aquí es donde vamos a empezar. Porque sabemos que eso es lo más cercano a VUE 3. Hay razones para eso, encuéntrame después.

Entonces VUE 3 también ha llegado al final de su vida útil. ¿Qué deberían hacer las empresas? Depende. ¿Tienes que preocuparte por las security parches tanto como nosotros que estamos en medtech? Tal vez. Si no has revisado los documentos de migración de VUE 2 a 3 recientemente, han cambiado. Y tienen muchos más detalles de los que tenían antes. Y hablo de los últimos tres meses, dos meses.

Entonces, retrocediendo, quería, literalmente retrocediendo, quería una biblioteca de componentes que pudiera desarrollarse activamente con confianza. Quería enviar un botón con Tailwind. Sí, sí, sí. Quería enviar un botón con Tailwind que pudiera desarrollarse y luego, no requerir un gran esfuerzo de migración de todos esos bonitos repositorios de los que hablamos o las bibliotecas intermedias. Un objetivo modesto, pensé. No lo fue. Pero lo intenté. Pensé, está bien, vamos a enviar algo llamado, hice una pequeña plantilla. Es de código abierto. Se llama Petite. Y es una estructura de proyecto para autores de biblioteca de componentes, porque idealmente, en realidad, otra situación de participación del público aquí. Durante el proceso de migración a Vue 3, ¿has notado que algunos repositorios simplemente dejaron de admitir Vue 2 y pasaron directamente a Vue 3? ¿Sí? No lo hiciste.

Lo sientes. Sí. En resumen. Lo que deseo que hagamos en el futuro es, al enviar bibliotecas, crear un Monorepo. Llegaremos allí. Y queremos enlazar el directorio fuente. Este es mi plan genial. No fue genial. Y queremos reutilizar las herramientas de compilación y pruebatooling para asegurarnos de que cuando compilemos una biblioteca para diferentes versiones del usuario, como, digamos, Vue Popper o cualquier otra, las pruebas y las herramientas de compilacióntooling se ejecuten en ambas versiones del usuario. Explicaré por qué.

Y finalmente, queremos desplegar el proyecto. Genial. Paso uno, crear un Monorepo. Elijo pnpmworkspaces. Creo que es la única opción sensata en este momento. Y luego ves esta pequeña cosa de origen aquí con la flecha. Si alguna vez has subido un enlace de origen a GitHub, así es como se ve. Y se ve así. Lo abres, ese es el código. Y tengo un archivo package JSON raíz. Te permite desarrollar como autor de biblioteca, nuevamente, en ambas versiones. Y esta es mi situación idealista, lo que desearía que hubiera sucedido. Código fuente. Idealmente, se ve normal. Este es mi ejemplo. Hice un código en vivo. Tal vez no lo haga. Depende del tiempo. Así que a la izquierda, tienes el sabor de script setup de JavaScript. La API de opciones también funcionaría.

Siempre y cuando lo escribas de una manera que funcione para ambas versiones de Vue, 2 y 3. Así que si estás escribiendo, digamos, la función emit aquí con update model value e input, idealmente debería funcionar. Avanzando.

Estamos utilizando las herramientas de compilación y prueba. Esta es la parte más importante, es lograr que todos reutilicen las herramientas de compilación. Si estás usando algo como Tailwind o Uno CSS, cuando compiles tu biblioteca, debes hacerlo para ambas versiones. Quieres reutilizar la configuración de Tailwind en ambos objetivos. Dependes en gran medida de tu entorno de prueba para asegurarte de que funcione con estas múltiples versiones de usuario. Y la mayoría de las bibliotecas en realidad no hacen esto. La mayoría de las bibliotecas se detienen en las pruebas unitarias. No se aseguran de que la API funcione con la versión de usuario objetivo 2.7, versión de usuario objetivo 2.6, 3, 3.3. La infraestructura de pruebas para bibliotecas podría mejorarse, por decirlo suavemente. Y utilizarás RuntimeUtils o BuildSteps para admitir múltiples cosas, como model value, value, etc., estos cambios que rompen la compatibilidad que tenemos. Así que asegurémonos de que siga funcionando cuando estemos desarrollando nuestra biblioteca. Cuando estamos desarrollando nuestro componente, no voy a decir sistema de diseño, porque eso es algo aparte. Cuando estamos desarrollando nuestra biblioteca de componentes, queremos asegurarnos de que siga funcionando. Y queremos reutilizar las pruebas de demostración que ejerciten el uso, no los detalles internos. ¿La gente usa ViewTestUtils? Genial. ¿Usas la función emitida en ViewTestUtils? No lo hagas. Tengo opiniones.

Así que veamos la prueba del componente de contadores. Esto está escrito en Cypress. Trabajé allí. Realmente no me importa lo que uses. Lo importante es que estés probando el componente haciendo clic en él. En la línea 11, donde digo assertions, te mostraré cómo se ve eso. En el mismo punto, enfatizándolo. La compatibilidad hacia atrás significa que el contrato de la API debería ser el mismo. Así que si tienes un componente de contador, debería admitir v-model, independientemente de la versión de usuario objetivo. Min y max aún deberían ser números.

Sí. Sí. Muy bien, ¿qué tenemos? ¿Hora? ¿Dónde está mi chico? Se supone que debe decirme que estoy bien. Así que tengo una estructura de repositorio. Tengo paquetes, que es la raíz del espacio de trabajo de PMPM. Y tengo dos carpetas, libview2, libview3. Libview2 tiene un directorio de origen, pero en realidad no es un libview2. Esto es técnicamente, aunque esta pequeña cosa de la ruta es como libview2, miente. Miente, porque si digo, hola, view JS, y voy a la vista3, así es como funcionan los símbolos, ¿verdad?

Estamos en Counter View. Es como, hola, view JS. Así que puedes adivinar lo que voy a hacer. Voy a escribir código que sea compatible con versiones anteriores. Nuevamente, esto era un sueño para mí. Esto es como el sueño. Así que llamé a este repositorio template petit. Está en mi GitHub. Te mostraré el enlace al final. Pero vamos a desarrollar en view2, y vamos a desarrollar en view3. Esto es Cypress, si nunca lo has visto. Lo construí durante dos años y medio de mi vida. Así que lo tenemos abierto en Canary, y lo tenemos abierto en Chrome. Ignora los pequeños Cypresses. Son aplicaciones de Electron. Está bien. Vamos a hacer clic en counter.tsx, y estamos en la versión 3.2 de view aquí. Podemos contar hasta 10. Oh, esto es pequeño. No vamos a hacer eso. 3.2. Y podemos contar hasta -10.

Tengo un componente de demostración porque alguien me dio el comentario de que es mejor escribir en SFCs para las demostraciones en lugar de JSX. Realmente no me importa de ninguna manera. La parte importante es esta.

Así es como debes usar dicho componente contador. Debes pasarle un minimax y un vmodel. ¿Alguna vez alguien ha hecho algo así antes? Sí, yo también.

Muy bien, así que en nuestra demostración del contador, imprimo la versión de la vista solo por diversión para que esta demostración se vea más bonita. Pero lo que realmente me importa es el contador. Quiero asegurarme de que el contador funcione en la vista 3 y en la vista 2. La vista 3 puede llegar hasta -10. La vista 2 también debería poder llegar hasta 10 y -10.

Puedes ver que estamos en la vista 3 debido a este texto pequeño aquí, texto pequeño, y este texto grande y bonito. Pero la vista 2, boop, está en la 2.7. Pero notarás que la prueba está fallando, y eso es una lástima porque significa que este componente que hemos escrito no es compatible con la vista 2. Es compatible con la vista 3, y eso está bien. Pero idealmente, nuestros consumidores, doo-doo-doo-doo, oh, vamos, acercamiento. No se está acercando. Juro que lo hice como un millón de veces. Muy bien. Ahora es lo suficientemente grande. Boop. OK, vista 2, vista 3. El componente contador aquí no funciona, y eso es triste porque queremos que nuestras cosas de usuario funcionen en múltiples versiones. Así que vamos a solucionarlo. Puedes ver que tenemos el valor del modelo. Así es como defines el modelo de medios en la vista 3. Y en el pasado, donde el pasado es la mayoría de los días para la mayoría de ustedes, teníamos el valor. Y la forma en que vamos a solucionarlo es diciendo que tenemos el valor. Es básicamente lo mismo. Y con muchas de las cosas de las que Evan estaba hablando, por cierto, esto será mucho más fácil de definir en la vista 3, vista 3.3 y más allá.

Podemos tener props definidos de manera más elegante y sintaxis. Y estamos actualizando el valor del modelo, pero lo que realmente queremos hacer es actualizar. ¿Qué queremos hacer? ¿Cómo hacemos que sea compatible con la vista 2? Actualizar el valor.

La forma en que escribimos modelos de vista personalizados es Input. Y estamos emitiendo el valor del modelo aquí en incremento y decremento. Habla. ¿Qué estamos haciendo? Estamos haciendo input. Y hago input aquí. Y nuevamente, esta es la forma más fea de hacer esto. Esto es terrible. Pero todos aquí entienden la abstracción. Y hay patterns para que esto se vea menos feo. Genial.

Y ahora, si recargo, debería poder hacer clic. No puedo hacer clic. Esto es lo que obtengo. Oh, es porque no hice change. ¿No es change? Es change. Nope. Mm. Oh, Jessica. Escribí esta demostración esta mañana. Sí. Mierda. Si alguien quiere programar en pareja conmigo ahora mismo, siéntase libre de gritar lo que debería hacer. ¿Change? ¿Change? Oh, recuerdo. Recuerdo. ¿Sabes qué es? Solo estoy tomando el contador aquí. props.value, o cero. Recargar.

No. Y estaba en lo correcto. De acuerdo, tenía razón la primera vez. Cambio. Triste Panda. En realidad, soy muy bueno en esto. Y soy bastante decente en la codificación en vivo. Es una de las pocas habilidades que valoro en mí mismo. Y practico esto también.

Guárdalo. Ejecútalo. No. No. Creo que esta es la primera vez que algo sale mal. Espera, ¿qué? El valor del modelo se establece en cero por defecto. El valor del modelo se establece en cero por defecto. El valor del modelo se establece en cero por defecto. Creo que tiene algo que ver con los eventos de cambio del contador. Entrada y predeterminado. ¿Hmm? Entrada y predeterminado. ¿Entrada y predeterminado? De acuerdo. Entrada y predeterminado. Vuelve a poner el predeterminado. Esta es la línea nueve. Línea nueve. Vuelve a poner el predeterminado. Lo eliminaste en dos líneas. ¿Sabes qué? Lo hice antes. Debería haber hecho esto. Me puse nervioso en el escenario.

Y creo que tomé mi versión correcta. Sí, tomé mi versión correcta. Podemos averiguar qué es más tarde. Pero tenía esto en mi bolsillo todo el tiempo y me olvidé de ello. Eso apesta.

De acuerdo. Agreguemos el ID de prueba de datos rápidamente. El ID de prueba es 'counter'. Y aquí vamos. Por favor, muestra la versión View 2. ¡Woo! Gracias. En realidad, estoy sudando. Estoy sudando físicamente. Eso fue muy estresante. De acuerdo. Y luego la versión View 3 también funciona. Una de las únicas cosas que Harry, el cambio rompedor número uno de Harry de la versión View 2 a 3 es vModel, ¿verdad? El cambio de Harry, no tan Harry, es bastante obvio, es eliminar los divs envolventes. ¿Verdad? Porque View 3 nos dio parciales, ¿verdad? Parciales de plantillas. View 2 no lo hizo. Entonces, ¿View 3? View 3.2.39? Muy feliz. ¿View 2? Muy triste. Vite está muy, muy triste en este momento porque las plantillas de los componentes deben contener exactamente un elemento. Y este es el tipo de cosas que se pueden detectar con una infraestructura de pruebas como esta.

Volviendo atrás, es hora de preguntas y respuestas. Me estoy pasando de tiempo. Voy a pasar rápidamente por esto. Al desplegar tus paquetes, quiero que mi biblioteca admita Semver. Quiero tener cambios rompedores entre componentes, entre versiones. Y no quiero acoplarme a la próxima versión principal de Vue.

Así que imploro a los autores de bibliotecas que no rompan a sus usuarios en el futuro. Imploro a los desarrolladores de aplicaciones que comprendan lo difícil que puede ser. Realmente es frustrante. Y lo experimenté como usuario, ¿verdad? Cambié de trabajo para experimentar realmente los problemas a los que todos nos enfrentamos. E imploro a los autores de bibliotecas que inviertan en herramientas que les permitan construir, probar y desplegar bibliotecas en múltiples versiones del framework. Si quieres ver la estructura del repositorio, siéntete libre de revisarlo.

Eso es lo más valioso que hay ahí. Gracias a todos. Gracias a las siguientes personas por ayudarme a hablar sobre la arquitectura, oh Dios mío, debe haber sido en julio cuando comencé el dolor. Daniel Rowe, a quien todos amamos, Thorsten Lindberg, miembro del equipo principal desde hace mucho tiempo. Y Johnson Chu. Shoo, voy a arruinarlo. Bill Vallar hace mucho trabajo para la comunidad de Vue y respondió un montón de preguntas para mí. Cosas como, ¿cómo se escribe un modelo V compatible con versiones anteriores? ¿Verdad? Así no tienes que escribir todo ese código feo que estaba escribiendo y que arruiné durante, como, 10 minutos.

Consejos para los desarrolladores de aplicaciones. Reduce el número de capas. ¿Por qué? Si no estuviera en una empresa de tecnología médica, no tendría tantas cajas. Habría dicho, monorepo, envíalo, porque eso haría que la integración continua sea mucho más fácil. La cadena de herramientas es lo que te complica. No es el tiempo de ejecución de Vue. El tiempo de ejecución de Vue, lo tuve en un día. Son las cadenas de herramientas y las diferencias en la cadena de herramientas entre VT, Vue CLI, Jest, etc. Eso es lo que realmente te complica. ¿La migración de Vue y Vue 3? Estable.

Todo lo demás. Ahí es donde está el dolor. Así que buen consejo. Eso es todo. Gracias. Muchas gracias. Realmente disfruté esa charla también.

También debo decir que la pregunta principal cuando entramos fue que la gente te pedía que por favor sigas haciendo LiveCoding, porque te hemos visto hacerlo antes. Eres increíble. Y sigue siendo valiente. Así que aplaudamos a LiveCoding. Y no solo LiveCoding. Como dije, dijiste que LiveCoding es uno de los únicos talentos que tienes. Eso es una mentira. Tienes una lata de agua en la mano. Yo fui e invertí en un par de latas adicionales.

Porque la siguiente pregunta es, ¿cuál es tu patrón de malabarismo favorito? Y sé que puedes hacer malabarismos. Tú sabes que puedes hacer malabarismos. Creo que deberías mostrarlo. ¿Crees que debería mostrarnos algo de malabarismo? Sí. Muy bien, adelante. Muy bien. Entonces, ¿cuál de estos? Deberías tener música, chicos, solo para marcar un ritmo al que puedas hacer malabarismos. En algún lugar, algo que se mezcle. Veamos si puedes marcar un ritmo. Puedes hacerlo. Lo tienes. El diagrama de Venn de los nerds y el malabarismo es un círculo. Hago esto en el MIT.

He estado haciendo esto durante cuatro meses. Y es muy difícil hacerlo con estas latas. Normalmente traigo mi equipo de malabarismo. Así que voy a hacer dos.

Vamos a comenzar. Asegurémonos de que no esté agotado después de dar una charla donde fallé. Oh, es LiveCode. Dos. Parece legítimo. Normalmente hago con clavas. No me gustan mucho las pelotas. Puedes hacer patterns más interesantes. Son más fáciles. ¿Lo quieres? Lo tienes. Lo tienes. Hagan ruido. OK, OK, OK. Tengo que esconder la cola, tener la postura correcta. No. Así que en las competencias de malabarismo, tienes tres intentos. Es cierto. Uno, y luego uno más. Muchas gracias. Eso es impresionante. Me encanta lo talentosos que son todos nuestros oradores, también.

Una cosa que quería darte la oportunidad de tal vez incluir en tus diapositivas. En una de tus diapositivas, decía que Vue 3 estaba cerca del final de su vida útil. Y sinceramente, me quedé pensando, ¿qué? Acabas de ver una charla del chico de Hero Devs, que decía que el nivel de riesgo de Vue 3 era de 97 sobre 100. Sí.

Vue 3 está cerca del final de su vida útil, pronto en diciembre de 2023. Es 2023 ahora. Diciembre de 2023. Muchas personas no necesitan actualizar a Vue 3. Considera no hacerlo. Analiza tu caso de uso. Bastante justo, ahora lo sabemos. Eso es definitivamente algo que voy a buscar en Google cuando termine en el escenario.

Y continuemos con algunas preguntas técnicas más. ¿Cuánto tiempo después del final de vida útil de Vue 2 crees que las bibliotecas deberían seguir dando soporte a Vue 2? Es una lucha como autor de bibliotecas. Y esto es igual para todos los frameworks. Los autores de bibliotecas en JavaScript no tienen buenos consejos sobre cómo construir la cosa. Simplemente no hay buenos recursos. De hecho, encontré uno mejor. Pero actualmente, creo que la documentación de Turbo Repo es fenomenal para los creadores de bibliotecas aspirantes. Me gustaría tener más de eso de la comunidad de JavaScript en general. Eso sería realmente beneficioso para todos nosotros. Pero hasta ahora, los autores de bibliotecas hacen lo que pueden. Realmente no hay buenos patrones.

No, definitivamente, entiendo eso, entiendo eso. Y solo para confirmar, ¿estás diciendo que Vue 3 está cerca del final de su vida útil, no Vue 2? Vue 2 está cerca del final de su vida útil. Oh, yay, yay. Sí, sí, sí. ¿Lo arruiné? ¡Dios mío! La diapositiva dice que Vue 3 está cerca del final de su vida útil. Hice la pregunta. Tú dijiste que sí, está cerca del final de su vida útil. Me voy a esconder detrás de este letrero.

No te preocupes. Ha sido un día largo. Ha sido un día largo, sin duda. Estaba tratando de mantener el entusiasmo. Estaba verificando los hechos. Esa es mi tarea como moderador, verificar los hechos. De todos modos, volvamos al tema.

Tenemos otra pregunta de Alvaro, que es, ¿cómo haces un seguimiento de las dependencias de NPM para cada versión y mantienes todo compatible cuando estas dependencias cambian su API? Por ejemplo, VT5 o VT5 2 y 3 tienen cambios importantes en tu plantilla que deben ser diferentes? Entonces, necesito información aclaratoria sobre eso. ¿Como autor de una biblioteca o como desarrollador de aplicaciones? Esa es la primera pregunta aclaratoria.

Como autor de una biblioteca, debes escribir pruebas antes de enviarlas. Porque tienes una versión fija con la que necesitas ser compatible. Como desarrollador de aplicaciones, asegurar la calidad de tu aplicación es muy diferente, y tienes cosas como monitoreo e implementaciones canary para asegurarte de que todo esté bien. Pero como autor de una biblioteca, necesitas escribir pruebas donde crees una aplicación Vuetify 2 y una aplicación Vuetify 3 y ver si tus cosas siguen funcionando. Ver si tu component library sigue funcionando. Si estás construyendo sobre Vuetify, por ejemplo. Eso es genial. Consejo realmente bueno.

Y también, alguien más ha preguntado, ¿has pensado en usar Vue Demi para diferentes versiones de bibliotecas? Sí, absolutamente. Vue Demi es genial si estás construyendo algo que no tiene SFC y necesita un paso de compilación en el medio. Intentamos usar Vue Demi en la migración que lideré. Y Vue Demi simplemente no admite SFC. Y cada caja que mostré en esa pantalla exportaba algún tipo de SFC. Si estás escribiendo código de biblioteca, por favor, intenta no hacerlo headless. Hazlo headless. No uses funciones de renderización en bruto, porque eso rompe mucho. Y luego, sí, solo API de composición en bruto, si puedes hacerlo, y referencias. Alguien mencionó las referencias de plantilla antes. Las referencias de plantilla serían la forma de hacerlo si estás tratando de hacer algún tipo de estilo. Usa Vue use. Literalmente ve al código fuente de Vue use y mira cómo lo hacen. Esa es la mejor manera. Como su componente de desplazamiento infinito, el componente de desplazamiento infinito headless de Vue use, ese tipo de patterns. Eso es lo que debes buscar. Y ve a GitHub. Mira el código fuente. Genial, y si las personas quieren saber más sobre ti, hacer más preguntas o tal vez ver más malabares, ¿dónde pueden encontrarte? Me pueden encontrar arriba durante los próximos, no sé, 40 minutos. Tal vez en la fiesta posterior y en Twitter. Genial. Aplaudamos a Jessica. ¡Woo!