Vue3设计目标和优化
vue3.0的设计目标是什么？做了哪些优化？
Vue3的设计目标：更小、更快、更友好、优化方案
一、设计目标
Vue3之前我们会面临的许多问题：
- 随着功能的增长，复杂组件的代码变得越来越难以维护起来
- 缺少一种比较【干净】的在多个组件提取和复用逻辑的机制
- 类型的推断不够友好
- bulid的时间比较长
Vue3的经历长达2-3年的筹备和研发，做了哪些事情？
我们从结果上面进行反推：
- 更小
- 更快
- Tyscript支持
- API设计一致性
- 提高自身可维护性
- 开发更多底层功能
总的来说就是更小更快更友好
更小
Vue3 移除一些不常用的 API，引入 tree-shaking，可以将无用的模块‘剪辑’ 仅打包需要的，使打包的整体体积变小了
更快
主要体现在编译方面
1- diff算法的优化
2-静态的提升
3-事件监听缓存
4-SSR优化
更友好
Vue3在兼顾Vue2的options API同时又推出了composition API，大大增加了代码逻辑组织和代码复用能力。
实例如下：
import { toRefs, reactive } from 'vue';
function useMouse(){
const state = reactive({x:0,y:0});
const update = e=>{
state.x = e.pageX;
state.y = e.pageY;
}
onMounted(()=>{
window.addEventListener('mousemove',update);
})
onUnmounted(()=>{
window.removeEventListener('mousemove',update);
})
return toRefs(state);
}
我们只需要调用这个函数，即可获取 x、y 的坐标，完全不用关注实现过程
试想一下，如果很多类似的第三方库，我们只需要调用即可，不必关注实现过程，
开发效率大大提高
同时，VUE3 是基于 typescipt 编写的，可以享受到自动的类型定义提示
二、优化方案
Vue3从很多层面都做了优化，可以分为三个方面：
1-源码
2-性能
3-语法API
1-源码
源码可以从两个层面展开：源码管理；Tyscript
源码管理：
首先，源码的优化体现在代码管理方式上。Vue.js 2.x 的源码托管在 src 目录，然后依据功能拆分出了 compiler（模板编译的相关代码）、core（与平台无关的通用运行时代码）、platforms（平台专有代码）、server（服务端渲染的相关代码）、sfc（.vue 单文件解析相关代码）、shared（共享工具代码） 等目录：
而到了 Vue.js 3.0 ，整个源码是通过 monorepo 的方式维护的，根据功能将不同的模块拆分到packages 目录下面不同的子目录中：
这样使得模块拆分更细化，职责划分更明确，模块之间的依赖关系也更加明确，开
发人员也更容易阅读、理解和更改所有模块源码，提高代码的可维护性
另外一些 package（比如 reactivity 响应式库）是可以独立于 Vue 使用的，这样
用户如果只想使用 Vue3 的响应式能力，可以单独依赖这个响应式库而不用去依赖
整个 Vue
TypeScript
Vue3 是基于 typeScript 编写的，提供了更好的类型检查，能支持复杂的类型推导
2-性能
vue3 是从什么哪些方面对性能进行进一步优化呢？
- 体积优化
- 编译优化
- 数据劫持优化
这里我们讲数据劫持
在vue2中，数据劫持是通过Object.defineProperty，这个API有一些缺陷，并不能检测对象属性的添加和删除
Object.defineProperty(data, 'a',{
get(){
// track
},
set(){
// trigger
}
})
尽管 Vue 为了解决这个问题提供了 set 和 delete 实例方法，但是对于用户来说，
还是增加了一定的心智负担
同时在面对嵌套层级比较深的情况下，就存在性能问题
default {
data: {
a: {
b: {
c: {
d: 1
}
}
}
}
}
相比之下，vue3 是通过 proxy 监听整个对象，那么对于删除还是监听当然也能监
听到
同时 Proxy 并不能监听到内部深层次的对象变化，而 Vue3 的处理方式是在 getter
中去递归响应式，这样的好处是真正访问到的内部对象才会变成响应式，而不是无
脑递归
3-语法 API
这里当然说的就是 composition API，其两大显著的优化
- 优化逻辑组织
- 优化逻辑复用
优化逻辑组织
一张图，我们可以很直观地感受到 Composition API 在逻辑组织方面的优势
相同功能的代码编写在一块，而不像 options API 那样，各个功能的代码混成一
块
逻辑复用
在 vue2 中，我们是通过 mixin 实现功能混合，如果多个 mixin 混合，会存在两个
非常明显的问题：命名冲突和数据来源不清晰
而通过 composition 这种形式，可以将一些复用的代码抽离出来作为一个函数，
只要的使用的地方直接进行调用即可
实例：
在 Vue.js 2.x 中，我们通常会用 mixins 去复用逻辑，举一个鼠标位置侦听的例子，我们会编写如下函数 mousePositionMixin：
const mousePositionMixin = {
data() {
return {
x: 0,
y: 0
}
},
mounted() {
window.addEventListener('mousemove', this.update)
},
destroyed() {
window.removeEventListener('mousemove', this.update)
},
methods: {
update(e) {
this.x = e.pageX
this.y = e.pageY
}
}
}
export default mousePositionMixin
然后在组件中使用：
<template>
<div>
Mouse position: x {{ x }} / y {{ y }}
</div>
</template>
<script>
import mousePositionMixin from './mouse'
export default {
mixins: [mousePositionMixin]
}
</script>
使用单个 mixin 似乎问题不大，但是当我们一个组件混入大量不同的 mixins 的时候，会存在两个非常明显的问题：命名冲突和数据来源不清晰。
首先每个 mixin 都可以定义自己的 props、data，它们之间是无感的，所以很容易定义相同的变量，导致命名冲突。另外对组件而言，如果模板中使用不在当前组件中定义的变量，那么就会不太容易知道这些变量在哪里定义的，这就是数据来源不清晰。但是Vue.js 3.0 设计的 Composition API，就很好地帮助我们解决了 mixins 的这两个问题。
我们来看一下在 Vue.js 3.0 中如何书写这个示例
import { ref, onMounted, onUnmounted } from 'vue'
export default function useMousePosition() {
const x = ref(0)
const y = ref(0)
const update = e => {
x.value = e.pageX
y.value = e.pageY
}
onMounted(() => {
window.addEventListener('mousemove', update)
})
onUnmounted(() => {
window.removeEventListener('mousemove', update)
})
return { x, y }
}
这里我们约定 useMousePosition 这个函数为 hook 函数，然后在组件中使用：
<template>
<div>
Mouse position: x {{ x }} / y {{ y }}
</div>
</template>
<script>
import useMousePosition from './mouse'
export default {
setup() {
const { x, y } = useMousePosition()
return { x, y }
}
}
</script>
可以看到，整个数据来源清晰了，即使去编写更多的 hook 函数，也不会出现命名冲突的问题。
Composition API 除了在逻辑复用方面有优势，也会有更好的类型支持，因为它们都是一些函数，在调用函数时，自然所有的类型就被推导出来了，不像 Options API 所有的东西使用 this。另外，Composition API 对 tree-shaking 友好，代码也更容易压缩。
虽然 Composition API 有诸多优势，它也不是一点缺点都没有，关于它的具体用法和设计原理，我们会在后续的章节详细说明。这里还需要说明的是，Composition API 属于 API 的增强，它并不是 Vue.js 3.0 组件开发的范式，如果你的组件足够简单，你还是可以使用 Options API。