看文章后发现key便于理解的两段话,特此记录一下。
对实现列表的增删,若是给列表的每一项增长一个key,即惟一索引,那就能够很清楚的知道两个列表谁少了谁没变。而若是不加key的话,就只能一个个对比,而后进行操做。vue
见vue/patch.js,在不带key的状况下,判断sameVnode时由于a.key和b.key都是undefined,对于列表渲染来讲已经能够判断为相同节点而后调用patchVnode了,实际根本不会进入到答主给的else代码,也就无从谈起“带key比不带key时diff算法更高效”了。node
而后,官网推荐推荐的使用key,应该理解为“使用惟一id做为key”。由于index做为key,和不带key的效果是同样的。index做为key时,每一个列表项的index在变动先后也是同样的,都是直接判断为sameVnode而后复用。(这段话很重要)git
说到底,key的做用就是更新组件时判断两个节点是否相同。相同就复用,不相同就删除旧的建立新的。github
正是由于带惟一key时每次更新都不能找到可复用的节点,不但要销毁和建立vnode,在DOM里添加移除节点对性能的影响更大。因此会才说“不带key可能性能更好”。看下面这个实验,渲染10w列表项,带惟一key与不带key的时间对比:算法
不使用key的状况:dom
<li v-for="item in list">{{ item.text }}</li>
使用id做为key的状况:性能
<li v-for="item in list" :key="item.id">{{ n.text }}</li>
list构造:spa
const list1 = [] const list2 = [] for (let i = 0; i <= 100000; i++) { list1.push({ id: i, text: i }) list2.push({ id: i * 2, name: 100000 - i }) }
由于不带key时节点可以复用,省去了销毁/建立组件的开销,同时只须要修改DOM文本内容而不是移除/添加节点,这就是文档中所说的“刻意依赖默认行为以获取性能上的提高”。code
既然如此,为何还要建议带key呢?由于这种模式只适用于渲染简单的无状态组件。对于大多数场景来讲,列表组件都有本身的状态。blog
举个例子:一个新闻列表,可点击列表项来将其标记为"已访问",可经过tab切换“娱乐新闻”或是“社会新闻”。
不带key属性的状况下,在“娱乐新闻”下选中第二项而后切换到“社会新闻”,"社会新闻"里的第二项也会是被选中的状态,由于这里复用了组件,保留了以前的状态。要解决这个问题,能够为列表项带上新闻id做为惟一key,那么每次渲染列表时都会彻底替换全部组件,使其拥有正确状态。
这只是个简单的例子,实际应用会更复杂。带上惟一key虽然会增长开销,可是对于用户来讲基本感觉不到差距,并且能保证组件状态正确,这应该就是为何推荐使用惟一id做为key的缘由。至于具体怎么使用,就要根据实际状况来选择了。