这次的题目看上去好像有点奇怪：把两个没有什么关联的名词放在了一起，正如大家所知道的，transition-group就是Vue的内置组件之一主要用在列表的动画上，但是会跟Virtual Dom Diff算法有什么特别的联系吗？答案明显是有的，所以接下来就是代码分解。
缘起
主要是最近对Vue的Virtual Dom Diff算法有点模糊了，然后顺手就打开了电脑准备温故知新；但是很快就留意到代码：
// removeOnly is a special flag used only by <transition-group> // to ensure removed elements stay in correct relative positions // during leaving transitions const canMove = !removeOnly
removeOnly是什么鬼，怎么感觉以前对这个变量没啥印象的样子，再看注释：removeOnly只用在transition-group组件上，目的是为了保证移除的元素在离开的动画过程中能够保持正确的相对位置（请原谅我的渣渣翻译）；好吧，是我当时阅读源码的时候忽略了一些细节。但是这里引起我极大的好奇心，为了transition-group组件竟然要在Diff算法动手脚，这个组件有什么必要性一定要这么做尼。
深入
首先假如没有这个removeOnly的干扰，也就是canMove为true的时候，正常的Diff算法会是怎样的流程：
while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) { if (isUndef(oldStartVnode)) { oldStartVnode = oldCh[++oldStartIdx] // Vnode has been moved left } else if (isUndef(oldEndVnode)) { oldEndVnode = oldCh[--oldEndIdx] } else if (sameVnode(oldStartVnode, newStartVnode)) { patchVnode(oldStartVnode, newStartVnode, insertedVnodeQueue, newCh, newStartIdx) oldStartVnode = oldCh[++oldStartIdx] newStartVnode = newCh[++newStartIdx] } else if (sameVnode(oldEndVnode, newEndVnode)) { patchVnode(oldEndVnode, newEndVnode, insertedVnodeQueue, newCh, newEndIdx) oldEndVnode = oldCh[--oldEndIdx] newEndVnode = newCh[--newEndIdx] } else if (sameVnode(oldStartVnode, newEndVnode)) { // Vnode moved right patchVnode(oldStartVnode, newEndVnode, insertedVnodeQueue, newCh, newEndIdx) canMove && nodeOps.insertBefore(parentElm, oldStartVnode.elm, nodeOps.nextSibling(oldEndVnode.elm)) oldStartVnode = oldCh[++oldStartIdx] newEndVnode = newCh[--newEndIdx] } else if (sameVnode(oldEndVnode, newStartVnode)) { // Vnode moved left patchVnode(oldEndVnode, newStartVnode, insertedVnodeQueue, newCh, newStartIdx) canMove && nodeOps.insertBefore(parentElm, oldEndVnode.elm, oldStartVnode.elm) oldEndVnode = oldCh[--oldEndIdx] newStartVnode = newCh[++newStartIdx] } else { if (isUndef(oldKeyToIdx)) oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx) idxInOld = isDef(newStartVnode.key) ? oldKeyToIdx[newStartVnode.key] : findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx) if (isUndef(idxInOld)) { // New element createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx) } else { vnodeToMove = oldCh[idxInOld] if (sameVnode(vnodeToMove, newStartVnode)) { patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue, newCh, newStartIdx) oldCh[idxInOld] = undefined canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm) } else { // same key but different element. treat as new element createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx) } } newStartVnode = newCh[++newStartIdx] } }
首先会是oldStartVnode跟newStartVnode做对比，当然如果它们类型一致就会进入patch流程；
接着又尝试oldEndVnode与newEndVnode做对比，继续跳过；
明显前面两个判断都没有canMove的身影，因为这里patch后是不用移动元素的，都是头跟头，尾跟尾，但是后面就不一样了；再继续oldStartVnode与newEndVnode对比，canMove开始出现了，这里旧的头节点从头部移动到尾部了，进行patch后，oldStartElem也需要移动到oldEndElem后面;
同样的如果跳过上一个判断，继续oldEndVnode与newStartVnode做对比，也会发生同样的移动，只是这次是把oldEndElm移动到oldStartElm前面去；
如果再跳过上面的判断，就需要在旧的Vnode节点上建立一个oldKeyToIdx的map了（很明显并不是所有的Vnode都会有key，所以这个map上并不一定有所有旧Vnode，甚至很有可能是空的），然后如果newStartVnode上定义了key的话在个map里面尝试去找出对应的oldVnode位置（当然不存在的话，就可以理所当然的认为这是新的元素了）；又如果newStartVnode没有定义key，它就会暴力去遍历所有的旧Vnode节点看看能否找出一个类型一致的可以进行patch的VNode；说明定义key还是很重要的，现在Vue的模板上都会要求for循环列表的时候要定义key，可以想象如果我们直接使用下标作为key的话会怎样尼；根据sameVnode方法：