Reflexiones basadas en una amplia práctica en proyectos Vue3 y TypeScript
En general, Vue3 ha logrado grandes avances tanto en los principios subyacentes como en el desarrollo empresarial real.
El uso de proxy en lugar de la API Object.defineProperty anterior brinda un mejor rendimiento y resuelve los defectos del vue anterior en el procesamiento de objetos y matrices en el algoritmo diff, el uso de etiquetas estáticas mejora enormemente la eficiencia de ejecución de Vue; .
En el nivel de uso, pasamos de la Api de opción a la Api de composición. Poco a poco, en el negocio real, abandonamos la forma original aislada de escribir datos, métodos y cálculos. Compuesto por API, está más enfocado, se trata de la agregación de negocios relacionados.
Es totalmente compatible con TypeScript y la verificación de tipos se ha convertido en una garantía de calidad para el futuro desarrollo de proyectos a gran escala de Vue3. Al mismo tiempo, esto también está orientado hacia la tendencia: ¡el futuro front-end es TypeScript! En esta función de configuración, los datos devueltos se utilizan en la plantilla del componente. El objeto devuelto representa los atributos de datos anteriores en vue2 hasta cierto punto.
En este punto, para la mayoría de los principiantes, es posible que tengan esta pregunta: ¿Cómo puedo definir las opciones escritas en Api, como datos, cálculos, observaciones, métodos, etc.?
Esto es lo que estoy tratando de hacer: estoy tratando de definir cómo se escriben las opciones de API.
Lo que debo señalar aquí es que Vue3 es totalmente compatible con la API de opciones de Vue2, pero conceptualmente es más recomendable utilizar el método de configuración al escribir nuestros componentes.
He aquí por qué: Vue3 existe para resolver el problema de Vue2, que es que la falta de agregación conduce a un código cada vez más inflado.
La configuración es una forma de agregar datos, lógica de métodos, dependencias, etc. en una sola pieza, lo que facilita su mantenimiento.
En otras palabras, en el futuro deberíamos intentar no escribir datos individuales, cálculos, observaciones, métodos, etc. Esto no quiere decir que Vue3 no lo admita, pero va en contra de la filosofía de Vue3.
Las propiedades de los componentes son subcomponentes de los componentes. No hay mucha diferencia entre ellos en Vue2 y Vue3. Los métodos de uso en Vue2 todavía son aplicables en Vue3.
En términos de funcionalidad, ¡tanto la referencia como la reactiva admiten datos receptivos!
A nivel gramatical existen diferencias entre ambos. La forma en que ref define los datos receptivos requiere el uso de [datos].valor para cambiar los datos; mientras que la forma reactiva define los datos requiere el uso del método [datos].[propiedad] para cambiar los datos.
Pero a nivel de aplicación, todavía existen diferencias entre los dos. La diferencia típica es: para un único tipo de datos común, usamos ref para definir reactivo. Los escenarios de aplicación del formulario que describen la clave: valor del formulario como objetos usan reactivo; en algunos escenarios de aplicación, un conjunto de datos del módulo generalmente usa reactivo para definir los datos.
Entonces, ¿es necesario utilizar reactivo para definir objetos? De hecho, no, ¡puede analizarlo en función de sus propios escenarios comerciales y problemas específicos! Ref enfatiza un cambio en el valor de los datos, mientras que reactivo enfatiza un cambio en un determinado atributo del objeto definido.
En Vue3, la función periódica se usa sola de la siguiente manera:
En Vue2, puedes obtenerla directamente a través de this.$store, pero en Vue3, no es así. en realidad no existe tal concepto, el uso es el siguiente:
En Vue2, es a través de this.$router. En Vue2, es a través de this.$router. Esta es la programación funcional del enrutamiento. pero en Vue3, se usa así:
comerciante.ts
Para ser precisos, esta parte es el contenido de TS, pero está estrechamente relacionado con el desarrollo de Vue3. proyecto, por lo que si realmente desea utilizar Vue3, debe comprender el uso de TS.
Pero en esta parte, no presentaré la sintaxis básica de TS, sino principalmente cómo organizar TS en escenarios comerciales.
En solicitudes de interfaz comunes, generalmente usamos TS, para que podamos definir solicitudes de datos, tipos de solicitudes de datos y tipos de solicitudes de datos res.