API de opciones vs API de composición: elegir el enfoque adecuado para tu equipo

Rate this content
Bookmark

Con la introducción de la API de composición en el ecosistema de Vue, muchos se preguntan qué deberían elegir. ¿API de opciones? ¿API de composición? ¿Cuál es la mejor opción? ¿Cuáles son los compromisos? En esta charla, examinaremos los dos enfoques para que puedas tomar la decisión correcta para tu aplicación.

23 min
21 Oct, 2021

Video Summary and Transcription

La charla de hoy analiza la API de opciones y la API de composición en Vue 3, destacando las diferencias y consideraciones al elegir un enfoque. La API de composición ofrece más flexibilidad e integra bien con TypeScript, pero puede requerir más familiaridad con JavaScript. Combinar ambas APIs permite estructura y flexibilidad, con la capacidad de mejorar progresivamente el código. Se deben considerar las preferencias del equipo y el nivel de uso de TypeScript al elegir el enfoque adecuado para un proyecto.

Available in English

1. Introducción a la API de Opciones y la API de Composición

Short description:

Hoy estamos aquí para hablar tanto de la API de Opciones como de la API de Composición y cómo elegir el enfoque adecuado para tu equipo. Soy un ingeniero de experiencia de desarrollo en Netlify, en el equipo principal de Vue, embajador de Nuxt, instructor de Vue Mastery y experto en desarrollo de Google.

¿Qué tal Vue London? ¿Cómo va todo? Estoy emocionado hoy porque estoy aquí para hablar de algo que, bueno, se ha discutido bastante dentro de la comunidad de Vue, y eso es la idea completa de si usar la API de Opciones o la API de Composición. Así que hoy estamos aquí para hablar de ambas y cómo elegir el enfoque adecuado para tu equipo. Para aquellos que no me conocen, mi nombre es Ben Hong y pueden encontrarme en Internet de las Cosas bajo el nombre de usuario BenCodeZen. Un poco sobre mí si no han encontrado mi trabajo antes. Soy un ingeniero de experiencia de desarrollo en Netlify. Estoy en el equipo principal de Vue, pasando la mayor parte de mi tiempo principalmente en la documentación, así como en actividades relacionadas con la comunidad, y también soy embajador de Nuxt, lo cual, si no lo han escuchado, estoy muy emocionado porque la versión beta pública de Nuxt ya está disponible, así que asegúrense de revisar eso. También soy instructor de Vue Mastery y experto en desarrollo de Google en tecnologías web y matplatform. Muy bien, para comenzar, enfrentémoslo, antes de Vue 3 las cosas eran, bueno, más simples. ¿Más simples cómo? Bueno, porque solo había una forma de escribir nuestros componentes, así que en otras palabras, esto es lo que básicamente hemos llegado a conocer como la API de Opciones. Y para asegurarnos de que todos estemos en la misma página, aquí tenemos un componente aquí que contiene tus cosas estándar de la API de Opciones. Entonces, lo que tenemos aquí en la parte superior es un bloque de script y luego dentro de aquí estamos exportando un objeto por defecto y luego tenemos cosas como tus data, tus propiedades computadas, así como los métodos que estás llamando dentro de esta plantilla que se encarga de renderizar esas cosas o llamar a los métodos apropiados . Y por lo tanto, dado que tenemos estos lugares con opiniones sobre dónde colocar tu código, es decir, data, métodos computados, esto era la API de Opciones. Bueno, con la introducción de la API de Composición en Vue 3, bueno, se complicó un poco más porque ahora, vayamos y, en caso de que las personas no sepan qué es la API de Composición, hagamos una breve descripción de la diferencia. Entonces, aquí en nuestra API de Opciones tenemos formas muy opinadas de cómo colocamos nuestros data. Bueno, lo primero que puedes notar cuando se trata de la API de Opciones, o lo siento, lo primero que puedes notar cuando se trata de la API de Composición es que estamos usando el método Setup. Así que vamos a mover todo hacia abajo, verás que esta función de configuración dentro de nuestro objeto exportado. Y dentro de aquí, lo que vamos a hacer, vamos a comenzar a mover cosas para mostrarte cómo se ve en la API de Composición. Lo primero es lo primero, tomaremos el data, la propiedad count de cero, y lo moveremos hacia arriba y lo declararemos con un const de count cero. Y luego necesitaremos hacerlo reactivo para que Vue lo rastree. Así que vamos a importar el ref que lo convierte en una referencia reactiva. Y envolvemos el valor cero en él. Y ahora count es básicamente una referencia reactiva de cero. Y luego, las propiedades computadas se convierten en algo que realmente podemos usar como un método auxiliar similar a ref. Así que lo importaremos aquí. Y luego, lo que hace de manera similar es declarar una variable de double count, y devuelve el valor count de la referencia reactiva multiplicado por dos. Así que actúa exactamente de la misma manera. Y finalmente, nuestros métodos aquí increment count. Nuevamente, como en el JavaScript normal aquí, const increment count, es una función. ¿Y qué hace? Incrementa el valor de count más más.

2. Introducción a Script Setup y la API de Opciones

Short description:

Ahora no entraremos en detalles sobre cómo funciona ref y todas estas cosas. Pero aquí tienes un nivel alto de lo que sucede cuando estas cosas se mueven a la API de Composición. Y debido a que estamos en el método de configuración de tener todo exportado en este punto. Una pieza más que necesitamos tener es decirle explícitamente a Vue qué queremos exponer al componente, porque a veces ciertas cosas son más como métodos privados o variables privadas. Y estas son cosas que queremos exponer a la plantilla. Y así que convertimos un objeto de manera muy similar a la propiedad data. Para aquellos de ustedes que han estado siguiendo de cerca, Vue 3.2 lanzó otra forma de escribir componentes, aunque otra debería estar entre comillas, porque realmente es una mejora en cuanto a la experiencia de desarrollo sobre la API de Composición, y eso es la nueva sintaxis de script setup. Y así que hablemos de los tres enfoques diferentes que diría que generalmente las personas tienen que elegir cuando se trata de esto. El primero de ellos es la API de Opciones pura. Es muy fácil de aprender y proporciona una sensación de consistencia entre los componentes. Sin embargo, también es opinada.

Ahora no entraremos en detalles sobre cómo funciona ref y todas estas cosas. Pero aquí tienes un nivel alto de lo que sucede cuando estas cosas se mueven a la API de Composición. Y debido a que estamos en el método de configuración de tener todo exportado en este punto. Una pieza más que necesitamos tener es decirle explícitamente a Vue qué queremos exponer al componente, porque a veces ciertas cosas son más como métodos privados o variables privadas. Y estas son cosas que queremos exponer a la plantilla. Y así que convertimos un objeto de manera muy similar a la propiedad data. Para aquellos de ustedes que han estado siguiendo de cerca, Vue 3.2 lanzó otra forma de escribir componentes, aunque otra debería estar entre comillas, porque realmente es una mejora en cuanto a la experiencia de desarrollo sobre la API de Composición, y eso es la nueva sintaxis de script setup. Así que hagamos una revisión rápida sobre eso. De vuelta en nuestro ejemplo de contador, podemos ver aquí que tenemos el método de la API de Composición que básicamente mostramos la transición anterior que migramos desde las opciones. Vamos a mostrar cómo se ve el script setup. Lo primero es que vamos a eliminar el objeto de exportación, porque lo que hace el script setup es decir que vamos a asumir que solo quieres usar la API de Composición, por lo que no vamos a exportar un objeto. Y lo que es más importante, sabemos que vas a configurar métodos. Entonces, ¿por qué hacerte definir eso de nuevo? Lo que vamos a hacer es mover ese método de configuración y moverlo como un atributo llamado script setup. Específicamente, setup es un atributo de script y, como resultado, el compilador sabe hacer cosas especiales con el código dentro. Ahora que tenemos el script setup, también sabemos que podemos hacer alguna especie de detección automática de lo que probablemente quieres exponer al componente. Entonces, lo que también podemos hacer es eliminar la exposición manual de variables, lo cual es bastante agradable. Y así obtienes este código que es bastante limpio y fácil de entender. Y como resultado, tienes una API de Composición pura utilizando el script setup. Básicamente, una mejora en la experiencia de desarrollo. Por supuesto, algunos de ustedes probablemente se preguntan nuevamente, porque la pregunta que todos siguen queriendo hacer es, ¿cuál es la correcta? Así que hablemos de los tres enfoques diferentes que diría que generalmente las personas tienen que elegir cuando se trata de esto. Y el primero de ellos, como puedes imaginar, es la API de Opciones pura. En otras palabras, para reiterar, lo que tenemos aquí es nuestro componente con nuestras opciones explícitas, ¿verdad?, con data, computed methods, y nos quedamos con la estructura y ni siquiera tratamos con la API de Composición. Bueno, lo que sucede con esto es que cuando se trata de la API de Opciones, hay un par de ventajas que quiero destacar, y la primera de ellas es que es muy fácil de aprender, ¿verdad? Esa es una de las razones por las que creo que la API de Vue 2 fue tan popular entre la gente, porque en realidad era bastante fácil de entender en cuanto a dónde iban las cosas, y todos seguían la misma estructura. Y así, incluso desde mi propia experiencia personal, enseñé a alguien que básicamente era un diseñador en tecnología pero que no había codificado durante años, pero básicamente en la primera hora de tomar un taller de Vue 101 donde estaban preocupados de que no iban a poder seguir porque sus habilidades de JavaScript realmente no estaban a la altura. En realidad, pudieron entender rápidamente, y antes de darse cuenta, estaban siguiendo y construyendo cosas, lo cual fue muy emocionante para ellos, y se sintieron realmente empoderados por eso, y esto es una de las cosas que siempre les recuerdo a las personas, que la API de Opciones es realmente genial en este sentido. Y luego, como mencionamos, porque es extremadamente estructurada, obtienes una sensación de consistencia entre los componentes porque todos saben que data va en data, computed va en computed, y así sucesivamente. Y como resultado, obtienes una sensación de simplicidad, ¿verdad? Especialmente cuando se trata de cómo se escribe el código y porque sabes que cada vez es predecible. Pero por otro lado, también hay desventajas, ¿verdad? Cada decisión en tecnología tiene sus compensaciones. Eso es algo que siempre trato de recordarles a las personas cuando se trata de estas cosas.

3. Razones para la introducción de la API de Composición

Short description:

Si no quieres organizar tu código utilizando la API de Opciones, se vuelve difícil hacer diferentes patrones. La API de Composición se introdujo para proporcionar más flexibilidad. Sin embargo, con Vue 3, la API de Opciones puede sentirse incómoda para el soporte de TypeScript.

y así, en primer lugar, es realmente opinada. En otras palabras, si no quieres organizar tu código de esta manera, se vuelve bastante difícil básicamente sortear o hacer diferentes patrones, y esta es una de las razones por las que se introdujo la API de Composición. Como resultado, vas a obtener menos flexibilidad, ¿verdad? Además de esa estructura opinada, porque ahora tienes que lidiar con el hecho de que tienes que separar cosas que tal vez no quieras. Tal vez quieras mantener tus métodos o data juntos de una manera más modularizada, y esa flexibilidad se volvió un poco difícil de lograr en la API de Opciones. Y la cosa es que con Vue 3, si bien muchas cosas ahora son mucho más amigables con TypeScript, entre aquellos que están aprendiendo TypeScript y realmente les gusta, la API de Opciones puede sentirse un poco incómoda cuando se trata del soporte de TypeScript porque estás haciendo cosas un poco diferentes a lo que harías normalmente al escribir un módulo cuando lo estás exportando

4. Enfoque puro de la API de Composición

Short description:

El segundo enfoque es un enfoque puro de la API de Composición, donde todo es básicamente JavaScript puro. Tienes la libertad de organizar tu código como desees y diseñarlo según tus preferencias. Este enfoque ofrece mucha flexibilidad, permitiendo que tus datos y cálculos se organicen de la manera que desees. Proporciona la sensación de trabajar solo con JavaScript, aunque puede haber cierta confusión debido a la abstracción y la conexión automática de cosas en segundo plano.

La segunda aproximación, como podrías esperar, es un enfoque puro de la API de Composición. Entonces, en este sentido, vamos a seguir adelante, y como recordatorio, permíteme mostrar el ejemplo de código de configuración del script que podemos ver aquí, y aquí es donde no hay más opciones. Todo es básicamente JavaScript puro. Puedes organizar tu código como desees y tienes la libertad de hacer y diseñar lo que quieras. Ahora, esto es bueno, ¿verdad? Hay muchas ventajas en esto. Como puedes imaginar, el hecho de que sea básicamente JavaScript puro con algunos métodos auxiliares te brinda mucha flexibilidad porque ahora tus datos pueden ir a donde quieran, tus cálculos pueden ir a donde quieran, como desees organizarlo, y como resultado, obtienes esta sensación de solo JavaScript porque, nuevamente, la razón por la que puse esto entre comillas es porque muchas veces, cuando se trata del código, la API de Objetos también es solo JavaScript, pero debido a que utiliza cosas como esta y hay un poco más de abstracción en segundo plano en cuanto a la conexión automática de cosas para ti, es aquí donde las personas, creo, se ponen un poco más nerviosas debido a este contexto que puede, bueno, tradicionalmente es muy confuso cuando se trata de JavaScript.

5. Combinando la API de Opciones y la API de Composición

Short description:

La API de Composición se siente más como JavaScript, se integra bien con TypeScript, pero también requiere más familiaridad con JavaScript y puede llevar a anti-patrones. Combinar tanto la API de Opciones como la API de Composición permite tener estructura y flexibilidad.

Entonces, como resultado, obtienes más de esta sensación de, como, declaro una constante, hago una ref, lo organizo como quiero, y en este sentido, creo que se siente un poco más como solo JavaScript. Y debido a esta especie de sintaxis de mantenerlo como el JavaScript normal que escribes en módulos, uno de los beneficios, el resultado es que la sintaxis de TypeScript y todo se integra de manera mucho más limpia porque ahora no tienes esa abstracción en segundo plano que sucede con este contexto y esta especie de cosa. Por lo tanto, muy, muy amigable con TypeScript. Por otro lado, una vez más, ninguna tecnología está exenta de sus compensaciones. Curiosamente, debido a que tenemos flexibilidad, la flexibilidad en sí misma, argumentaría, también es una desventaja en sí misma. En otras palabras, es un poco una espada de doble filo. Después de todo, si lo piensas, porque ya no tienes esta estructura que las personas siguen consistentemente, hay más oportunidades para crear anti-patrones y mucha de la responsabilidad ahora recae en ti. Y esto significa que si cometes errores en cuanto a la arquitectura, es tu responsabilidad resolverlo más adelante. O, por ejemplo, si alguien hace algo incorrecto con la arquitectura y luego se lo pasa a otra persona, se necesita mucha más navegación que debe ocurrir. Mientras que, por ejemplo, con la API de Opciones, todos sabían dónde estaba el código en todo momento. Además, esto es un poco una situación mixta, pero diría que, en comparación con las Opciones, tiene una barrera de entrada más alta porque la API de Composición requiere ciertos conocimientos previos de JavaScript. Y aunque eso puede sonar un poco extraño al principio, debemos entender que cuando se trata de la API de Opciones, hay mucho que las personas pueden asumir con los patrones, ¿verdad? Esta abstracción y el hecho de que siempre escribas las cosas de cierta manera permiten que las personas que quizás no entiendan completamente cómo funciona JavaScript aún hagan muchas cosas poderosas o incluso experimenten o realicen cambios menores sin tener que saber mucho JavaScript. Pero, por otro lado, si tienes un sólido conocimiento de JavaScript, nuevamente, esta es la otra cara de la moneda, algunas personas pueden encontrar la API de Composición más fácil porque ya tienen ese requisito previo de JavaScript. Entonces piensan: 'Oh, entiendo cómo importar métodos auxiliares, sé cómo exportar módulos, todo esto tiene sentido'. Mientras que con la API de Opciones está integrado. Hay dos lados de la moneda, pero como resultado, hay una barrera de entrada un poco más alta para aquellos que no están tan familiarizados con JavaScript. Y nuevamente, al igual que el primer punto sobre la flexibilidad, la falta de estructura puede ser un problema si los desarrolladores no están utilizando las mejores prácticas cuando se trata de la arquitectura de sus aplicaciones, así que ten en cuenta que puede ser un poco complicado a veces cuando se trata de escalar proyectos porque ahora realmente depende de tu capacidad para mantener esa consistencia en una gran base de código, en comparación una vez más con la API de Opciones, donde cada componente siempre se veía básicamente igual.

Ahora, el tercer enfoque aquí es el que creo que vale la pena mencionar, que es que puedes combinar tanto la API de Opciones como la API de Composición. Y aquí tenemos en este código, tenemos el componente para la API de Opciones y la API de Composición. Y lo que vemos aquí es la exportación predeterminada estándar. Y esta vez, toda nuestra configuración de la API de Composición está definida y configurada. Y lo que es genial de esto es que básicamente todo esto ahora está expuesto para que la API de Opciones lo utilice y luego lo ingiera. Entonces, lo que vemos aquí ahora es que realmente podemos construir sobre eso. Digamos que queremos una propiedad como triple count, similar al double count, pero simplemente devolvemos this.count multiplicado por tres. Bueno, porque todo se ha configurado en el método de configuración, ¿ves cómo funciona ese nombre? Básicamente permite que se exponga para que la API de Opciones lo use y luego básicamente construya sobre él. Y esto, para mí, es probablemente donde veremos mucho de, cómo puedo decir esto, y lo que es realmente bueno de esto es que básicamente obtienes un poco de ambos mundos, lo mejor de tener cierta estructura y consistencia mientras aprovechas lo que hace que la API de Composición sea realmente poderosa. Así que repasemos, al igual que antes, los pros y los contras de esto. Bueno, el primero de ellos es que obtienes estructura con cierta flexibilidad. Entonces, en otras palabras, tenemos esas opciones consistentes, pero al mismo tiempo, podemos inyectar

6. Choosing the Right Approach

Short description:

Otra ventaja de utilizar un enfoque híbrido es la capacidad de mejorar progresivamente el código y agregar características de la API de Composición sin refactorizar todo. Sin embargo, utilizar dos enfoques requiere una mejor comprensión de ambas metodologías y puede tener una curva de aprendizaje. El enfoque híbrido proporciona amigabilidad con TypeScript y similitudes entre la API de Composición y la API de Opciones. Puede ser un poco verboso y no tan amigable con TypeScript como la API de Composición pura. La elección del enfoque adecuado depende de la base de código, la composición del equipo y el nivel de uso de TypeScript.

flexibilidad cuando la necesitamos. Y luego, por otro lado, la estructura sigue estando ahí para nosotros. Otra cosa buena de este enfoque es que puedes mejorar progresivamente el código. En otras palabras, especialmente si estás trabajando con una base de código que ha existido durante un tiempo, y ya estás utilizando opciones, por ejemplo, hay una forma de mejorar progresivamente tu código hay una forma de agregar progresivamente características de la API de Composición sin tener que refactorizar todo y reescribir todo tu código, lo cual, nuevamente, es uno de los puntos fuertes de Vue en cuanto a su flexibilidad para adaptarse a diferentes situaciones.

Además, porque ahora tienes la capacidad de fusionar básicamente las cosas de la API de Composición con la API de opciones, tienes más amigabilidad con TypeScript de la que tendrías si hubieras utilizado solo la API de opciones. Así que es algo a tener en cuenta. Sin embargo, en cuanto a las desventajas, como podrías esperar, debido a que estás utilizando dos enfoques, esto significa que debes tener una mejor comprensión de ambas metodologías. Y esto es una desventaja en el sentido de que hay un poco más de curva de aprendizaje, porque eso significa que las personas que estaban muy familiarizadas con la API de opciones ahora también deben conocer la API de Composición, y viceversa, aquellos que conocían la API de Composición también necesitarán conocer la API de opciones. Pero nuevamente, una de las cosas interesantes que diría cuando se trata de eso es que muchas personas cuando usan Vue ya están familiarizadas con las opciones desde el principio. Y lo que es más importante, los principios que creo que impulsan la API tanto de Composición como de Opciones en cuanto a los hooks del ciclo de vida, las propiedades computadas, los datos reactivos, son en su mayoría muy, muy similares. Entonces, con suerte, aunque hay dos enfoques diferentes, hay similitudes y con suerte la curva de aprendizaje no es tan difícil.

Dicho esto, como vimos anteriormente con la configuración del script, puede ser bastante conciso. Pero ahora que tienes ambos, puede ser un poco verboso a veces porque tienes que definir manualmente tus retornos. Y aunque podría haber herramientas para ayudar con eso en el futuro, esto técnicamente es una desventaja al comparar la capacidad de utilizar la API de Composición pura frente a las opciones. Y entonces, ya sabes, dije que era más amigable con TypeScript, bueno, entonces, nuevamente, de manera similar, en comparación con la API de Composición, no es tan amigable con TypeScript en el sentido de que puedes usar una sintaxis más limpia con la API de Composición pura, pero con la API de opciones u objeto, por otro lado, entonces tienes que hacer un poco más de ajustes para asegurarte de que escribas correctamente los tipos según el contexto. Y esto es una de esas cosas en las que, bueno, esto no es una solución perfecta cuando se trata de eso. Y entonces, nuevamente, es un enfoque híbrido. Esto se espera. Entonces, ¿cuál es el enfoque correcto? Bueno, creo que una de las cosas desafiantes cuando se trata de ingeniería es que muchas veces como desarrolladores estamos obsesionados con ser los más correctos o encontrar formas de demostrar que esto siempre será correcto. Pero en lugar de pensar en correcto en términos de corrección o alguna especie de superioridad objetiva, creo que es más importante cambiar el contexto de correcto y enfocarse en el hecho de que lo que realmente importa es elegir el enfoque correcto para tu equipo. En otras palabras, se trata más de ajuste que de alguna especie de habilidad de calificación objetiva de la que estamos hablando. Y aquí hay algunos aspectos a considerar al tomar la decisión entre los diversos enfoques. El primero de ellos es la base de código en la que estás trabajando, ¿verdad? Porque si estás migrando desde una existente que tiene Vue 2 y ya estás utilizando la API de opciones y la estás migrando a Vue 3, por ejemplo. Nuevamente, sabemos que las migraciones pueden ser costosas y aún se desean lanzar nuevas características. Entonces, en ese caso, porque el equipo ya está familiarizado con la API de opciones, en mi opinión personal, tiene más sentido mejorar progresivamente tus componentes con la API de Composición. E incluso si tu equipo está pensando en utilizar más la API de Composición, esto evita la necesidad de hacer que toda tu base de código sea pura API de Composición desde el principio, lo cual definitivamente puede ralentizar el desarrollo, especialmente cuando se trata de lanzar nuevas características y cosas así. Por otro lado, si estamos hablando de un nuevo proyecto, aquí es donde creo que las sutilezas son un poco diferentes. Creo que esto es algo que a menudo se pasa por alto, pero realmente importante considerar es quién está realmente contribuyendo al código, ¿verdad? ¿Cuál es la composición del equipo? Si tienes muchas personas que no están tan familiarizadas con JavaScript y tienes tal vez una o dos personas que están escribiendo principalmente el código base, y ellos vienen a ayudar con pequeñas partes y piezas, la API de opciones como metodología principal podría ser realmente buena para la mayoría de los componentes, porque aunque no lo creas, cuando pensamos en muchos componentes, es fácil siempre querer pensar que escalarán infinitamente, pero porque Vue te da la flexibilidad de elegir entre varias metodologías, dependiendo de cuál, no hay razón para decir que no puedes comenzar con opciones y luego, a medida que crezca en complejidad, puedes mejorarla con la API de Composición o eventualmente cambiarla según sea necesario. Y por lo tanto, al considerar tu equipo, esto puede ser realmente, realmente importante, porque, por ejemplo, si tienes un equipo que está muy, muy familiarizado con JavaScript y quieren la flexibilidad de tomar sus propias decisiones arquitectónicas, entonces sí, la API de Composición sería la mejor opción. Pero nuevamente, por eso es realmente importante la composición de tu equipo y cómo eso contribuye al mantenimiento y la iteración de tu base de código. Y un tercer aspecto, que en realidad es un factor importante, es si planeas o el equipo planea utilizar TypeScript de manera muy, muy intensiva, ¿verdad? Y creo que hay una diferencia entre usar TypeScript ligeramente para anotar algunos tipos ocasionalmente y los usuarios de TypeScript más avanzados que quieren hacer cosas más complejas

7. Considering Team Preferences and Shipping Products

Short description:

Cuando tu equipo prefiere en gran medida TypeScript, la API de Composición encaja naturalmente en cuanto a sintaxis y herramientas. Sin embargo, es importante considerar las preferencias de tu equipo. Al lanzar productos, a las personas les importa la funcionalidad y el rendimiento, no el enfoque específico utilizado. Vue te permite elegir lo que mejor funcione para tu equipo. Si a tu equipo no le gusta trabajar con una base de código en particular, vale la pena considerar enfoques alternativos.

con TypeScript. Y así, cuando sabes que tu equipo realmente quiere enfocarse en TypeScript, es donde diría que probablemente te inclinarás más hacia la API de Composición porque se ajustará de manera más natural en cuanto a sintaxis, tooling, y ese tipo de cosas. Dicho esto, el último aspecto que quiero que consideres, que en realidad es muy importante, es ¿qué prefiere tu equipo? Y esto, creo, es contraintuitivo para los ingenieros muchas veces porque, nuevamente, estamos tan obsesionados con encontrar la respuesta correcta y tememos que las personas nos juzguen por nuestra decisión o piensen que nuestra base de código es de alguna manera inferior. Pero la realidad es que cuando lanzas productos y las personas descargan aplicaciones, nadie está pensando en qué enfoque están utilizando. Solo quieren saber si funciona y si tiene buen rendimiento. Y así, Vue, una de las cosas que siempre me ha gustado de Vue es que te permite elegir lo que es mejor para tu equipo. Al igual que con TypeScript, si no quieres usar TypeScript, no hay problema. Aún puedes usar la API de Composición Pura. Puedes usar la API de Opciones, ¿verdad? Pero al final del día, si a tu equipo no le gusta trabajar con esa base de código o temen tener que hacer algo en ella, ese es el momento de pensar realmente si, incluso si no es objetivamente, incluso si el resto de la community dice lo contrario, yo argumentaría que no importa lo que piensen. Y así, el veredicto final, ¿qué está sucediendo exactamente? Bueno, probablemente no te sorprenda, pero en mi opinión, cada enfoque es válido. Hemos visto con Vue 2 a personas creando bases de código realmente grandes como Gitlab. Y sus aplicaciones son geniales, ¿verdad? Funcionan. Y así, lo importante aquí es recordar que, independientemente de lo que todos digan, si lo estás construyendo y funciona y te diviertes, eso es lo que realmente importa. Porque así es como lanzarás nuevas características, así es como iterarás. Y luego, no me malinterpretes, cuando te encuentres con problemas y digas: oh, ahora necesito hacer algo diferente, que las opciones realmente no proporcionan, y necesito la Composición. La API de Composición estará allí esperándote. No tienes que comenzar a utilizarla por completo para sentir que estás aprovechándola al máximo. Con eso, gracias a todos por escuchar mi charla hoy. Si quieres ponerte en contacto o tienes alguna otra pregunta, no dudes en contactarme. Aquí está mi sitio web, benkosen.io. Puedes encontrarme en Twitter, YouTube, Twitch, bajo el seudónimo de Benkosen. Así que ven a pasar el rato en el streaming en vivo o echa un vistazo a los videos. De cualquier manera, ha sido muy divertido. Así que, gracias a ti, Londres.

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.

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.
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.
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.
Vue.js London Live 2021Vue.js London Live 2021
72 min
A Different Vue into Web Performance
Workshop
Solving your front-end performance problems can be hard, but identifying where you have performance problems in the first place can be even harder. In this workshop, Abhijeet Prasad, software engineer at Sentry.io, dives deep into UX research, browser performance APIs, and developer tools to help show you the reasons why your Vue applications may be slow. He'll help answer questions like, "What does it mean to have a fast website?" and "How do I know if my performance problem is really a problem?". By walking through different example apps, you'll be able to learn how to use and leverage core web vitals, navigation-timing APIs, and distributed tracing to better understand your performance problems.