Composition Api与Options Api
Options Api存在的问题
- 代码逻辑散落在各个选项中,代码可读性随着项目增大而变差
- 不好复用,mixins命名冲突、数据来源不清
- ts支持不好
Composition Api
- 将某个逻辑关注点相关的代码全都放在一 个函数里,高内聚
- 因为 Composition API 几乎是函数,会有更好的类型推断。
- Composition API 对 tree-shaking 友好,代码也更容易压缩
- Composition API 中见不到 this 的使用,减少了 this 指向不明的情况
- 如果是小型组件,可以继续使用 Options API,也是十分友好的
tree shaking
- vue2为单例的,全局api通过vue实例访问,无法区分哪些被使用到,哪些没有,也没法在打包中砍掉未使用的代码
- vue3将全局api拆分,import使用,tree shaking利用esmodule特性,编译阶段可判断已使用模块,未使用模块不再打包
proxy api 代替 defineProperty
defineProperty问题
- 检测不到对象属性的新增和删除,要额外处理
- 数组 API 方法无法监听到,要额外处理
- 需要对每个属性进行遍历监听,如果嵌套对象,需要深层监听,造成性能问题 proxy
- 代理多达13种方法
- 深度响应处理仅在被访问时进行,避免不必要的深度遍历
vue3性能提升
- 编译阶段
- diff算法优化:标记为静态节点的标签不进行diff比较
- 静态提升:静态节点不进行diff比较,且只被创建一次,渲染时直接复用
- 事件监听缓存:
- ssr优化:静态内容大到一定量级,直接在客户端生成static node ,innerHTML
- 源码体积
- 移除不常用api,采用tree shaking,体积减小
- 响应系统
- proxy 监听属性增加、删除
- 监听数组索引和length
- 避免不必要的深度遍历