Options API vs Composition API: Elegir el enfoque correcto para tu equipo

Rate this content
Bookmark

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

Ben Hong
Ben Hong
23 min
21 Oct, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy discute la Options API y la Composition API en Vue 3, destacando las diferencias y consideraciones al elegir un enfoque. La Composition API 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. Las preferencias del equipo y el nivel de uso de TypeScript deben considerarse al elegir el enfoque correcto para un proyecto.

Available in English

1. Introducción a Options API y Composition API

Short description:

Hoy estamos aquí para hablar tanto de Options API como de Composition API y cómo elegir el enfoque correcto para tu equipo. Soy ingeniero de experiencia de desarrollador en Netlify, en el equipo central de Vue, embajador de Nuxt, instructor de Vue mastery y experto en desarrollo de Google. Antes de Vue 3, las cosas eran más simples con la Options API. Con la Composition API de Vue 3, se complicó más. La Composition API utiliza el método Setup y proporciona una forma diferente de estructurar datos y métodos.

¿Qué pasa Vue Londres? ¿Cómo va todo? Estoy emocionado hoy porque estoy aquí para hablar de algo que, bueno, se ha discutido bastante dentro de la Vue comunidad, y esa es toda la idea de si usar o no Options API o Composition API. Así que hoy estamos aquí para hablar de ambos y cómo elegir el enfoque correcto para tu equipo. Para aquellos que no me conocen, mi nombre es Ben Hong y puedes encontrarme en Internet bajo el nombre de usuario BenCodeZen. Un poco sobre mí si no has encontrado mi trabajo antes. Soy ingeniero de experiencia de desarrollador en Netlify. Estoy en el equipo central de Vue dedicando la mayor parte de mi tiempo principalmente en documentos así como en actividades relacionadas con la comunidad y luego también soy embajador de Nuxt que de nuevo si no has oído, muy emocionado porque la beta pública de Nuxt ya está disponible, así que asegúrate de revisar eso. También soy instructor de Vue mastery y experto en desarrollo de Google en tecnologías web y matplatform. Bueno, para empezar, enfrentémoslo, antes de vue 3s las cosas eran bien más simples. ¿Más simples cómo? Bueno, porque solo había una forma de escribir nuestros componentes, en otras palabras, esto es lo que básicamente hemos llegado a conocer como la Options API. Y para asegurarnos de que todos estamos en la misma página, aquí tenemos un componente aquí que contiene tus cosas estándar de Options API. Así que lo que tienes aquí en la parte superior es un bloque de script y luego dentro de aquí estamos exportando un objeto predeterminado y luego tenemos cosas como tus datos, tus propiedades calculadas, así como los métodos que estás llamando dentro de esta plantilla que se encarga de renderizar esas cosas o llama a los métodos apropiados. Y por lo tanto, ya que tenemos estos lugares de opinión para donde pones tu código, es decir, datos, métodos calculados, esta era la Options API. Bueno, con la introducción de Vue 3 de la Composition API, bueno, se complicó un poco más porque ahora vamos a adelantar y solo, solo en caso de que la gente no sepa qué es la Composition API, hagamos una rápida revisión de la diferencia. Así que aquí en nuestra Options API tenemos formas muy opinadas de cómo ponemos nuestros datos. Bueno, lo primero que puedes decir cuando se trata de la Options API, o lo siento, lo primero que puedes decir cuando se trata de la Composition API es que estamos usando el método Setup. Así que moveremos todo hacia abajo, verás que esta configuración función dentro de nuestro objeto exportado. Y dentro de aquí lo que vamos a hacer, vamos a empezar a mover cosas para mostrarte cómo se ve en Composition API. Así que lo primero es tomaremos los datos, la propiedad de conteo de cero, y la moveremos hacia arriba y declararemos eso con un const de conteo cero. Y luego necesitaremos hacer eso reactivo para que Vue pueda rastrear eso. Así que vamos adelante e importa la ref que lo convierte en una referencia reactiva. Y envolvemos el valor cero en él. Y así ahora ese conteo es básicamente una referencia reactiva de cero. Y luego se convierte en calculado algo que podemos usar como un método de ayuda similar a ref. Así que lo importaremos aquí. Y luego lo que hace de manera similar es que declaramos una variable de doble conteo, y devuelve el valor de conteo la referencia reactiva veces dos. Así que actúa exactamente de la misma manera. Y finalmente, nuestros métodos aquí incrementan el conteo. De nuevo, como normal JavaScript aquí, const incrementa el conteo, es una función. ¿Y qué hace? Incrementa el valor de conteo más y más.

2. Introducción a Script Setup y Options API

Short description:

Ahora no entraremos en detalles y en cómo funciona ref y todas estas cosas. Pero aquí tienes una especie de alto nivel de una a una de lo que sucede cuando estas cosas se mueven a la Composition API. Y porque estamos en el método de configuración de tener todo exportado en este punto. Una pieza más que necesitamos tener es que necesitamos decirle explícitamente a Vue, básicamente lo que 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í devolvemos un objeto muy similar a la propiedad de datos. Para aquellos de ustedes que han estado siguiendo de cerca, bueno, Vue 3.2 lanzó otra forma de escribir componentes, aunque otra debería estar entre comillas, porque realmente es una especie de mejora en la experiencia del desarrollador en la Composition API, y eso es la nueva sintaxis de script setup. Así que hablemos de los tres enfoques diferentes que diría que generalmente la gente tiene que elegir cuando se trata de esto. El primero de los cuales es solo Options API. Es muy fácil de aprender y proporciona una sensación de consistencia entre los componentes. Sin embargo, también es opinado.

Ahora no entraremos en detalles y en cómo funciona ref y todas estas cosas. Pero aquí tienes una especie de alto nivel de una a una de lo que sucede cuando estas cosas se mueven a la composition API. Y porque estamos en el método de configuración de tener todo exportado en este punto. Una pieza más que necesitamos tener es que necesitamos decirle explícitamente a Vue, básicamente lo que 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í devolvemos un objeto muy similar a la propiedad data. Y para aquellos de ustedes que han estado siguiendo de cerca, bueno, Vue 3.2 lanzó otra forma de escribir componentes, aunque otra debería estar entre comillas, porque realmente es una especie de mejora en la experiencia del desarrollador en la composition API, y eso es la nueva sintaxis de script setup. Así que hagamos una revisión rápida sobre eso. Y así, de vuelta en nuestro ejemplo de contador, podemos ver aquí que tenemos el método composition API que básicamente mostramos la transición de antes que migramos desde las opciones. Vamos a mostrarles cómo se ve el script setup. Así que lo primero es que vamos a deshacernos del objeto de exportación, porque lo que realmente hace el script setup es que vamos a asumir que solo quieres usar composition API, así que no vamos a exportar un objeto. Y más importante aún, sabemos que vas a configurar métodos. Entonces, ¿por qué te hacen definir eso de nuevo? Así que lo que vamos a hacer es que vamos a mover ese método de configuración y moverlo como un atributo como un script de configuración. Específicamente, la configuración es un atributo de script, y luego como resultado, el compilador sabe hacer cosas especiales con el code dentro. Así que ahora que tenemos el script de configuración, aunque, también sabemos. Bueno, también podemos hacer algún tipo de detección automática de lo que probablemente quieras exponer al componente. Así que en realidad lo que podemos hacer también es que podemos eliminar la exposición manual de variables, lo cual es bastante agradable. Y así obtienes este code que es bastante limpio, fácil de entender. Y luego aquí como resultado, tienes una pura composition API usando el script de configuración. Básicamente, la mejora de la experiencia del desarrollador. Por supuesto, algunos de ustedes probablemente se preguntan de nuevo, porque la pregunta que todos siguen queriendo hacer es, bueno, ¿cuál es el correcto? Así que hablemos de los tres enfoques diferentes que diría que generalmente la gente tiene que elegir cuando se trata de esto. Y el primero de los cuales, como puedes imaginar, es solo Options API. Así que en otras palabras, solo para reiterar, lo que tenemos aquí es nuestro componente aquí con nuestras opciones explícitas, ¿verdad?, con data, métodos computados, y nos quedamos con la estructura y ni siquiera tratamos con composition API. Bueno, lo cierto es que cuando se trata de las opciones en API, hay un par de pros que quiero destacar, y el primero de los cuales 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 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 no había codificado durante años, pero básicamente en la primera hora de tomar una masterclass de Vue 101 donde estaban preocupados de que no iban a poder seguir porque sus habilidades en JavaScript realmente no estaban a la altura. En realidad pudieron entender muy rápidamente, y antes de que se dieran cuenta, estaban siguiendo y construyendo cosas, lo cual fue realmente emocionante para ellos, y se sintieron realmente empoderados por eso, y así es una de las cosas que siempre recuerdo a la gente que Options API es realmente genial en este sentido. Y luego, como hemos hablado, porque es extremadamente estructurado, obtienes una sensación de consistencia entre los componentes porque todos saben que los datos van en data, computados van en computados, y así sucesivamente. Y como resultado, obtienes una sensación de simplicidad, ¿verdad? Especialmente cuando se trata de cómo se escribe el code y porque sabes que cada vez que es predecible. Pero por otro lado, hay contras, ¿verdad? Cada decisión en tecnología tiene compensaciones. Eso es algo que siempre trato de recordar a la gente 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 parecer incómoda para el soporte de TypeScript.

y en primer lugar, es realmente opinada. Entonces, en otras palabras, si no quieres organizar tu code de esta manera, se vuelve bastante difícil básicamente sortear o hacer diferentes patterns, y esta es una de las razones por las que se introdujo la Composition API. 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 quizás no quieras. Tal vez quieras mantener tus métodos o data juntos de una manera que sea más modular, y esa flexibilidad se volvió un poco difícil de hacer en la API de Opciones. Y lo cierto es que con Vue 3, aunque muchas cosas ahora son mucho más amigables con TypeScript, entre aquellos que están aprendiendo TypeScript y realmente están metidos en ello, la API de Opciones puede parecer un poco incómoda cuando se trata del soporte de TypeScript porque estás haciendo cosas que son un poco diferentes a lo que podrías hacer cuando estás escribiendo normalmente un módulo cuando 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 quieras y arquitectarlo según tus preferencias. Este enfoque ofrece mucha flexibilidad, permitiendo que tus datos y cálculos se organicen de la manera que prefieras. Proporciona una 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.

para JavaScript y ese tipo de cosas. Ahora, el segundo enfoque, como podrías esperar, es un enfoque puro de la composition API. Entonces, en este sentido, vamos adelante, y como recordatorio, déjame mostrar el ejemplo de configuración de script code que podemos ver aquí, y esto es donde no hay más opciones. Todo es básicamente JavaScript puro. Puedes organizar tu code como quieras, y tienes la libertad de hacer y arquitectar 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 de ayuda, obtienes mucha flexibilidad porque ahora tus data pueden ir a donde quieran, tu computadora puede ir a donde quiera, como quieras organizarlo, y como resultado, obtienes esta sensación de solo JavaScript porque aunque, de nuevo, la razón por la que pongo esto entre comillas es porque muchas veces cuando se trata del code, la API de Objetos también es solo JavaScript, pero porque usa cosas como esta y hay algo de un poco más de abstracción en segundo plano en cuanto a conectar cosas automáticamente para ti, esto es donde la gente, creo, se pone un poco más nerviosa debido a este contexto que puede, bueno, es tradicionalmente 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. Tomar tanto la API de Opciones como la API de Composición juntas permite estructura y flexibilidad.

Entonces, como resultado, obtienes más esta sensación de, como, declaro una constante, hago una ref, lo organizo como quiero, y en este sentido, creo que se siente para la gente un poco más como solo JavaScript. Y debido a esta especie de sintaxis de mantenerlo justo como el normal JavaScript que escribes en modules, uno de los beneficios, el resultado es que la sintaxis de TypeScript y todo se integra mucho más limpio porque ahora no tienes esa abstracción en segundo plano sucediendo con este contexto y este tipo de cosas. Entonces, como resultado, muy, muy amigable con TypeScript. Por otro lado, una vez más, ninguna tecnología está sin sus compromisos. Curiosamente, porque tenemos flexibilidad, la flexibilidad en sí, argumentaría, es también un inconveniente en sí mismo. En otras palabras, es un poco una espada de doble filo. Después de todo, piénsalo, porque ahora ya no tienes esta estructura que la gente sigue consistentemente, hay más oportunidad para que crees anti-patrones y mucha de la responsabilidad ahora está en ti. Y esto significa que si cometes errores hasta en cuanto a la arquitectura, eso es para que lo descubras más tarde. O, por ejemplo, si alguien hace algo mal con la arquitectura y luego se pasa a otra persona, hay mucha más navegación que necesita suceder. Mientras que, por ejemplo, con la API de Opciones, todos sabían dónde estaba el code en todo momento. Además, esto es un poco una mezcla, pero diría, en comparación con las Opciones diría que tiene una barrera de entrada más alta porque la API de Composición viene con algunos de los requisitos previos de tener más familiaridad con JavaScript que la API de Opciones. Y mientras eso puede sonar un poco raro al principio, tenemos que entender que cuando se trata de la API de Opciones hay mucho que la gente puede asumir con los patrones, ¿verdad? Esta abstracción y el hecho de que siempre escribes las cosas de cierta manera permite a las personas que quizás no entiendan totalmente cómo funciona JavaScript hacer muchas cosas poderosas o incluso jugar o básicamente hacer cambios menores sin realmente saber mucho de JavaScript. Pero por otro lado, si tienes un fuerte conocimiento de JavaScript, de nuevo, es por eso que el otro lado de la moneda, algunas personas podrían encontrar la API de Composición más fácil porque de nuevo vienen con ese requisito previo de JavaScript. Entonces, están como, oh entiendo cómo importar métodos de ayuda, sé cómo exportar modules, todo esto tiene sentido. Mientras que con la API de Opciones está incorporado. Hay dos caras de la moneda, pero como resultado hay un poco más de barrera de entrada para aquellos que no están tan familiarizados con JavaScript. Y de nuevo, similar al primer punto sobre más flexibilidad, la falta de estructura puede ser un problema si los desarrolladores no están básicamente usando mejores prácticas cuando se trata de la arquitectura de sus aplicaciones y solo sepan que eso puede hacer un poco complicado a veces cuando se trata de escalar proyectos porque ahora realmente depende de tu habilidad para hacer cumplir esa consistencia en una gran base de code, en comparación con, una vez más, la API de Opciones, donde cada componente siempre se veía igual básicamente.

Ahora, el enfoque número tres aquí es el que creo que vale la pena mencionar, que es que puedes tomar tanto la API de Opciones como la API de Composición juntas. Y así aquí tenemos en este codebase, tenemos el componente para Opciones y API de Composición. Y lo que vemos aquí es la exportación predeterminada estándar. Y esta vez, todo nuestro Composición Las cosas de la API están definidas y configuradas. Y lo que es genial de esto es que básicamente todas estas cosas son ahora expuestas para la API de Opciones para luego, oh lo siento, la API de Opciones, para seguir adelante y luego ingerirlo. Entonces, lo que ves aquí ahora es que podemos construir sobre ello. Entonces, digamos que queríamos una propiedad como triple count, similar al double count, pero solo estamos devolviendo this.count veces tres. Bueno, porque todo se ha configurado en el método de configuración, ¿ves cómo funciona ese nombre? Luego, básicamente, permite que se exponga a la API de Opciones para que la use y luego como básicamente construir sobre ella. Y esto para mí es probablemente donde vamos a ver mucho de el, ¿cómo digo esto? Vale. Y lo que es realmente agradable de esto es que básicamente obtienes un poco de ambos mundos, lo mejor de tener algún tipo de estructura y consistencia mientras aún aprovechas lo que hace que la API de Composición sea realmente poderosa. Entonces, repasemos como antes los pros y contras de esto. Bueno, lo primero es que obtienes estructura con cierta flexibilidad. Así en otras palabras, tenemos esas opciones consistentes, pero al mismo tiempo, podemos inyectar el

6. Elegir el Enfoque Correcto

Short description:

Otra ventaja de usar 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, usar 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. Elegir el enfoque correcto 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, la estructura sigue ahí para nosotros. Otra ventaja de este enfoque es que puedes mejorar progresivamente el code. En otras palabras, especialmente si vienes de una base de code que ha existido durante un tiempo, ya utilizando opciones, por ejemplo, hay una forma de mejorar progresivamente tu code hay una forma de agregar progresivamente características de la composition API sin tener que refactorizar todo y reescribir todo tu code, que de nuevo, para mí, es uno de los puntos de venta más grandes 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 composition API con la API de Opciones, tienes más amigabilidad con typescript de la que tendrías si hubieras hecho pura API de Opciones. Así que es algo a considerar. Cuando se trata de contras, sin embargo, como podrías esperar, porque estás usando dos enfoques, esto significa que tienes que tener una mejor comprensión de básicamente ambas metodologías. Y esto es solo un contra en el sentido de que hay un poco más de curva de aprendizaje, porque eso significa que las personas que estaban muy cómodas con la API de Opciones ahora también tienen que conocer la composition API, y viceversa, aquellos que conocían la composition API también necesitarán conocer la API de Opciones. Pero de nuevo, 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 generalmente desde el principio. Y lo más importante, los principios que creo que impulsan la API detrás de ambas, la composición y las opciones, en cuanto a los hooks del ciclo de vida, las propiedades computadas, los datos reactivos son en su mayoría muy, muy similares. Así que, espero que aunque haya dos enfoques diferentes, hay similitudes y espero que la curva de aprendizaje no sea demasiado mala.

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 una herramienta, como básicamente tooling para ayudar con eso en el futuro, esto es técnicamente un contra cuando se trata de comparar la capacidad de ir puro composition API versus opciones. Y entonces, sabes cómo dije que era más amigable con TS, bueno, entonces, de nuevo, de manera similar, en comparación con la composition API no es tan amigable con TypeScript en el sentido de que puedes usar una sintaxis realmente limpia con la pura composition API pero con la API de Opciones u opciones API, por otro lado, entonces tienes que hacer un poco más de eso de afinar para asegurarte de que estás tipificando las cosas correctamente de acuerdo al contexto. Y entonces esto es una de esas cosas donde es, bueno, esto no es una solución perfecta cuando se trata de eso. Y de nuevo, es un enfoque híbrido. Esto es de esperarse. Entonces, ¿cuál enfoque es el 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 lo correcto en términos de corrección o alguna superioridad objetiva, creo que es más importante cambiar el contexto de lo correcto en lugar de centrarse en el hecho de que lo que realmente importa es elegir el enfoque correcto para tu equipo. En otras palabras, más sobre el ajuste y en lugar de algún tipo de escala 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 los cuales es la base de code con la que estás trabajando, ¿verdad? Porque si estás migrando de una existente que tiene Vue 2 y ya estás usando la API de Opciones y estás migrando a Vue 3, por ejemplo. De nuevo, sabemos que las migraciones pueden ser costosas y quieren seguir sacando nuevas características. Así que diría que 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 composition API. Y luego, incluso si tu equipo está pensando en hacer más composition API, esto evita la necesidad de hacer toda tu base de code pura composition API desde el principio, lo cual puede definitivamente ralentizar el desarrollo, especialmente cuando se trata de lanzar nuevas características y tal. Por otro lado, sin embargo, si estamos hablando de un nuevo proyecto, aquí es donde creo que las sutilezas entran un poco más diferente. Creo que esto es algo que a menudo se pasa por alto, pero realmente importante a considerar es quién está realmente contribuyendo a la base de code, ¿verdad? ¿Cómo está compuesto el equipo? Si tienes muchas personas que no están tan familiarizadas con JavaScript y tienes quizás una o dos personas que están escribiendo la base de code principalmente, con ellas entrando para ayudar con pequeños bits y piezas, la API de Opciones sirviendo como la metodología principal podría ser realmente un buen caso de uso para esto para la mayoría de los componentes, porque lo creas o no, cuando pensamos en muchos componentes, es fácil querer siempre pensar que se scale 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 empezar con opciones y luego, a medida que crece en complejidad, puedes mejorarlo con la composition API o eventualmente cambiarlo según lo vea conveniente. Y como resultado, cuando estás considerando tu equipo, esto puede ser realmente, realmente importante, porque, por ejemplo, si tienes un equipo que está realmente, realmente familiarizado con JavaScript, y quieren la flexibilidad de tomar sus propias decisiones arquitectónicas, entonces sí, la composition API todo el camino podría tener mucho sentido. Pero de nuevo, por eso realmente importa la composición de tu equipo y cómo básicamente eso contribuye al mantenimiento y la iteración de tu base de code. Y un tercer factor, que es en realidad bastante grande, es ¿planeas o el equipo planea usar TypeScript muy, muy intensamente, ¿verdad? Y creo que hay una diferencia entre usar TypeScript ligeramente para anotar algunos tipos de vez en cuando a algunos usuarios de TypeScript más pesados que quieren hacer cosas mucho más complejas

7. Considerando las Preferencias del Equipo y la Entrega de Productos

Short description:

Cuando tu equipo prefiere en gran medida TypeScript, la API de Composición encaja naturalmente en términos de sintaxis y herramientas. Sin embargo, es importante considerar la preferencia de tu equipo. Al entregar productos, a la gente le 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 determinada, vale la pena considerar enfoques alternativos.

con TypeScript. Y entonces, cuando sabes que tu equipo realmente quiere ir a fondo con TypeScript, aquí es donde diría que probablemente te inclinarás más hacia la API de Composición porque simplemente encajará de manera más natural en cuanto a sintaxis, herramientas, y ese tipo de cosas. Dicho esto, sin embargo, el último aspecto que quiero que consideres, que es realmente muy importante, es ¿qué prefiere tu equipo? Y esto, creo, es contraintuitivo para los ingenieros muchas veces porque, de nuevo, estamos tan atrapados en tratar de encontrar la respuesta correcta, y tenemos miedo de que la gente nos juzgue por nuestra decisión o piense que nuestra base de código es de alguna manera inferior. Pero la realidad es que cuando estás entregando productos y la gente está descargando aplicaciones, nadie está pensando como, oh, me pregunto qué enfoque usaron. Solo quieren saber ¿funciona? ¿Es eficiente? Y así, Vue, una de las cosas que siempre me ha encantado de Vue es que te permite elegir lo que es mejor para tu equipo. Al igual que TypeScript, si no quieres usar TypeScript, no es un gran problema. Todavía 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 les aterra entrar allí para hacer algo, ese es el momento de pensar realmente si incluso si no es objetivamente, incluso si el resto de la comunidad dice lo contrario, yo argumentaría que no importa lo que ellos piensen. Y entonces, el veredicto final, ¿verdad?, ¿qué está pasando exactamente? Bueno, probablemente no te sorprenda pero en mi opinión, cada enfoque es válido. Hemos visto con Vue 2 personas creando bases de código realmente grandes como Gitlab. Y sus aplicaciones son geniales, ¿verdad? Funcionan. Y entonces, lo principal aquí es recordar que independientemente de lo que todos digan, si lo estás construyendo y funciona y te diviertes, eso es realmente lo que importa. Porque así es como estarás entregando nuevas características, así es como estarás iterando. Y luego, no me malinterpretes, cuando te encuentras con problemas y estás como, oh, ahora necesito hacer algo diferente, que las opciones no proporcionan realmente, y necesito composición. La API de Composición estará allí esperándote sin importar. No tienes que empezar a ir all in en ella para básicamente sentir que estás sacándole el máximo provecho. Con eso, gracias a todos por escuchar mi charla hoy. Si quieres ponerte en contacto o tienes alguna otra pregunta, no dudes en comunicarte. Aquí está mi sitio web, benkosen.io. Puedes encontrarme bajo el... Básicamente, estoy en Twitter, YouTube, Twitch, bajo el seudónimo Benkosen. Así que, ven a pasar un rato en la transmisión 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

Everything Beyond State Management in Stores with Pinia
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.
Welcome to Nuxt 3
Vue.js London Live 2021Vue.js London Live 2021
29 min
Welcome to Nuxt 3
Top Content
Explain about NuxtJS codebase refactor and challenges facing to implement Vue 3, Vite and other packages.
One Year Into Vue 3
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!
Utilising Rust from Vue with WebAssembly
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: Feature Updates
Vue.js London 2023Vue.js London 2023
44 min
Vue: Feature Updates
Top Content
The creator of Vue js gives an update on the new features of the technology.
Local State and Server Cache: Finding a Balance
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

Vue3: Modern Frontend App Development
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
Mikhail Kuznetcov
Mikhail Kuznetcov
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
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
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
Daniel Roe
Daniel Roe
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.
TresJS create 3D experiences declaratively with Vue Components
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
Alvaro Saburido
Alvaro Saburido
- 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
Building Vue forms with VeeValidate
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
Abdelrahman Awad
Abdelrahman Awad
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.
Building full-stack GraphQL applications with Hasura and Vue 3
Vue.js London Live 2021Vue.js London Live 2021
115 min
Building full-stack GraphQL applications with Hasura and Vue 3
WorkshopFree
Gavin Ray
Gavin Ray
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.
A Different Vue into Web Performance
Vue.js London Live 2021Vue.js London Live 2021
72 min
A Different Vue into Web Performance
Workshop
Abhijeet Prasad
Abhijeet Prasad
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.