新特性总结
- 全局
API
和内置组件/功能支持tree-shaking
- 常驻代码大小控制在
10kb gzipped
上下 - 编译器架构重构,更多的编译时优化
- 添加TypeScript支持,使外部贡献者更有信心做改动
- 代码采用monorepo结构,内部分层更清晰
一、使Vue
更快(性能优化)
基于Proxy
的响应式实现,性能整体优于Object.defineProperty
长远来看,JS
引擎会继续优化Proxy
,但Object.defineProperty
(getter/setter
)基本不会再有针对性的优化
Virtual DOM 重构
2.x版本的VDOM更新
- Vue虽然能够保证触发组件更新的最小化,但在单个组件内部依然需要遍历该组件的整个VDOM树
- 但如果碰到下列只有少量动态节点时,这些遍历都是性能的浪费
- 因此:传统的VDOM的性能与模板带下正相关,与动态节点数目无关
3.x 动静分离优化,提示更新效率
React 解决方法: 时间分片
-
通过模板静态分享生成更优化的VDOM渲染函数
-
先将模板切分为block,每个block内部动态节点位置都是固定的
-
每个block的根节点会记录自己所包含的动态节点(包含子block的根节点)
-
更新时,只需要直接遍历动态节点
-
block Tree
-
最简单情况
-
v-if情况
-
优化效果
- 新策略将VDOM更新性能与模板大小解耦,变为与动态节点数目相关
- 整体性能提升2~5倍
二、Function-based API
单个函数内部的变量会被压缩,对压缩更友好
替换Class API
- class api(vue-property-derocator和vue-class-component) 对vue而已只是扩展了对TypeScript和与React类似的装饰器写法,其余并没有其他的优点,
- Derocator提案严重不稳定是的依赖他的方案具有很大风险
- Props和其他需要注入到this的属性导致类型声明存在很大问题
逻辑复用
- Mixin
- 混入的属性来源不清楚
- 命名空间冲突
- 高阶组件(HOC)
- Props来源不清楚
- Props命名空间冲突
- 多余的组件实例造成性能浪费
- Scoped Slots
- 来源清楚
- 无命名空间冲突
- 多余的组件造成性能浪费
- Composition Functions (Function-based API提供)
- 即函数组合
- 无额外实例开销
优点
- 更灵活的逻辑复用能力
- 更好的TypeScript类型推导支持
- 更好的性能
- Tree-shaking优化
- 基于函数的 API 每一个函数都可以作为 named ES export 被单独引入,这使得它们对 tree-shaking 非常友好。没有被使用的 API 的相关代码可以在最终打包时被移除
- 代码容易压缩
- 所有的函数名和 setup 函数体内部的变量名都可以被压缩,但对象和 class 的属性/方法名却不可以
使用Function-based API
官方提供了一个vue-function