时间:2021-05-25
前言
vue-next 对virtual dom的patch更新做了一系列的优化,从编译时加入了 block 以减少 vdom 之间的对比次数,另外还有 hoisted 的操作减少了内存的开销。本文写给自己看,做个知识点记录,如有错误,还请不吝赐教。
VDOM
VDOM的概念简单来说就是用js对象来模拟真实DOM树。由于MV**的架构,真实DOM树应该随着数据(Vue2.x中的data)的改变而发生改变,这些改变可能是以下几个方面:
Vue框架要做的其实很单一:在用户改变数据时,正确更新DOM树,做法就是其核心的VDOM的patch和diff算法。
Vue2.x中的做法
在Vue2.x中,当数据改变后就要对所有的节点进行patch和diff操作。如以下DOM结构:
<div> <span class="header">I'm header</span> <ul> <li>第一个静态li</li> <li v-for="item in mutableItems" :key="item.key"> {{ item.desc }}</li> </ul></div>在第一次mount节点的时候会去生成真实的DOM,此后如果
mutableItems.push({ key: 'asdf', desc: 'a new li item'})预期的结果是页面出现新的一个li元素,内容就是 a new li item,Vue2.x中是通过patch时对 ul 元素对应的 vnode 的 children 来进行 diff 操作,具体操作在此不深究,但是该操作是需要比较所有的 li 对应的 vnode 的。
不足
正是由于2.x版本中的diff操作需要遍历所有元素,本例中包括了 span 和 第一个li元素,但是这两个元素是静态的,不需要被比较的,不论数据怎么变,静态元素都不会再更改了。vue-next在编译时对这种操作做了优化,即 Block。
Block
入上述模板,在vue-next中生成的渲染函数为:
const _Vue = Vueconst { createVNode: _createVNode } = _Vueconst _hoisted_1 = _createVNode("span", { class: "header" }, "I'm header", -1 )const _hoisted_2 = _createVNode("li", null, "第一个静态li", -1 )return function render(_ctx, _cache) { with (_ctx) { const { createVNode: _createVNode, renderList: _renderList, Fragment: _Fragment, openBlock: _openBlock, createBlock: _createBlock, toDisplayString: _toDisplayString } = _Vue return (_openBlock(), _createBlock(_Fragment, null, [ _hoisted_1, _createVNode("ul", null, [ _hoisted_2, (_openBlock(true), _createBlock(_Fragment, null, _renderList(state.mutableItems, (item) => { return (_openBlock(), _createBlock("li", { key: item.key }, _toDisplayString(item.desc), 1 )) }), 128 )) ]) ], 64 )) }}我们可以看到调用了 openBlock 和 createBlock 方法,这两个方法的代码实现也很简单:
const blockStack: (VNode[] | null)[] = []let currentBlock: VNode[] | null = nulllet shouldTrack = 1// openBlockexport function openBlock(disableTracking = false) { blockStack.push((currentBlock = disableTracking ? null : []))}export function createBlock( type: VNodeTypes | ClassComponent, props?: { [key: string]: any } | null, children?: any, patchFlag?: number, dynamicProps?: string[]): VNode { // avoid a block with patchFlag tracking itself shouldTrack-- const vnode = createVNode(type, props, children, patchFlag, dynamicProps) shouldTrack++ // save current block children on the block vnode vnode.dynamicChildren = currentBlock || EMPTY_ARR // close block blockStack.pop() currentBlock = blockStack[blockStack.length - 1] || null // a block is always going to be patched, so track it as a child of its // parent block if (currentBlock) { currentBlock.push(vnode) } return vnode}更加详细的注释还请看源代码中的注释,写的十分详尽,便于理解。这里面 openBlock 就是初始化一个块,createBlock 就是对当前编译的内容生成一个块,这里面的这一行代码:vnode.dynamicChildren = currentBlock || EMPTY_ARR 就是在收集动态的子节点,我们可以再看一下编译时运行的函数:
// createVNodefunction _createVNode( type: VNodeTypes | ClassComponent, props: (Data & VNodeProps) | null = null, children: unknown = null, patchFlag: number = 0, dynamicProps: string[] | null = null) { /** * 一系列代码 **/ // presence of a patch flag indicates this node needs patching on updates. // component nodes also should always be patched, because even if the // component doesn't need to update, it needs to persist the instance on to // the next vnode so that it can be properly unmounted later. if ( shouldTrack > 0 && currentBlock && // the EVENTS flag is only for hydration and if it is the only flag, the // vnode should not be considered dynamic due to handler caching. patchFlag !== PatchFlags.HYDRATE_EVENTS && (patchFlag > 0 || shapeFlag & ShapeFlags.SUSPENSE || shapeFlag & ShapeFlags.STATEFUL_COMPONENT || shapeFlag & ShapeFlags.FUNCTIONAL_COMPONENT) ) { currentBlock.push(vnode) }}上述函数是在模板编译成ast之后调用的生成VNode的函数,所以有patchFlag这个标志,如果是动态的节点,并且此时是开启了Block的话,就会将节点塞入Block中,这样 createBlock返回的 VNode 中就会有 dynamicChildren 了。
到此为止,通过本文中案例经过模板编译和render函数运行后并经过了优化以后生成了如下结构的vnode:
const result = { type: Symbol(Fragment), patchFlag: 64, children: [ { type: 'span', patchFlag: -1, ...}, { type: 'ul', patchFlag: 0, children: [ { type: 'li', patchFlag: -1, ...}, { type: Symbol(Fragment), children: [ { type: 'li', patchFlag: 1 ...}, { type: 'li', patchFlag: 1 ...} ] } ] } ], dynamicChildren: [ { type: Symbol(Fragment), patchFlag: 128, children: [ { type: 'li', patchFlag: 1 ...}, { type: 'li', patchFlag: 1 ...} ] } ]}以上的 result 不完整,但是我们暂时只关心这些属性。可以看见 result.children 的第一个元素是span,patchFlag=-1,且 result 有一个 dynamicChildren 数组,里面只包含了两个动态的 li,后续如果变动了数据,那么新的 vnode.dynamicChildren 会有第三个 li 元素。
patch
patch部分其实也没差多少,就是根据vnode的type执行不同的patch操作:
function patchElement(n1, n2) { let { dynamicChildren } = n2 // 一系列操作 if (dynamicChildren) { patchBlockChildren ( n1.dynamicChildren!, dynamicChildren, el, parentComponent, parentSuspense, areChildrenSVG ) } else if (!optimized) { // full diff patchChildren( n1, n2, el, null, parentComponent, parentSuspense, areChildrenSVG ) }}可以看见,如果有了 dynamicChildren 那么vue2.x版本中的diff操作就被替换成了 patchBlockChildren() 且参数只有 dynamicChildren,就是静态的不做diff操作了,而如果vue-next的patch中没有 dynamicChildren,则进行完整的diff操作,入注释写的 full diff 的后续代码。
结尾
本文没有深入讲解代码的实现层面,一是因为自己实力不济还在阅读源码当中,二是我个人认为阅读源码不可钻牛角尖,从大局入眼,再徐徐图之,先明白了各个部分的作用后带着思考去阅读源码能收获到的应该更多一些。
到此这篇关于详解Vue3中对VDOM的改进的文章就介绍到这了,更多相关Vue3 VDOM内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
前言vue-next是Vue3的源码仓库,Vue3采用lerna做package的划分,而响应式能力@vue/reactivity被划分到了单独的一个packa
Vue.js作者尤雨溪就Vue3支持IE11的计划提交了新提案。提案摘要:Vue3将不会支持IE11原定投入Vue3IE11支持的精力将投入给2.7,移植3.x
vue3修改link中标签默认icon,vue3初次使用的时候不好好阅读配置难免会遇到一些坑,本人在项目完结的时候打算把浏览器的导航小icon图标给替换了,可是
最近在重新看vue3的rfcs,发现一个细节,原话如下:propsthatstartwithonarehandledasv-onbindings,witheve
在10月05日凌晨Vue3的源代码正式发布了,来自官方的消息:目前的版本是Pre-Alpha,仓库地址:Vue-next,可以通过CompositionAPI了