React/Vue里的key到底有什么用?看完这篇你就知道了!(附demo代码)
大唐西域都护 人气:0网上有很多博客讲到,React、Vue里的key,与 Virtual DOM 及 DOM diff 有关, 可以用来唯一标识DOM节点,提高diff效率,云云。
这大致是对的,但是,大多讲得语焉不详,像是在背答案。
具体怎么个提效法?为什么说用数组下标当作key是“反模式”?讲了一堆,能不能来个眼见为实,show me the code?
本文以React为例,尝试稍微刨一刨,但又不刨到太底层,以足够帮助理解为度。
1. VNode diff
首先介绍 Virtual DOM 结点(后续简称Virtual Node, VNode)是如何创建出来的。
现实中的React项目几乎都会用到JSX,而JSX不能直接执行,需要先经babel编译成js代码,比如:
<div className="content">Hello world!</div>
会被编译成
React.createElement("div", { className: "content" }, "Hello world!");
(点击这里查看在线编译)
所以,只要调用 React.createElement 这个静态方法,就可以创建出一个VNode。
无需深入VNode 的具体数据结构,只要看看这个工厂方法的参数,就可以知道 DOM diff 到底 diff 了哪些内容。
根据React官方文档,该方法可以接收≥3个参数:
- 第一个参数是type,指定结点类型,如果是HTML原生结点,那么会是一个字符串,比如"div";如果是React组件,那么就会是一个class或function;
- 第二个参数是props,是一个对象或者null。比如前面的例子中,div标签上的"className"属性就被加到这里来了;
- 第三(及第四,第五,……)个参数是childNode,该结点的子节点。前面的例子中,div的子节点是一个内容为"Hello world!"的TextNode
是滴,DOM diff 具体diff 的东西,就是这几个参数。为什么不会有别的?因为那样不符合React的设计理念:Data => UI 单向映射。
2. 动态列表的diff困局
我们知道React在调用setState触发render时,会对新旧 Virtual DOM 做比较,力争以最小的代价完成新DOM渲染任务。
结合上面提到的几个参数,具体比较过程大致是这样的:
- 首先比较type。如果type不同,那没什么好说的,直接销毁重新create一个;如果type相同,再往后看:
- 其次比较props,如果有变化,那就把变化的部分update;如果没变化,那就再往后看:
- 最后比较子节点,同样地,有变化就update,没变化就啥都不做
这在DOM结构固定的一般情况下是很好用的,但当我们希望从一个list映射出列表、而且这个list里的项随时可能变化时,就有点麻烦了。
比如说,原本list是这样的:
[ {name: 'Smith', job: 'Engineer'}, {name: 'Alice', job: 'HR'}, {name: 'Jenny', job: 'Designer'} ]
然后,Jenny被移到了最前面,那么Smith和Alice就相应后移了,变成了
[ {name: 'Jenny', job: 'Designer'}, {name: 'Smith', job: 'Engineer'}, {name: 'Alice', job: 'HR'} ]
对于React来说,如果它不知道这三个结点“本来”是谁,只是按照位置对应关系逐个去检查,会发现每个结点都变了:
- Smith => Jenny
- Alice => Smith
- Jenny => Alice
于是React得出结论:列表中的所有结点,全都需要update,重新渲染!
且慢!有没有更好的方法?
3. 借助key破局
如果,React“知道”这三个结点“本来”是谁,那么事情就会简单很多:
不需要更新任何DOM结点,只需把Jenny对应的结点摘下来,再插入到新的位置,完事。
但React怎么会知道谁是谁呢?
这需要我们开发者手动告诉它,于是key出场了。
在做DOM diff 时,如果同一个父组件下的两个VNode拥有同样的key,就会被视为同一个结点,如果React据此判断出,这个结点在列表中的排位发生了变化,就会像上面说的那样,进行“摘下-插入”处理。
为了证明这一点,亮代码!
首先上一个故意整出bug的版本:
class App extends React.Component { state = { list: [0, 1, 2] } add() { const list = this.state.list; this.setState({ list: [list.length, ...list] }); } render() { return ( <div className="App"> <button onClick={() => this.add()}>Input sth below, then click me</button> <ul> {
// 注意:这里故意用index作为key,引发bug this.state.list.map((item, index) => ( <li key={index}> <span>Item-{item}</span> <input type="text" /> </li> ) ) } </ul> </div> ); } }
ReactDOM.render(
<App />,
document.getElementById('root')
);
可以用 create-react-app起个项目,在本地试试这段代码。演示效果如下,先在第二行文本框里输入一些1:
然后,点击上面的按钮,会发现……
输入了一串1的文本框没有跟着Item-1走,而是留在了“原位”!
这就是用数组下标作key引发的典型bug。原因就在于新列表里Item-0和原列表里的Item-1拥有同样的key,被React视为同一个结点,所以只是“就地”更新了子节点(文本),并没有挪动结点的位置。
而这个bug的巧妙之处就在于使用了<input>,它可以在VNode的type、props、children均无变化的前提下,被用户行为改变其样式(输入的内容),从而让我们直观地看到结点所处位置。感谢React官方提供了这个巧妙的case。
好,下面我们来修复这个bug。
修复方法很简单:把 key={index} 改成 key={item} 就行了。
保存,刷新重试,我们就可以得到:
这下,对应关系正确了,React正确地识别出了3个旧结点,直接把新结点插入到列表开头,而旧结点没有变化。
全文结束。看到这里,你应该明白key到底有什么用,以及为什么index不宜做key了吧!
加载全部内容