¿Cuál es la diferencia entre la API de composición y la API de opciones? ¿Cual es mejor? ¿Por qué elegí utilizar la API combinada de vue3 en lugar de la API opcional?

Prefacio

Es 2023, han pasado varios años desde que nació vue3, pero todavía hay muchos proyectos basados ​​​​en vue2, pero la tendencia de vue3 es inevitable. La mayoría de las personas
aprenden de vue2, luego usan vue3 y están expuestas a la API combinada. Pero las personas que no entienden la API combinada pensarán a primera vista: "Qué diablos, es un desastre, la opción API es tan buena, las variables del método están claramente divididas", pero para la mayoría de la gente: "Ya que todos lo está usando, haré lo mismo”.

Pero cuando vas a ayudar a tu colega que no conoce Vue3 Composition Api, o a un novato que acaba de aprender Vue,
la otra parte te preguntará una tortura para el alma: "¿Por qué usar esto? Es tan problemático y complicado".

​ Este artículo explica las diferencias y beneficios de las dos API de forma comparativa.

¿Qué es la composición API?

Echa un vistazo a la documentación oficial.

La API de composición es una colección de API que nos permiten escribir componentes de Vue usando funciones en lugar de declarar opciones. Es un término general que cubre API para:

• API reactivas : como ref()y reactive(), nos permiten crear estados reactivos, propiedades calculadas y oyentes directamente.
• Ganchos del ciclo de vida : como onMounted()y onUnmounted(), nos permiten agregar lógica en varias etapas del ciclo de vida del componente.
• Inyección de dependencia : por ejemplo , provide()nos inject()permite aprovechar el sistema de inyección de dependencia de Vue cuando utilizamos API reactivas.

Echemos un vistazo a la imagen oficial y la descripción.

En pocas palabras: "El código no se divide según datos, métodos, cálculos, etc., sino según la lógica. En el pasado, encontrar la lógica relevante de esta función requería varios cambios y desplazamientos. Lo busqué y lo usé. Después de la API combinada, mi madre ya no teme que no pueda encontrar el código lógico relevante y puede mover este código a otros archivos sin tener que reorganizar el código, lo que reduce en gran medida el costo de reconstrucción y mejora en gran medida la legibilidad de el código."

Por supuesto, si no comprende por qué la API combinada está diseñada de esta manera, puede escribir cada vez más confuso y eventualmente convertirse en una montaña de mierda. En este momento, la diferencia entre las dos API es una montaña de mierda. que esta dividido en categorías y otro que no.Montaña de mierda clasificada

Mejor organización lógica y reutilización

​ En options Api, los mixins se usan básicamente para hacer un mix-in para lograr una reutilización lógica, options apiademás de varias inyecciones de mixin, y luego, inexplicablemente, ajustan un método this.xxxx(). Ni siquiera sabes dónde o qué archivo define este método. . Pero si usamos ganchos para reemplazar mixin y agregamos mecanografiado, será muy fácil rastrear la fuente de datos. Aquí se recomienda otra biblioteca de ganchos, [vueuses]: https://vueuse.org/ Por supuesto, puedes escribirla según sus propias necesidades. ganchos para lograr el propósito de la reutilización lógica.
Por ejemplo, uno de mis artículos anteriores: la carga móvil bajo desplazamiento se usa con ganchos. La
documentación oficial dice: Los usuarios de Vue 2 pueden estar familiarizados con la opción mixins . También nos permite extraer la lógica de los componentes en unidades reutilizables. Sin embargo, los mixins tienen tres desventajas principales:

1. Fuentes de datos poco claras : cuando se utilizan varios mixins, no queda claro de qué mixin provienen los atributos de datos de la instancia, lo que dificulta rastrear la implementación y comprender el comportamiento del componente. Esta es también la razón por la que recomendamos usar el patrón de desestructuración ref + en funciones compuestas: para aclarar la fuente de las propiedades de un vistazo al consumir el componente.
2. Conflicto de espacio de nombres : varios mixins de diferentes autores pueden registrar el mismo nombre de propiedad, lo que provoca conflictos de nombres. Si utiliza funciones compuestas, puede evitar nombres de clave idénticos cambiando el nombre de las variables al desestructurarlas.
3. Comunicación implícita entre mixins : varios mixins dependen de nombres de propiedades compartidos para interactuar, lo que los une implícitamente. El valor de retorno de una función combinada se puede pasar como parámetro de otra función combinada, como una función normal.

Por las razones anteriores, ya no recomendamos seguir usando mixins en Vue 3. Esta función se conserva únicamente para las necesidades de migración del proyecto y para atender a los usuarios que están familiarizados con ella.

Mejor inferencia de tipos

​Descripción oficial:

En los últimos años, cada vez más desarrolladores han comenzado a utilizar TypeScript para escribir código más robusto y confiable, y TypeScript también proporciona muy buen soporte de desarrollo IDE. Sin embargo, la API opcional se diseñó en 2013 y la derivación de tipos no se tuvo en cuenta en ese momento, por lo que tuvimos que hacer algunos ejercicios de tipos exageradamente complicados para lograr la deducción de tipos para la API opcional. Pero a pesar de todos estos esfuerzos, la inferencia de tipos de la API opcional todavía no es ideal cuando se trata de mixins y tipos de inyección de dependencia.

Por lo tanto, muchos desarrolladores que desean utilizar Vue con TS utilizan la vue-class-componentClass API proporcionada por . Sin embargo, la API basada en clases depende en gran medida de los decoradores de ES y cuando comenzamos a desarrollar Vue 3 en 2019, todavía era una característica del lenguaje de etapa 2. Creemos que el riesgo de diseñar la API central del marco basado en una propuesta de lenguaje inestable es demasiado grande, por lo que no hemos seguido desarrollándonos en la dirección de Class API. Después de eso, la propuesta del decorador sufrió muchos cambios y finalmente alcanzó la etapa 3 en 2022. Otro problema es que las API basadas en clases y las API basadas en opciones tienen las mismas limitaciones en la reutilización lógica y la organización del código.

Por el contrario, la API composicional utiliza principalmente variables y funciones básicas, que son inherentemente fáciles de escribir. El código reescrito con la API de composición puede disfrutar de una inferencia de tipos completa sin escribir demasiadas anotaciones de tipo. La mayoría de las veces, el código API componible escrito en TypeScript no es muy diferente del escrito en JavaScript. Esto también permite que muchos usuarios de JavaScript puro disfruten de algunas funciones de inferencia de tipos del IDE.

​ En pocas palabras: ¡el soporte de TS es muy, muy amigable! ! Hermanos! ! Los hermanos a quienes les gusta usar ts pueden usar directamente el método de escritura vue3 + tsx, que es más cómodo.

Tamaño de paquete de producción más pequeño

Composition ApiMás amigable para <script setup>la plantilla de componente escrita en el formulario se compila en una función en línea y <script setup>tiene el mismo alcance que el código en . A diferencia de la API opcional, que se basa en thisel objeto de contexto para acceder a las propiedades, las plantillas compiladas pueden acceder directamente a <script setup>las variables definidas en , sin la necesidad de realizar un proxy desde la instancia.

Compatibilidad con Tree-Sharking: elimine fácilmente las dependencias irrelevantes. Los montajes globales diversos tradicionales en archivos hacen que cada componente se hinche, incluso si no usa las cosas que monta Options Api. main.jsOriginalmente esto era un desastre, e inexplicablemente no sabía dónde estaba definido y montado algo en esto, así que tuve que buscarlo.

Conveniente para escribir

En las versiones posteriores a Vue3.2, se agregó azúcar en la sintaxis de configuración y
ya no es necesario declarar los componentes. Sin embargo, Options Apisi no es necesario declarar el componente, solo se puede montar en una
variable definida globalmente sin retorno, y allí No hay necesidad de preocuparse de que esto apunte al problema. Cuando se usa con reactivo, puede saber de un vistazo si es una variable o un método.

Resumir

Composition ApiResolver Options Apila mayoría de los puntos débiles del proyecto y escribir código altamente fácil de mantener siempre ha sido el objetivo de todos. Nadie quiere ser regañado por personas que mantendrán los proyectos que han escrito en el futuro, así que adoptémoslo juntos Composition Api.