React文档（二十一）协调

React提供了一个声明式地API因此你不用担心每一次更新什么东西改变了。这使得开发应用变得简单，但是这个东西在React中如何实现的并不是很明显。这篇文章会解释我们在React的算法中所做的选择以便组件的更新是可预测的当为了高性能的app而变得速度足够快。

目的

当你使用React，在一个单独的时间点你可以考虑render()函数会创建一棵React元素的树。当下一次state或者props更新了，render()函数将会返回一个不同的树。React随后需要解决怎样有效率地更新UI去匹配最新的树。

对于这个最小化转变一个树到另一个树的操作的算法问题，这里有一些通用的解决办法。然而，树中元素个数为n，最先进的算法 的时间复杂度为O(n^3) 。

如果我们在React里使用这个算法，显示1000个元素将会要求按次序发生十亿次比较。这样的比较的花费太高昂了。React实现了一个探索式的O(n)算法基于两种假设：

1. 两个元素类型不同会造成不同的树
2. 借助一个key属性，开发者可以暗示哪一个子元素在不同的渲染的时候会稳定不变

实际上，这些假设几乎对所有实际使用场景都是有效的。

对比算法

当比较两棵树的时候，React首先比较两个根元素。根据根元素的type不同比较的行为也不同。

不同类型的元素

无论何时根元素如果有不同的类型，React会销毁旧的树然后从草稿中创建新的树。从<a>变成<img>，或者从<Article>变成<Comment>，或者从<Button>变成<div>，任何这样的改变都会使得整个树重建。

当销毁一个树的时候，旧的DOM节点就被销毁了。组件实例调用componentWillUnmount()方法。当创建了一个新的树，新的DOM节点被插入已有的DOM。组件实例依次调用componentWillMount()方法和之后的componentDidMount()方法。任何旧的树的state都会丢失。

任何根元素之下的组件也会被销毁并且state也丢失。举个例子，当比较不同的时候：

<div>
  <Counter />
</div>

<span>
  <Counter />
</span>

这样会销毁旧的Counter然后重新建立一个新的。

相同类型的DOM元素

当比较两个相同类型的React DOM元素的时候，React会观察它们的属性，保留相同的DOM节点，只更新改变了的属性。举个例子：

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

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

通过比较这两个元素，React知道只去修改className属性。

当更新style的时候，React也知道只去更新改变了的属性。举个例子：

<div style={{color: 'red', fontWeight: 'bold'}} />

<div style={{color: 'green', fontWeight: 'bold'}} />

当改变发生在这两个元素之间，React知道只去修改color样式，而不修改fontWeight。

在处理DOM节点之后，React之后会在子元素上递归计算。

相同类型的组件元素

当一个组件更新的时候，实例保持一样，以便渲染的时候state被维持。React更新底层组件实例的props去产生新元素，并且在底层实例上调用componentWillReceiveProps()和componentWillUpdate()。

接下来，render()方法被调用并且diff算法在之前的结果和新结果上递归处理。

子节点的递归

默认情况，当在DOM节点的子节点上递归时，React仅在同一时间点递归两个子节点列表，并在有不同时产生一个变更。

举个例子，当在子元素的结尾添加一个元素的时候，两个树之间的转变：

<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>子树不变。这样的低效率会成为一个问题。

key属性

为了解决这个问题，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>

现在React知道了拥有2014key的元素是新元素，而拥有2015和2016的元素只是需要移动一下位置。

事实上，找到一个key通常不麻烦。你将要去显示的元素也许已经有了一个唯一的ID，因此key属性也可以使用你的数据：

<li key={item.id}>{item.name}</li>

如果不是这种情况，你可以添加新的ID属性到你的模型或者哈希一些内容来生成一个key。这个key对于兄弟元素必须唯一，但是不需要全局唯一。

万不得已，你可以传递它们在数组里的索引作为一个key。如果数组不会重新排序那么这样也会起作用，但是如果重新排序程序也会变慢。

当索引用作key时，组件状态在重新排序时也会有问题。组件实例基于key进行更新和重用。如果key是索引，则item的顺序变化会改变key值。这将导致受控组件的状态可能会以意想不到的方式混淆和更新。

这里是在CodePen上使用索引作为键可能导致的问题的一个例子，这里是同一个例子的更新版本，展示了如何不使用索引作为键将解决这些reordering, sorting, 和 prepending的问题。

权衡

牢记协调算法的实现细节非常重要。React可能在每一次动作的时候会渲染整个app；最终的结果会是一样的。我们要定期地提炼这些启发式算法为了让相同的使用场景性能更好。

在如今的实现里，你可以表示这个事实，一个子树在它的兄弟节点之中移动，但是你不能告知它移动到哪里。算法将会渲染整个子树。

因为React依赖于启发式算法，如果在它们背后的设想没有被满足，那么性能会受损。

1. 这个算法不会去试图匹配组件类型不同的子树。如果你看到交替的两种组件类型有着相似的输出，你也许想要使它们的类型一样。事实上，我们还没有发现这样会出现问题。
2. key属性必须稳定，可预测还有唯一。不稳定的key（就像那些通过Math.random()生成的随机数）将会造成许多组件实例和DOM节点不必要的重复创建，这样就会使性能变差并且在子组件中丢失state。