Vue: Actualizaciones de Funciones

Spanish audio is available in the player settings
Rate this content
Bookmark

El creador de Vue js da una actualización sobre las nuevas funciones de la tecnología.

44 min
12 May, 2023

Video Summary and Transcription

La charla discute las recientes actualizaciones de funciones en Vue 3.3, centrándose en la configuración de scripts y el soporte de TypeScript. Cubre mejoras en la definición de props utilizando tipos importados y soporte para tipos complejos. La introducción de componentes genéricos y firmas reestructuradas para componentes definidos proporciona más flexibilidad y un mejor soporte de tipos. Otras funciones incluyen la inferencia automática de props en tiempo de ejecución, mejoras en la definición de emisiones y slots definidos, y funciones experimentales como la destrucción de props reactivos y la definición de modelos. La charla también menciona los planes futuros para Vue, que incluyen estabilizar la suspensión y mejorar las invalidaciones computacionales.

Available in English

1. Introducción a Vue 3.3 y Soporte de TypeScript

Short description:

¡Hola, Reino Unido! Hoy hablaré sobre la reciente actualización de características en Vue 3.3. El enfoque fue mejorar la experiencia de desarrollo con script setup y TypeScript. Inicialmente, Vue no admitía TypeScript, pero a medida que crecía la base de usuarios, repensamos partes del framework para adaptarlo a aplicaciones complejas. Un buen soporte de TypeScript mejora la productividad entre equipos y la mantenibilidad a largo plazo.

Es mi primera vez en el Reino Unido, primera vez en Londres, ¡estoy súper emocionado de estar aquí! Ayer hicimos un recorrido en autobús, no tuve muchas oportunidades de caminar por mi cuenta aún, pero ha sido una experiencia muy enriquecedora, hay mucha historia aquí, así que estoy súper emocionado y ansioso por conectarme con todos los desarrolladores de aquí, y también de cualquier otro lugar de donde vengan.

Hoy hablaré sobre la actualización de características que ha ocurrido recientemente en Vue, y en caso de que aún no lo sepas, Vue 3.3 fue lanzado ayer. Esta fue la primera versión menor en mucho tiempo, de hecho, 3.2 fue lanzado hace más de un año, y una de las razones fue porque dedicamos mucho tiempo trabajando en Vite y otros proyectos relacionados. Invertimos mucho tiempo en, por ejemplo, el lado de las IDE, mejorando las herramientas de lenguaje, Volar y todo lo demás, mejorando toda la experiencia de desarrollo en torno al ecosistema de herramientas alrededor del núcleo de Vue. Pero ahora estamos volviendo nuestra atención al núcleo de Vue, y verás más lanzamientos frecuentes del núcleo de Vue después de este. Así que esto es el comienzo de muchas cosas nuevas que están por venir. Echemos un vistazo a 3.3.

El enfoque de esta versión fue, nuevamente, mejorar la experiencia de desarrollo cuando se utiliza script setup en componentes de un solo archivo y TypeScript. Ahora, no te enfades si no usas TypeScript. Obviamente, cuando Vue comenzó, ni siquiera admitíamos TypeScript. De hecho, muchas de las API iniciales ni siquiera fueron diseñadas teniendo en cuenta TypeScript. Con el tiempo, tuvimos que repensar lentamente partes del framework para tener en cuenta, oh, ¿cómo funciona esta API con TypeScript? Cuando introducimos nuevas API, ¿cómo funcionarán estas nuevas API con TypeScript? Y la razón de esto es porque en las etapas iniciales, cuando Vue era relativamente pequeño, nuestra base de usuarios se centraba principalmente en casos de uso relativamente simples. Mayormente utilizaban un framework de backend y solo querían algo de interactividad en el frontend. Pero hoy en día, nuestros casos de uso se han expandido enormemente y la gente está construyendo aplicaciones realmente complejas con Vue. Y en situaciones como esa, cuando tienes proyectos grandes, equipos grandes, muchas personas trabajando juntas con diferentes niveles de experiencia, tener un sistema de tipos y una buena experiencia de desarrollo con TypeScript te ayudará mucho con la productividad entre equipos y la mantenibilidad a largo plazo de tus aplicaciones. Creemos que esto es algo realmente importante en lo que queremos enfocarnos, y ha habido históricamente algunos puntos problemáticos en Vue cuando se utiliza Vue con TypeScript, los cuales creemos que hemos resuelto en gran medida en esta versión.

2. Tipos Importados para Definir Props

Short description:

Desde la introducción de Script Setup, una de las características más solicitadas en Vue 3.2 es la capacidad de usar tipos importados al definir props. El compilador de vistas analiza los tipos proporcionados para definir props y determina las props que el componente espera en tiempo de ejecución. El compilador genera la lista correcta de props en tiempo de ejecución, asegurando que la aplicación funcione correctamente.

Probablemente una de las características más solicitadas desde la versión 3.2, desde la introducción de Script Setup, es la capacidad de usar tipos importados al definir props. Ahora, este ejemplo funcionaba en la versión 3.2 cuando importas un tipo desde otro archivo y lo usas en DefineProps con la sintaxis de declaración de tipo.

Un poco de contexto aquí, la razón por la que necesitamos hacer algo especial con los tipos aquí es porque en tiempo de ejecución, un componente de vista necesita conocer la lista explícita de props que se espera que reciba. Sin esa información, no podrá determinar si algo que recibe debe tratarse como una prop o simplemente como un atributo de paso.

Esta es la razón por la que el compilador de vistas necesita analizar los tipos que proporcionaste para definir props, y luego tratar de analizar qué props espera recibir este componente en tiempo de ejecución. Aquí, solo con mirar la sintaxis, te darías cuenta de que es muy fácil determinar que message msg es lo único que este componente espera. Es determinista, por lo que el compilador dice: `OK, ya he determinado que message será una prop esperada. Incluso si no puedo inferir completamente qué es este tipo externo, eso no impide que genere la lista correcta de props en tiempo de ejecución, ¡así que tu aplicación funcionará correctamente, ¿verdad? Porque en producción, realmente no hacemos una validación de props en tiempo de ejecución basada en estos tipos aquí.

3. Soporte de Tipos Importados y Tipos Complejos

Short description:

En Vue 3.2, el compilador carecía de la capacidad de examinar los tipos importados. Sin embargo, en la versión 3.2, logramos admitir la mayoría de los casos comunes. Utilizamos la API de TypeScript para la resolución de módulos y analizamos los archivos para generar la información de tipo adecuada. Aún existen limitaciones, especialmente para los tipos complejos, pero para el código a nivel de aplicación, cubre la mayoría de los casos. Estamos trabajando con los autores de bibliotecas de componentes para mejorar su experiencia de creación y admitir sus casos especiales.

Pero las cosas se complican un poco cuando, por ejemplo, usas una interfaz importada y luego la pasas a define props de esta manera. Ahora, en la versión 3.2, el compilador no podía realmente examinar lo que está dentro de este tipo, porque hasta la versión 3.2, la compilación de componentes de vista siempre se realiza en el contexto de un solo archivo, lo que significa que el compilador solo ve este archivo. Por lo tanto, no tiene información sobre otros archivos, porque no tiene la información sobre tu sistema de archivos, sobre tu configuración de alias o la configuración de ruta en tu tsconfig. Entonces, si queremos resolver realmente este tipo y examinar qué propiedades se incluyen en él, el compilador realmente necesita resolver este especificador de importación. Básicamente, necesita saber en qué archivo estamos, resolver la ruta relativa y luego también debemos tener en cuenta, por ejemplo, si estás importando un tipo desde un paquete npm, ¿cómo resolvemos ese archivo del paquete npm? Y cómo resolvemos, por ejemplo, si el usuario ha configurado mapeos de ruta personalizados en tsconfig, puedes tener un alias aleatorio aquí que apunte a cualquier archivo en tu sistema de archivos, y necesitaremos resolverlo de la misma manera en que TypeScript resuelve los tipos. Entonces, eso suena como una tarea bastante desafiante. Y siendo honestos, realmente nos llevó bastante esfuerzo hacer que esto funcione, pero en la versión 3.2 realmente logramos admitir la mayoría de los casos comunes con los que puedes encontrarte. Por ejemplo, cuando usas una importación relativa, es relativamente simple porque conocemos la ruta del archivo de los componentes actuales, por lo que podemos usar esta ruta relativa para buscar el otro archivo. Luego, necesitamos manejar la memoria caché y la invalidación de archivos cuando editas esos archivos, y también necesitamos manejar los casos en los que estás importando desde un alias o un paquete npm, por lo que en realidad usamos la propia API de TypeScript para realizar la resolución de módulos y obtener el mismo archivo exacto que TypeScript está resolviendo, y luego analizamos ese archivo para obtener la información de tipo adecuada para generar el código de tiempo de ejecución que utilizas. Entonces, parece una característica simple, pero de hecho es bastante compleja y nos llevó bastante tiempo descubrir cómo hacerlo. Pero incluso con esto, todavía hay algunas limitaciones sobre las que debemos ser transparentes, no solo con los tipos importados, sino que también agregamos soporte para un conjunto limitado de tipos complejos. Por ejemplo, aquí estamos usando un tipo importado junto con un tipo de intersección con algunas props adicionales que es posible que desees agregar a esta interfaz. También podemos usar extensiones de interfaz, o a veces puedes usar tipos de utilidad como required o optional, tipos de utilidad incorporados como esos. Entonces, intentamos tener en cuenta estos tipos tanto como sea posible. Por ejemplo, este ejemplo aquí funcionará sin problemas, porque podemos resolver lo que está en props, podemos resolver lo que está aquí y podemos simplemente fusionarlos. Pero en última instancia, todo el proceso de análisis sigue siendo basado en AST, no estamos utilizando TypeScript en sí mismo para hacer toda la inferencia de tipos y todo, porque eso sería realmente costoso. Es una aproximación pragmática en la que intentamos admitir tanto como podamos mediante el análisis del AST, por lo que no podrá cubrir el 100% de los tipos, por lo que si tienes tipos extremadamente complejos con tipos condicionales, inferencia condicional o tipos mapeados locos con genéricos y todo eso, algunos de ellos realmente no serán completamente admitidos. Pero para los casos más comunes, esto probablemente cubrirá la mayoría de los casos con los que te encontrarías en el código a nivel de aplicación. Por lo general, los casos de tipos advanced ocurren cuando estás escribiendo una biblioteca de componentes relativamente advanced, y todavía estamos trabajando con los autores de bibliotecas de componentes para descubrir qué casos especiales pueden necesitar para que podamos mejorar la experiencia de creación para ellos y también para los consumidores de esas bibliotecas de componentes. Por lo tanto, esta seguirá siendo un área en la que seguiremos invirtiendo.

4. Componentes Genéricos y Componentes Definidos

Short description:

La próxima gran característica en Vue 3.3 son los componentes genéricos, que te permiten expresar el tipo de elementos seleccionados en un componente de lista. Puedes usar genéricos, similar a TypeScript, para definir los parámetros y restricciones de tipo. También hemos introducido una firma reestructurada para los componentes definidos, lo que permite a los autores de bibliotecas utilizar genéricos directamente. Esto proporciona más flexibilidad y un mejor soporte de tipo al escribir componentes complejos con JSX o TSX.

La próxima gran característica que habilitamos son los componentes genéricos. Si no estás familiarizado con TypeScript o los genéricos, piensa en ello como... Vamos a usar este componente como ejemplo. Estás construyendo un componente de lista. Este componente de lista va a recibir una lista de elementos, y también va a recibir ese elemento que está seleccionado. A nivel de tipo, quieres decir que el elemento seleccionado va a tener el mismo tipo que el elemento en esa lista. Entonces, aquí el problema es que no sé qué tipo exacto va a ser.

Los genéricos te permiten expresar eso. Aquí, simplemente vamos a agregar el atributo genérico a nuestra etiqueta de script. Esto va a ser exactamente lo mismo que cuando estás usando genéricos normales en TypeScript, tienes este corchete angular y colocas los parámetros de tipo genérico allí. Puedes poner cualquier cosa que puedas poner en esos corchetes cuadrados aquí. Y vas a decir, vamos a tener un tipo genérico, T, y voy a aceptar una lista de elementos que va a ser un array de T y un elemento seleccionado, que va a ser T. Como dije, puedes hacer cualquier cosa que funcione con genéricos normales, lo que significa que puedes tener estas restricciones de extensión, diciendo que este T debe cumplir con esta restricción de tipo. O puedes tener múltiples parámetros de tipo y luego puedes usarlos juntos. Este es solo un ejemplo muy forzado. No trates de encontrarle mucho sentido. Esto es solo para demostrar la posibilidad de sintaxis. Entonces, cualquier cosa que puedas hacer con genéricos normales en TypeScript, deberías poder expresarla aquí.

También hemos lanzado algo así como una característica a medio cocinar sobre los componentes genéricos con componentes definidos. Esto está más orientado a los autores de bibliotecas, porque si has usado Vue, sabes que Vue puede trabajar con JSX, y también puedes usar TSX con Vue. Y esto es, en algunas situaciones, preferido por los autores de bibliotecas cuando escriben componentes realmente complejos y dinámicos para que los consumas. Esto les brinda un poco más de flexibilidad, pero también se encuentran en la situación en la que necesitan genéricos, y anteriormente no había forma de hacerlo. O tenían que recurrir a trucos realmente complejos, trucos de tipo para poder expresar estas cosas. Entonces, reestructuramos la firma de los componentes definidos para permitirte pasar directamente una función con genéricos al componente definido. Y funciona de manera similar a los componentes de función de React, con la diferencia de que, en lugar de devolver directamente JSX o una función de renderizado o nodos virtuales, quieres devolver una función que devuelve JSX. La diferencia entre esto y los hooks de React, si has usado React, obviamente sabrías que la diferencia aquí es que el código de la API de Composición de Vue se ejecuta solo una vez cuando se crea un componente. No se llama repetidamente, sin embargo, esta función de retorno aquí, la función de renderizado, sí se llama repetidamente. Esa es la razón por la que necesito separarlos, pero esto te brinda un compromiso bastante bueno entre poder usar el sistema de reactividad de Vue, con TSX, JSX o funciones de renderizado manuales, junto con un soporte de tipo muy satisfactorio, con genéricos. Una cosa que falta aquí es que necesitamos proporcionar la misma lista de props de tiempo de ejecución generadas en función de tu soporte de tipos. Esto es lo que debes hacer aquí.

5. Inferencia automática de props en tiempo de ejecución

Short description:

Estamos desarrollando un complemento de Babel para inferir automáticamente la lista de props en tiempo de ejecución e inyectarla en los componentes. Esto eliminará la necesidad de declaraciones dobles manuales e ingeniería inversa en las bibliotecas de componentes. Nuestro objetivo a largo plazo es permitir a los usuarios de TypeScript centrarse únicamente en los tipos sin preocuparse por la lista de props en tiempo de ejecución.

Estamos trabajando en un complemento de Babel que se utilizará junto con nuestro complemento JSX para que, cuando uses una declaración de props solo de tipo aquí, automáticamente infiera la lista de props en tiempo de ejecución e inyectarla en este componente para ti. No necesitas declarar todo dos veces. Una de las implicaciones de esta característica es que esperamos que algunas bibliotecas existentes que utilizan TSX para crear componentes de vista puedan migrar a esto y luego podamos enviar solo los tipos para todas las props tanto en la biblioteca de componentes como en la aplicación. Por lo tanto, ya no es necesario escribir manualmente una lista de declaraciones en tiempo de ejecución ni invertir los tipos de la misma, lo cual es una práctica muy común en las bibliotecas de componentes en este momento. Eso es algo que queremos resolver. Eventualmente, queremos llegar al punto en el que, si estás utilizando TypeScript, ya sea como autor o consumidor de componentes, solo te preocupes por los tipos y no te preocupes más por la lista de props en tiempo de ejecución. Ese es nuestro objetivo a largo plazo que esperamos lograr.

6. Improved Define Emits and Defined Slots

Short description:

En Vue 3.3, introdujimos define emits más ergonómicos, lo que te permite declarar tipos de eventos utilizando la sintaxis de tupla etiquetada. Esta característica está inspirada en los macros de Vue, desarrollados por Kevin, quien ahora es miembro del equipo principal. Si estás interesado en explorar ideas experimentales, echa un vistazo a los macros de Vue. Otra mejora es la capacidad de definir slots con tipos, lo que permite una mejor verificación de tipos y detección de errores en el IDE.

Entonces, otra característica en la versión 3.3 son los define emits más ergonómicos. Si has utilizado define emits anteriormente, probablemente hayas encontrado que la firma es un poco extraña. La razón es que, de hecho, este es el tipo exacto para esta función emit que vas a obtener aquí. Es un poco incómodo de escribir. Aquí estamos haciendo algunas conversiones internas de tipos para que puedas simplemente decir que tenemos un evento foo, que va a aceptar esto. Esta sintaxis puede parecer desconocida para algunos. De hecho, esto se llama sintaxis de tupla etiquetada en TypeScript. Si ignoras esta etiqueta ID aquí, esto es solo un número normal, una tupla con un solo elemento que es un número. Pero TypeScript también te permite etiquetar los elementos de la tupla. Puedes darle a cada elemento dentro de una tupla un nombre. Entonces puedes decir que este primer elemento va a ser ID. Y el propósito de eso es que cuando veas el tipo desde otro lugar, te va a dar mejor información. Vas a decir, oh, el primer elemento es el ID, el segundo elemento es eso. Es como una lista de argumentos, que es el propósito exacto de lo que quieres declarar aquí. Internamente convertimos este tipo para darte el tipo de función emit correcto de vuelta. Si estás utilizando Vue 2, esto de hecho es compatible con los macros de Vue. De hecho, esta característica está inspirada. Simplemente tomamos la característica de los macros de Vue. Y el autor de los macros de Vue, Kevin, ahora es miembro del equipo principal. Ha estado trabajando activamente en muchas ideas experimentales en los macros de Vue. Y si eres más explorativo, estás bien con probar cosas nuevas que pueden o no funcionar, deberías echar un vistazo a este proyecto.

Luego están los slots con slots definidos, ¿verdad? Una cosa con la que siempre hemos tenido un poco de problema es que los slots no se expresan como parte de las props del componente, porque todo sucede en la plantilla. Anteriormente no había forma de expresarlos con tipos, pero ahora te proporcionamos la capacidad de hacerlo. Este es el macro define slots. La sintaxis aquí requiere que sepas un poco sobre cómo se representan internamente los slots en Vue. Cuando pasas un slot de un componente padre a un componente hijo, se representan internamente como funciones. Entonces, cuando defines slots, los vas a representar como funciones, y una función de slot recibe sus props de slot, que el componente hijo puede pasar al slot padre. Cuando declaras slots en un componente como este, el IDE va a detectar esencialmente que estás declarando... si cometes un error tipográfico y dices que el nombre del slot es igual a un nombre que no existe aquí, te dará un error.

7. Vue Slot Props and Define Slots

Short description:

Las slot props en Vue 3 proporcionan verificaciones de tipo para la slot predeterminada. Sin embargo, la verificación de slots requeridos aún no está implementada. Los macros de Vue se pueden utilizar con Vue 2.7. Define slots no tienen implicaciones en tiempo de ejecución, solo verificaciones a nivel de tipo.

Decimos, oh, este slot, no has declarado este slot, probablemente estás cometiendo un error, y te dará verificaciones de tipo para las slot props si pasas un mensaje a la slot predeterminada y no es una cadena, te lo indicará. Y también en el componente padre, cuando consumes este componente en el padre y usas un slot, recibes el mensaje del slot de ámbito, te dará el tipo de cadena correctamente. Actualmente, una cosa que aún falta es la verificación de slots requeridos. Como puedes ver, tenemos la capacidad de diferenciar entre un slot requerido y un slot opcional con esto. Actualmente, la verificación de slots requeridos aún no está implementada, pero está planeada y estará disponible eventualmente. Además, puedes usar esto en Vue 2.7 con los macros de Vue. El soporte del IDE en Volar admite tanto Vue 2 como Vue 3. Además, define slots no tiene realmente ninguna implicación en tiempo de ejecución, no realiza ninguna verificación en tiempo de ejecución. Esto es puramente para verificaciones a nivel de tipo que serán utilizadas por Volar y Vue TSC. Obtienes las mismas verificaciones cuando solo ejecutas las verificaciones de tipo desde la línea de comandos también.

8. Reactive Props Destructure and Define Model

Short description:

Aquí, estamos introduciendo una característica experimental llamada desestructuración de props reactivos. Por defecto, Vue realiza un seguimiento de la reactividad a través del acceso a propiedades con puntos. Sin embargo, cuando estructuras una prop, pierdes la reactividad. Con la característica de desestructuración de props reactivos, puedes desestructurar props con valores predeterminados manteniendo la reactividad. Esta característica agrega automáticamente el acceso con puntos en tiempo de compilación, lo que proporciona una sintaxis más limpia para declarar valores predeterminados. Otra característica experimental es define model, que simplifica el proceso de creación de entradas personalizadas con soporte de modelo. En lugar de declarar manualmente props y eventos, puedes usar define model para generar una ref que se comporta como una ref normal.

Aquí, estamos entrando en un territorio experimental, así que desestructuración de props reactivos. ¿Cuántos de ustedes han escuchado o probado la transformación de reactividad? ¿Nadie? La transformación de reactividad fue una característica experimental que probamos durante mucho tiempo, pero finalmente decidimos descartar. Si no estás familiarizado con la transformación de reactividad, es posible que necesitemos proporcionar más contexto aquí.

Entonces, lo primero es que en Vue, por defecto, toda la magia de reactividad ocurre cuando estás usando una propiedad en tu plantilla, usando algo dentro de un watcher, Vue automáticamente realiza un seguimiento de ellos. Y la forma en que Vue los realiza es mediante el seguimiento de este acceso a propiedades con puntos. Entonces, cuando dices props.foo, en realidad activa un getter o una trampa de proxy internamente, en la cual Vue realiza el seguimiento mágico. Oh, está bien, el tiempo en realidad... Necesito ir más rápido. Pero la idea es que, por defecto, todo debe suceder a través de estos puntos. Es por eso que si actualmente estructuras una prop, defines props de esta manera, en realidad pierdes la reactividad. Este foo, esta estructura aquí será simplemente una constante que nunca cambiará. Pero ¿qué pasa si podemos hacerlo reactivo? Y eso es exactamente lo que estamos haciendo aquí.

Entonces, si optas por la característica experimental de desestructuración de props reactivos aquí, puedes desestructurar con valores predeterminados en todo y este foo seguirá siendo reactivo, por ejemplo, cuando lo uses en una propiedad computada, cuando lo uses dentro de un efecto de watcher o lo devuelvas desde un getter, seguirá siendo reactivo. Y el truco es muy simple, simplemente compilamos esto en tiempo de compilación a algo como esto. Así que simplemente agregamos automáticamente el acceso con puntos para que no necesites escribirlo tú mismo. Y te brinda, y la razón principal por la que queremos hacer esto es porque te brinda una sintaxis más agradable y limpia al declarar valores predeterminados. Si has intentado declarar valores predeterminados con define props antes, sabes que lo haces con defaults, lo cual es realmente incómodo, esto es algo de lo que realmente queremos deshacernos y esto nos brinda una forma de hacerlo. Pero nuevamente, esta característica es un poco controvertida en el sentido de que introduce esta nueva magia del compilador que necesitas entender un poco más sobre cómo funciona el seguimiento de reactividad v- para entender por qué funciona, pero esperamos que las mejoras en la experiencia de desarrollo que proporciona eventualmente valgan la pena. Esto solo demuestra que si usas esta prop destructora dentro de un efecto de watcher, se realizará un seguimiento, al igual que props.message. Cada vez que cambian las props del padre, este console.log se bloqueará nuevamente.

Ahora, define model es otra característica experimental. Si alguna vez has creado un componente, por ejemplo, envolviendo un input nativo, y quieres tener un input personalizado con características más avanzadas, pero aún quieres que el consumidor del componente pueda usar el modelo con él. Anteriormente, era bastante verboso. Esto es lo que necesitas hacer. Primero debes declarar una prop llamada modelValue, luego también necesitas tener un evento correspondiente que se emitirá, y luego debes hacer tu conexión manual aquí en el input nativo y finalmente unir todo. Con la versión 3.3, esto es lo que necesitas hacer. Simplemente dices define model. Lo que te devuelve es una ref. Esta ref funciona como una ref normal. Puedes modificarla.

9. Mutating Refs and Advanced Level Usage

Short description:

Cuando lo mutas, simplemente emite el evento de vuelta al padre por ti. Y como es una ref, puedes vincularla a un input con el v-model nativo. Y luego está define options. Y hay un poco de nivel avanzado en esto. Si has usado la API de composición y has trabajado con composables, conoces Vue-use. Cuando usas Vue-use, puede aceptar un valor normal o una ref. Pero el problema es que, si quieres pasar una propiedad anidada profundamente, se vuelve complicado. Proporcionamos una nueva función llamada toValue para normalizar todo a un valor. Y está el JsyncPoSource, que tiene implicaciones potenciales para TSX.

Cuando lo mutas, simplemente emite el evento de vuelta al padre por ti, y si el valor del padre cambia, simplemente actualizará la ref por ti. Y como es una ref, puedes simplemente vincularla a un input con el v-model nativo. Así que luego puedes trabajar tu lógica adicional sobre esto, lo que hace que sea mucho más simple envolver un input nativo para construir tus componentes de input personalizados sobre ellos.

Y luego está define options. Así que cuando usas script setup, si aún necesitas declarar opciones adicionales, anteriormente necesitabas usar un bloque de script separado. Ahora simplemente usas la macro para que no necesites elegir bloques separados.

Y luego está este pequeño detalle de nivel avanzado. Entonces, si has usado la API de composición y has trabajado con composables, ¿alguien aquí ha usado Vue-use? Genial, cuando usas Vue-use, sabes que Vue-use normalmente puede, cuando quieres pasar algo a una función Vue-use, puede aceptar un valor normal o una ref, por lo que a nivel de tipo podemos pensar en ello como algo llamado maybe ref. Puedes pasar un valor o una ref, pero el problema con eso es, por ejemplo, si tienes un escenario como este, tienes props y dices que quieres pasar props.Vue en él, pero no puedo simplemente decir use feature props.Vue, porque de esa manera solo estoy pasando un valor que no se mantendrá reactivo. Entonces, lo que teníamos que hacer anteriormente es usar dos ref, así que dices two ref propsVue, estás creando una ref a partir de propsVue y luego la pasas a la función. Y el problema con eso es que two ref, la firma anterior, no es completamente flexible. La idea aquí es, ¿qué pasa si estás tratando de pasar una ref para una propiedad anidada profundamente? Entonces quieres decir two ref props.Vue bar. Ahora esto ya comienza a verse un poco extraño, y otra desventaja aquí es que no maneja el caso en el que foo puede o no estar presente. Entonces dices, está bien, puedo refactorizar esto, puedo usar una propiedad computada. Ahora simplemente voy a decir props.Vue?bar. Ahora esto manejará, no importa si foo está presente o no. El problema es que computed, a veces podemos usar computed sin pensar demasiado en ello, pero internamente, la computación tiene que crear un watcher que realiza un seguimiento de las cosas y los valores no válidos y todo eso. La forma más fácil de hacerlo es si tus composables simplemente admiten la aceptación de un getter. Entonces proporcionamos una nueva función llamada toValue para que puedas hacer eso. Lo que realmente hace es que dentro de tu composable, vas a decir que foo no es solo maybe una ref o un getter. Y toValue simplemente normaliza todo a un valor, sin importar si es un valor o una ref o un getter. Simplemente lo normaliza. Entonces puedes hacer esto y no necesitas preocuparte por lo que es foo. Puede ser cualquier cosa que el usuario quiera pasar y simplemente se normalizará. Y si piensas en las direcciones de normalización, en el medio tienes maybe, ref o getter. A la izquierda, puedes usar toRef para normalizar cada uno de ellos en refs. A la derecha, puedes usar toValue para normalizar cada uno de ellos en valores. Es solo una calle de doble sentido.

De acuerdo, luego está el JsyncPoSource. Quiero mencionar esto principalmente porque tiene una implicación potencial si estás usando TSX.

10. Soporte de TSX y Vue.js 1.0 Beta

Short description:

Si usas TSX con Vue, opta por esto ahora para evitar problemas cuando se elimine el registro global predeterminado en la versión 3.4. Pronto se lanzará Vue.js 1.0 beta, el generador de sitios estáticos. Se recomienda Vitepress como la mejor herramienta de documentación.

Si no usas TSX, no te concierne realmente, pero si usas TSX con Vue quieres optar por esto ahora para que cuando eliminemos el registro global predeterminado en la versión 3.4 no te afecte de ninguna manera. Entonces sí, ¿y qué sigue? Vue.js 1.0 beta muy pronto ahora que tenemos la versión 3.3. Este es el generador de sitios estáticos. Si has leído la documentación de Vue.js, la documentación de Vite, de hecho, muchos de estos nuevos proyectos, su documentación está construida en Vitepress y si tienes un proyecto propio y quieres documentarlo, pruébalo. Personalmente, creo que es la mejor herramienta de documentación disponible.

11. Vue Future Plans and Exciting Features

Short description:

Estamos planeando una ronda de limpieza de problemas principales de Vue y priorizando problemas importantes para el próximo sprint menor. En la versión 3.4, nuestro objetivo es estabilizar el suspense, mejorar el teleport seguro y mejorar las invalidaciones de cálculo. También tenemos planes emocionantes para el modo Vapor y características adicionales de la plataforma. La propuesta de ámbito de la aplicación nativa en el Grupo de Trabajo CSS simplificará la implementación de estilos con ámbito en Vue. El contexto asíncrono rastreará la inicialización del componente en pilas de llamadas asíncronas y las partes del DOM serán un objetivo de compilación crucial para el modo Vapor. Estos avances harán que VueCorp sea más simple y eficiente.

Lo siguiente que haremos es una ronda de limpieza de problemas principales de Vue. Tenemos varios problemas importantes de prioridad 4 que queremos abordar antes del próximo sprint menor. Luego, en la versión 3.4, algunas de las cosas que queremos priorizar son estabilizar el suspense, algunas mejoras, construir un teleport seguro y unas invalidaciones de cálculo más eficientes. El objetivo para las futuras versiones menores es mantenerlas más pequeñas en alcance, para que podamos lanzar más a menudo, lanzar más rápido. En el tercer y cuarto trimestre, seguiremos trabajando en el modo Vapor y habrá algunas características adicionales de la plataforma a tener en cuenta. Si te interesa cómo el futuro de Vue interactuará con el nuevo uso de las iniciativas de la plataforma. Una cosa emocionante es la propuesta de ámbito de la aplicación nativa que se está llevando a cabo en el Grupo de Trabajo CSS. En resumen, esta característica nos permitirá implementar completamente la implementación de estilos con ámbito de Vue para que sea mucho más simple y eficiente, lo cual es genial. Menos dentro del framework y más aprovechado en las características nativas de la plataforma. Y luego está el contexto asíncrono, que nos permite rastrear el contexto actual del componente en una pila de llamadas asíncronas. Por lo tanto, en la configuración asíncrona, los métodos asíncronos y las acciones pnet asíncronas, podremos saber qué componente lo inicializó. Y luego están las partes del DOM, que serán un objetivo de compilación importante para el modo Vapor. Muchos de estos están más cerca de la materialización y de las partes del DOM, que están en una etapa muy temprana. Pero estas son las cosas en las que estamos atentos, estamos emocionados. Creemos que ayudarán a que VueCorp sea más simple y eficiente.

¡Y eso es todo! Gracias. Muchas gracias a todos. Por favor, pasen a mi oficina. Recuerden, si tienen alguna pregunta, pueden ir a Slido y hacerla. Y mientras esperamos a que la gente saque sus teléfonos y haga algunas preguntas, tengo una pregunta para ustedes. Acaban de anunciar Vue 3.3 y tienen tantas características diferentes, algunas de las características de las que hablaron hoy. ¿Cómo priorizan en cuáles quieren trabajar y qué características les emocionan más?

¿Te refieres dentro de la versión? Sí. Personalmente, estoy más emocionado por el soporte externo de tipos, el soporte de tipos importados, principalmente porque ha sido un desafío técnico para mí y durante mucho tiempo dudamos si era posible, pero finalmente lo logramos en 3.3. Así que eso es algo bueno para mí, me siento aliviado de poder lograrlo. Y en general, creo que todas estas características juntas nos dan una buena confianza para decir que los componentes de un solo archivo de Vue, especialmente con la configuración de script, ahora funcionan muy bien con TypeScript. Tendrás una experiencia de desarrollo realmente buena cuando uses TypeScript con Vue. Eso es lo más importante para mí. Genial. Es increíble. Así que tenemos algunas preguntas que llegan.

12. Vapor Mode and Unref Compatibility

Short description:

El modo Vapor en Vue 3 es una nueva forma de compilar plantillas en un código más eficiente en memoria y de mejor rendimiento. Es compatible con el formato de componente existente y ofrece una experiencia de desarrollo más ligera y rápida. Sin embargo, tiene un conjunto limitado de características admitidas. Además, cambiar unref para admitir getters no es posible debido al diseño actual de la API y los posibles cambios disruptivos que introduciría.

Algunas preguntas, ¿qué es el modo Vapor? Correcto. He mencionado esto varias veces en conferencias anteriores. Actualmente, la forma en que Vue funciona es que compilamos tus plantillas a JavaScript. Y el JavaScript que producimos actualmente todavía se llama funciones de renderizado del Virtual DOM. Así que todavía hay algo llamado un Virtual DOM runtime. En Vue 2, nos enfocamos en el Virtual DOM principalmente porque queríamos proporcionar capacidades de renderizado en el servidor. En Vue 3, nos dimos cuenta de que el Virtual DOM tiene ciertos costos en memoria y rendimiento, por lo que ya estamos realizando muchas optimizaciones en tiempo de compilación para que el código del Virtual DOM generado sea lo más eficiente posible. Pero aún así, no será tan bueno como si pudiéramos omitir por completo el Virtual DOM y usar una estrategia de generación de código completamente diferente.

Entonces, el modo Vapor es esencialmente esta nueva forma. Va a tomar el mismo formato de componente, el mismo componente de archivo único con la misma sintaxis de plantilla. Nada necesita cambiar. Inicialmente, admitirá un subconjunto de las características, pero será 100% compatible. Simplemente tomamos el mismo código de plantilla y lo compilamos en algo que será bastante diferente en su núcleo. Será mucho más eficiente en memoria, más eficiente en rendimiento y generará un código más ligero, también requerirá menos código en tiempo de ejecución. En general, es algo que será en gran medida transparente en el nivel de experiencia de desarrollo, simplemente optas por utilizarlo. Cuando optas por utilizarlo, obviamente estarás limitado a un conjunto de características que admite, pero será la misma experiencia de Vue. Pero el código que genera será mágicamente más ligero, más rápido y más eficiente. Me encanta cuando las cosas se vuelven mágicamente más ligeras y eficientes detrás de escena.

Así que muchas gracias. También tenemos otra pregunta, y creo que voy a leer la última línea de esta pregunta primero, que es, se ve increíble por cierto, pero ¿por qué no cambiar unref para admitir getters de modo que las implementaciones componibles existentes ya lo admitan? Esa es una buena pregunta, de hecho. Si lo piensas, ref y unref son los dos contrapartes. Entonces, ¿qué sucede cuando pasas una función a ref? Unref lo que hace es crear un ref utilizando esa función como su valor. Unref tiene el mismo problema. Entonces, si unref recibe una función, lo que hace actualmente es, la premisa actual de la API de unref es, digamos, si lo que recibí es un ref, lo devolveré como valor. Si no es un ref, simplemente devolveré el valor tal cual. Y una función en realidad cae en la categoría de no ser un ref aquí. Entonces, si cambiamos unref para simplemente llamar a la función y devolver su valor de retorno, en realidad sería un cambio disruptivo. Así que desafortunadamente, pensé en admitir eso en primer lugar. Pero nos dimos cuenta de que es un cambio disruptivo. Y no podemos hacer eso.

QnA

Vue API: toValue, TSX, and Composition API

Short description:

Introdujimos toValue como una nueva API que funciona de manera similar a unref pero llama a funciones. Al implementar componentes recursivos y dinámicos, se prefiere TSX para casos de uso altamente dinámicos. Se recomienda el uso de la Composition API en lugar de la Options API para construir bases de código a gran escala y mantenibles, gracias a su mejor integración con TypeScript y su capacidad de composición.

Así que necesitamos una nueva API para eso. Por eso introdujimos toValue. Entonces, toValue, básicamente, puedes pensar en ello como unref, pero simplemente llamará a funciones. Sí. Gracias. Gracias. Y gracias, Canan, también, por hacer esa pregunta.

Tenemos otra pregunta de Mitch. Si intentas implementar componentes recursivos y dinámicos, ¿recomendarías TSX en lugar de usar un SFC? ¿Usando CSS? TSS. Oh, TSX. ¿Componentes recursivos? No creo que haya una diferencia fundamental aquí. Por lo general, cuando las personas recurren a TSX, es porque tienen que lidiar con una gran cantidad de renderizado de componentes dinámicos basados en una estructura de datos, típicamente. Esto sucede mucho en componentes basados en configuración, como un componente de tabla que recibirá un objeto de opciones para especificar qué campos se mostrarán en el encabezado, qué filas se mostrarán, etc. Todo es altamente dinámico y realmente tendrás dificultades para expresar esta lógica utilizando la sintaxis de plantilla, pero el uso de TSX te permite construir programáticamente el árbol de componentes basado en estos valores de opción, y ese es el caso más común donde las personas prefieren TSX. Los componentes recursivos pueden caer en eso, pero si solo son recursivos, realmente no tienes que hacerlo, pero realmente depende de qué tan dinámico sea tu caso de uso. Gracias. Gracias por la pregunta una vez más. También tenemos otra pregunta. Y chicos, también pueden votar las preguntas para asegurarse de que las hagamos todas, tantas como podamos. Tenemos muchas preguntas y si no llegamos a todas, asegúrate de encontrar a Evan arriba. Pero siguiendo adelante, tenemos otra pregunta que pregunta sobre la Composition API. ¿Dirías que Vue está cambiando a favor del uso de la Composition API con todas las nuevas características que estás lanzando para dejar de fomentar el uso de la Options API en algún momento, o la Options API siempre tendrá algunos casos en los que se fomentará sobre la Composition API? En este momento, para ser 100% honesto, no creo que haya casos en los que recomendaría la Options API sobre la Composition API. La clara ventaja de la Options API, diría que está disminuyendo, especialmente cuando se considera TypeScript. Pero en realidad, nuestra productividad a veces no es una métrica completamente objetiva. Puede estar asociada con tus preferencias subjetivas. Cuando estás más satisfecho con la API, eres más productivo. Entonces, si tienes fuertes preferencias personales con los estilos de API, no diría que debas ir en contra de eso. Pero si lo piensas desde una perspectiva puramente pragmática, estás diciendo que quieres construir una base de código a gran escala y mantenible. Entonces, recomendaría usar la Composition API, principalmente debido a una mejor integración con TypeScript y la capacidad de composición, la capacidad de tomar un componente que has escrito y extraer partes de él, reordenar cosas y reutilizar cosas en diferentes componentes. En general, la Composition API se presta mucho mejor a estas prácticas en comparación con la Options API.

Tips for Working in a Development Team

Short description:

Si estás personalmente bien con procedimientos estrictos o más flexibilidad en un equipo de desarrollo, en última instancia depende de la dinámica del equipo y el acuerdo mutuo. Se necesita cierto nivel de convención de código y reglas aplicadas para la productividad a largo plazo, pero ser demasiado pedante puede obstaculizar el progreso. Encontrar un equilibrio es clave.

Entonces es una apuesta mejor a largo plazo. Pero si estás haciendo tu propia cosa personal y dices que la API de Opciones todavía se siente bien, y no has encontrado limitaciones con ella, entonces puedes usarla sin problemas. Me encanta cómo incluyes tu felicidad o satisfacción como desarrollador en la producción o en el ciclo de desarrollo como uno de los factores por los que elegirías uno sobre el otro.

Lo cual me lleva perfectamente al siguiente punto, que son los mejores tips para trabajar juntos en un equipo de desarrollo. ¿Prefieres procedimientos estrictos o más flexibilidad? ¿Deberían las personas ser flexibles y estar contentas en su propio entorno? ¿O estrictos y vamos a construir el mejor código posible? Creo que esto tiene mucho que ver con la dinámica del equipo en primer lugar, ¿verdad? Creo que depende de cuando tienes un equipo, si tienes un equipo formado por personas con opiniones muy diferentes y también muy arraigadas, entonces no va a ser productivo de ninguna manera, ¿verdad? Entonces lo importante es que el equipo esté de acuerdo en lo que mutuamente aceptan como algo con lo que pueden trabajar. Personalmente, para mí, creo que va a ser realmente una decisión del equipo. Si, por ejemplo, tomo un trabajo y me uno a un equipo, personalmente estaré bien con cualquier dirección. Depende de lo que decidan los líderes del equipo. Creo que se necesita cierto nivel de convención de código y reglas aplicadas si quieres una productividad a largo plazo. Pero no quieres ser demasiado pedante al respecto. Pondría un ejemplo, ahora mismo, la forma en que formateo mi código es usando Prettier y atrapo errores con TypeScript. Ya no uso mucho ESLinks. Entonces, si me uno a un proyecto con las reglas de Airbnb ESLink, diría que no. Eso es a lo que me refiero con ser pedante. Y en tus equipos, ¿en qué parte de esa escala dirías que se encuentran? Probablemente un poco más hacia el extremo de la flexibilidad.

Vue y la Magia de la Compilación

Short description:

La tendencia en todos los frameworks es hacia una mayor magia de compilación. React Server Components, SvelteKit y Solid Start también dependen en gran medida de la compilación. La realidad es que nos estamos moviendo hacia un escenario de frameworks impulsados por el compilador. Angular también está explorando los componentes de un solo archivo. No me preocupa que Vue se aleje del ecosistema de JavaScript porque todos están adoptando frameworks impulsados por el compilador.

Genial. Otra pregunta, ¿te preocupa que Vue esté agregando demasiada magia de compilación y se aleje lentamente del resto del ecosistema de JavaScript? Tienes el ecosistema de JavaScript y luego todas estas burbujas. ¿Te preocupa en algún momento que Vue se aleje de eso? No lo creo. De hecho, si observas la tendencia general, la tendencia general en todos los frameworks es que hay cada vez más magia de compilación. Los React Server Components requieren mucha magia de tipo compilador. Ya sabes, Server Actions, que acaban de introducir recientemente, SvelteKit, Svelte es posiblemente aún más mágico en términos de compilación. ¿Verdad? Solid Start también tiene mucha magia de compilación involucrada. Entonces, creo que la tendencia general es que las personas, les guste o no, la realidad es que nos estamos moviendo hacia un escenario de frameworks impulsados por el compilador. Y en cuanto a - y si también miras Angular, hay mucho interés en la comunidad de Angular en este momento en explorar los componentes de un solo archivo para Angular. Entonces, creo que diría que no, no me preocupa eso, porque todos están haciendo más cosas de compilación en estos días. Es como lo que dijiste, hacer las cosas en segundo plano para que sean más eficientes. Realmente aprecio cuando haces cosas así por nosotros. De verdad lo hago. Y el último, porque sé que casi se nos acaba el tiempo, ¿cuál es tu consejo para los equipos que pasan de Vue 2 a Vue 3? Un cambio grande como ese siempre es importante. ¿Tienes algún consejo para las personas? Sí, mi consejo honesto es que necesitas hacer una exploración preliminar, como la situación realmente varía en función de cómo estés usando actualmente Vue 2. Entonces, si tienes un solo proyecto con una definición clara, que no te desvías demasiado de cómo hacemos las cosas por defecto, entonces migrar a Vue 3 es 100% factible. Pero la situación va a variar mucho según las dependencias que uses. ¿Usas alguna configuración de compilación personalizada loca? Hay muchas cosas que están fuera del control del núcleo de Vue para poder determinar completamente lo fácil que será para ti migrar a Vue 3. Y tengo que admitir que en algunos casos, tal vez no sea la mejor idea actualizar. Entonces, creo que como mínimo, actualizar a la versión 2.7 y combinarlo con los macros de Vue te dará un porcentaje muy decente de todas las cosas buenas que esperarías de Vue 3. Y si el rendimiento actual y todo eso no te está causando problemas notables, entonces es una decisión razonable quedarse en Vue 2. Y si te preocupa el cumplimiento del ciclo de vida, entonces obviamente hay desarrolladores expertos que pueden ayudarte con eso. Entonces sí, la triste verdad es que es realmente difícil darte una declaración general y decir, oh, puedes actualizar. Realmente depende de muchos de estos pequeños factores en los que tienes que mirar caso por caso. Entonces, nuestro esfuerzo se centra en asumir que tienes una sola aplicación que utiliza nuestras prácticas recomendadas estándar, luego te damos este camino que se describe en la guía de migración. Utilizas el código de migración, comienzas a reemplazar tus dependencias una por una y eventualmente te deshaces de todas las advertencias de migración y luego estás en Vue 3. ¡Perfecto! Muchas gracias, aplaudamos a Evan una vez más. Gracias.

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.
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.

Workshops on related topic

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
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.
JSNation 2022JSNation 2022
141 min
Going on an adventure with Nuxt 3, Motion UI and Azure
WorkshopFree
We love easily created and deployed web applications! So, let’s see what a very current tech stack like Nuxt 3, Motion UI and Azure Static Web Apps can do for us. It could very well be a golden trio in modern day web development. Or it could be a fire pit of bugs and errors. Either way it will be a learning adventure for us all. Nuxt 3 has been released just a few months ago, and we cannot wait any longer to explore its new features like its acceptance of Vue 3 and the Nitro Engine. We add a bit of pizzazz to our application with the Sass library Motion UI, because static design is out, and animations are in again.Our driving power of the stack will be Azure. Azure static web apps are new, close to production and a nifty and quick way for developers to deploy their websites. So of course, we must try this out.With some sprinkled Azure Functions on top, we will explore what web development in 2022 can do.
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
- Intro 3D - Intro WebGL- ThreeJS- Why TresJS- Installation or Stackblitz setup - Core Basics- Setting up the Canvas- Scene- Camera- Adding an object- Geometries- Arguments- Props- Slots- The Loop- UseRenderLoop composable- Before and After rendering callbacks- Basic Animations- Materials- Basic Material- Normal Material- Toon Material- Lambert Material- Standard and Physical Material- Metalness, roughness - Lights- AmbientLight- DirectionalLight- PointLights- Shadows- Textures- Loading textures with useTextures- Tips and tricks- Misc- Orbit Controls- Loading models with Cientos- Debugging your scene- Performance
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.

Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
Prerequisites:
VSCode setup and an empty Vite + Vue project.