关于react.js:聊一聊-React-的key

咱们在写 React 组件时 [].map 会提醒咱们须要为组件增加一个 key。那么这个 key 有什么必要性呢？

当比照两棵树时，React 首先比拟两棵树的根节点。不同类型的根节点元素会有不同的状态

当根节点为不同类型的元素时，React 会卸载原有的树并且建设起新的树。举个例子，当一个元素从变成 <img>，从 <Article> 变成 <Comment>，或从 <Button> 变成 <div> 都会触发一个残缺的重建流程。

当卸载一棵树时，对应的 DOM 节点也会被销毁。当建设一棵新的树时，对应的 DOM 节点会被创立以及插入到 DOM 中。所有与之前的树相关联的 state 也会被销毁。根节点以下的组件也会被卸载，它们的状态会被销毁。
比方，当比对以下更变时：

<div>
  <Counter />
</div>

<span>
  <Counter />
</span>

React 会销毁 Counter 组件并且从新装载一个新的组件。

当比照两个雷同类型的元素时，React 会保留 DOM 节点，仅比对及更新有扭转的属性。比方：

<div className="before" title="stuff" />

<div className="after" title="stuff" />

通过比照这两个元素，React 晓得只须要批改 DOM 元素上的 className 属性。
在解决完以后节点之后，React 持续对子节点进行递归。

默认状况下，当递归 DOM 节点的子元素时，React 会同时遍历两个子元素的列表；当产生差别时，生成一个 mutation。

在子元素列表开端新增元素时，更新开销比拟小。比方：

<ul>
  <li>first</li>
  <li>second</li>
</ul>

<ul>
  <li>first</li>
  <li>second</li>
  <li>third</li>
</ul>

React 会先匹配两个 <li>first</li> 对应的树，而后匹配第二个元素 <li>second</li> 对应的树，最初插入第三个元素的 <li>third</li> 树。

如果只是简略的将新增元素插入到表头，那么更新开销会比拟大。比方：

<ul>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

<ul>
  <li>Connecticut</li>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

React 并不会意识到应该保留 <li>Duke</li> 和 <li>Villanova</li>，而是会重建每一个子元素。这种状况就会带来性能问题。

为了解决上述问题，React 引入了 key 属性。当子元素领有 key 时，React 应用 key 来匹配原有树上的子元素以及最新树上的子元素。以下示例在新增 key 之后，使得树的转换效率得以进步：

<ul>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

<ul>
  <li key="2014">Connecticut</li>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

key 不须要全局惟一，但在列表中须要放弃惟一。

尽量避免应用数组中的下标作为 key，当基于下标的组件进行从新排序时，组件 state 可能会遇到一些问题。因为组件实例是基于它们的 key 来决定是否更新以及复用，如果 key 是一个下标，那么批改程序时会批改以后的 key，导致非受控组件的 state（比方输入框）可能互相篡改，会呈现无奈预期的变动。

React 能够在每个 action 之后对整个利用进行从新渲染，从新渲染示意在所有组件内调用 render 办法，然而这不代表 React 会卸载或装载它们。React 只会基于以上提到的规定来决定如何进行差别的合并。

所以，综上所述

Key 应该具备稳固，可预测，以及列表内惟一的特质。不稳固的 key（比方通过 Math.random() 生成的）会导致许多组件实例和 DOM 节点被不必要地从新创立，这可能导致性能降落和子组件中的状态失落。

React Diffing 算法

1、比照不同类型的元素

2、比照同一类型的元素

Keys