使用 proxy 代替之前的 Object.defineProperty 的API,性能更加优异,也解决了之前vue在处理对象、数组上的缺陷;在diff算法上,使用了静态标记的方式,大大提升了Vue的执行效率。
在使用的层面,我们从options Api(options Api的写法,比如data、computed、watch、methods等等),变成了composition Api,慢慢的在实际的业务中,我们抛弃了原本的data、methods、computed那种隔离式的写法。compositon Api,它更加聚焦,它讲究的是相关业务的聚合性。
同时,在composition Api中,为了防止过于重的业务逻辑,它提供了一种关注点分离的方式,大大的提升了我们代码的可读性。Vue2的问题就是在于,聚合性不足,会导致代码越来越臃肿!setup的方式,能够让data、方法逻辑、依赖关系等聚合在一块,更方便维护。
完全良好的支持了TypeScript,类型校验也成为了以后Vue3进行大型项目开发的质量保障,同时这也是面向了趋势 -- 前端的未来就是TypeScript!
1、compositon Api
compositon Api的本质,体现在代码里面,也就是一个setup函数,在这个setup函数中,返回的数据,会用到该组件的模板中。return的这个对象,一定程度上,代表了之前vue2中的data属性。
import { defineComponent, ref } from 'vue';
export default defineComponent({
name: 'Gift',
setup() {
const counter = ref(0);
return {
counter
}
}
})
这时候,对于大多数初学者来说,可能存在的疑惑就是,那么我能不能定义options Api的写法,比如data、computed、watch、methods等等。
这里我需要明确的是,Vue3是完全兼容Vue2的这种options Api的写法,但是从理念上来说,更加推荐setup的方式,来写我们的组件。
原因如下:Vue3的存在,本身是为了解决Vue2的问题的,Vue2的问题就是在于,聚合性不足,会导致代码越来越臃肿!setup的方式,能够让data、方法逻辑、依赖关系等聚合在一块,更方便维护。
也就是说,以后我们