vue2.0 vs vue3.0
1.重构响应式系统,使用Proxy替换Object.defineProperty,使用Proxy优势:
(1)可直接监听数组类型的数据变化
(2)监听的目标为对象本身,不需要像Object.defineProperty一样遍历每个属性,有一定的性能提升
(3)可拦截apply、ownKeys、has等13种方法,而Object.defineProperty不行
(4)直接实现对象属性的新增/删除
2.新增Composition API,更好的逻辑复用和代码组织
3.重构 Virtual DOM
(1)模板编译时的优化,将一些静态节点编译成常量
(2)slot优化,将slot编译为lazy函数,将slot的渲染的决定权交给子组件
(3)模板中内联事件的提取并重用(原本每次渲染都重新生成内联函数)
4.代码结构调整,更便于Tree shaking,使得体积更小
5.使用Typescript替换Flow(使用ts重写)
语法糖介绍
vue3.0依然可以使用大部分vue2.0的语法
compositon-api提供了一下几个函数
reactive
watchEffect
computed
ref
toRefs
生命周期的hooks
为什么要新增Composition API,它能解决什么问题
先来从图中看看对比
Vue2.0中,随着功能的增加,组件变得越来越复杂,越来越难维护,而难以维护的根本原因是Vue的API设计迫使开发者使用watch,computed,methods选项组织代码,而不是实际的业务逻辑。
另外Vue2.0缺少一种较为简洁的低成本的机制来完成逻辑复用,虽然可以minxis完成逻辑复用,但是当mixin变多的时候,会使得难以找到对应的data、computed或者method来源于哪个mixin,使得类型推断难以进行。
所以Composition API的出现,主要是也是为了解决Option API带来的问题。
第一个是代码组织问题,Compostion API可以让开发者根据业务逻辑组织自己的代码,让代码具备更好的可读性和可扩展性,也就是说当下一个开发者接触这一段不是他自己写的代码时,他可以更好的利用代码的组织反推出实际的业务逻辑,或者根据业务逻辑更好的理解代码。
第二个是实现代码的逻辑提取与复用,当然mixin也可以实现逻辑提取与复用,但是像前面所说的,多个mixin作用在同一个组件时,很难看出property是来源于哪个mixin,来源不清楚,另外,多个mixin的property存在变量命名冲突的风险。而Composition API刚好解决了这两个问题。
先来一个小demo:
app.vue
<input type="text" v-model="state.val" @keyup.enter="addTodo">
<ul>
<li v-for="v in state.todos" :key="v.name">{{v.name}}</li>
</ul>
<div>
total:{{total}}
</div>
import useAdd from "./useAdd.js";
export default {
setup() {
let { state, total, addTodo } = useAdd();
return {
state,
total,
addTodo
};
}
};
useAdd.js
import { reactive, computed, watchEffect } from "vue";
export default function useAdd(){
let state = reactive({
todos: [
{
name: "吃"
},
{
name: "喝"
},
{
name: "玩"
}
],
val: ""
});
let total = computed(() => state.todos.length);
watchEffect(() => console.log(state.todos));
function addTodo() {
state.todos.push({
name: state.val
});
state.val = "";
}
return { state, total, addTodo };
}
从demo里能看到我们把独立的功能都抽离了出来,放在了一个函数里,避免了vue2.0为了实现一个功能反复上下窜跳的尴尬,即容易理解代码,也易于维护。
从import里可以看到类似于computed都需要按需引入,虽然从视觉上看着麻烦一点,但实际上实现了一个按需打包的功能,没有用到的就直接被tree shake给干掉,并且不会像vue2.0一样什么都挂在this上,导致一些莫名其妙的错误。