React进阶笔记8(协调Reconciliation)

协调（Reconciliation）

React提供了一组声明式的API，让你不必关心每次更新的变化，这样使得应用的编写容易了很多。
但是在React中如何实现还并不太清晰，这篇文章解释了React对比算法的选择，让组件更新可预测并且使得高性能足够的快。

目的

当你使用React，在单一的时间点，你可以考虑render()函数作为创建React函数的树，React需要算出如何更新UI来匹配最新的树（dom）

有一个解决方案是：

将一棵树转换为另一棵树的最小操作数算法问题的通用方案。然而树种元素的个数为n，最先进的算法 的时间复杂度为O(n³) 。

如果我们在React中使用，展示1000个元素，则需要10亿次的比较，这样的操作台昂贵。相反，React基于这两点的假设，实现了一个启发的O(n)算法：

①两个不同类型的元素将产生两颗不同的树
②通过渲染器附带的key属性，开发者可以示意，那些子元素是稳定的。

实践中，这种假设适用于大部分的应用场景的。

对比算法

当对比两棵树时，React首先比较他们的根节点。根节点的type不同，他们的行为也不同。

不同类型的元素

每当根元素有不同的类型，React就会卸载旧树，创建新树，从到或从

到，或从 到

，任何的调整都会导致全部重建。

当树被卸载，旧的DOM节点将被销毁。组件实例会调用componentWillUnmount()。当构建一棵新树，新的DOM节点被插入到DOM中。组件实例将依次调用componentWillMount()和componentDidMount()。任何与旧树有关的状态都将丢弃。

这个根节点下，所有的组件都会被卸载，同时他们的状态会被销毁。
以下的节点对比前后：

由于根节点换了，所以组件将会重载新的组件。

相同类型的DOM元素

当比较2个相同的React DOM元素时，React则会观察两者的属性。

当比较两个相同类型的React DOM元素时，React则会观察二者的属性，保持相同的底层DOM节点，并仅更新变化的属性。例如：

通过比较两个元素，React知道仅更改底层DOM元素的className。

当更新style时，React同样知道仅更新变更的属性。例如：

当在调整两个元素时，React知道仅改变color样式而不是fontWeight。

在处理完DOM元素后，React递归其子元素。

相同类型的组件元素

当组建更新时，实例还是保持一致。这样能让状态在渲染之间保留。React通过更新底层组件的props来渲染新的元素，并且在底层的组件上，依次调用componentWillReviceProps和componentWillUpdate的方法。

接下来render()方法被调用，同时对比算法 递归处理之前的结果和新的结果。

递归子节点

默认情况下，当递归DOM节点的子节点，React只在同一个时间点，递归2个子节点列表。并且在有发生不同的时候，产生一个变更。

如，当在子节点末尾增加一个元素，两棵树的转换效果很好：

  
first
  
second



  
first
  
second
  
third

React将会匹配两棵树的

first

，并匹配两棵树的

second

节点，并插入

third

节点树。

如果使用原生实现，在开始插入元素，会使得性能更加棘手，例如，两棵树的转换效果则比较糟糕：

  
Duke
  
Villanova



  
Connecticut
  
Duke
  
Villanova

React会调整每一个子节点，而非意识到可以完整保留

Duke

和

Villanova

子树。低效成了一个问题。

keys

为了解决以上这个低效的问题，React支持了一个key属性，当子节点有key时，React会用key来匹配原本树的子节点和新树的子节点，增加key可以让之前效率不高的样例中使变得高效。

  
Duke
  
Villanova



  
Connecticut
  
Duke
  
Villanova

现在React知道带有'2014'的key的元素是新的，并仅移动带有'2015'和'2016'的key的元素。

实践中，发现key通常不难。你将展示的元素可能已经带有一个唯一的ID，因此key可以来自于你的数据中：

{item.name}

当这已不再是问题，你可以给你的数据增加一个新的ID属性，或根据数据的某些内容创建一个哈希值来作为key。

key必须在其兄弟节点中是唯一的，而非全局唯一。

万不得已，你可以传递他们在数组中的索引作为key。若元素没有重排，该方法效果不错，但重排会使得其变慢。

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

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

权衡

牢记协调算法的实现细节非常重要。React可能会在每次操作时渲染整个应用；而结果仍是相同的。为保证大多数场景效率能更快，我们通常提炼启发式的算法。

在目前实现中，可以表明一个事实，即子树在其兄弟节点中移动，但你无法告知其移动到哪。该算法会重渲整个子树。

由于React依赖于该启发式算法，若其背后的假设没得到满足，则其性能将会受到影响：

1.算法无法尝试匹配不同组件类型的子元素。若你发现两个输出非常相似的组件类型交替出现，你可能希望使其成为相同类型。实践中，我们并非发现这是一个问题。

2.Keys应该是稳定的，可预测的，且唯一的。不稳定的key（类似由Math.random()生成的）将使得大量组件实例和DOM节点进行不必要的重建，使得性能下降并丢失子组件的状态。