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

¿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.

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,

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

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