前言
React提供了声明式API，因此在每次更新时你无需担心它是如何准确变化的。这将使得你的应用写起来更容易，但是React如何实现的可能并不清楚。
本篇将解释React的"diffing"算法，因此，组件更新是可预测的，同时对于高性能APP也是足够快的。
一、Motivation：
当你使用React，在某时刻你知道render()作为一个函数会创建React元素树。再下一状态或属性更新时，render()函数将返回一个不同的React元素树。React需要指出如何有效的更新UI来满足最近的树（就是上次更新后的树）。
对于这个产生将一种树转换为另一种树的最小的一组操作的算法问题有一些通用的解决方案。然后，最新的算法有一个复杂的顺序（O(n^3)，其中，n是元素在树中的个数）。如果用在React中，假如显示1000个元素则将需要10亿的比较。代价太大了，相反，React基于两条假设实现了O（n）算法：
- 两个不同类型的元素将产生不同的树；
- 开发者能够捕获含有key属性的子元素在不同的渲染中哪些可能是稳定的（不变的）；
实践中，这些假设对于几乎所有的实践用例是合适的。
二、The Diffing Algorithm（差异算法）：
当比较两颗树，React首先比较两者的根元素。这个行为取决于根元素的类型是否不同。
2.1 Elements of Different Types
无论何时根元素类型不同，React将删除老树，重建新树。当删除一颗树，老的DOM节点将销毁。组件实例将收到 componentWillUnmount()。当建立一颗新树，新的DOM节点将被插入DOM中。组件实例将收到 componentWillMount()以及componentDidMount()。任何与老树相关的状态将丢掉。
注：最新的v16.13.1中，不再建议使用 componentWillMount()。
以下例子中，根元素将会移除且销毁实例：
<div>
<Counter />
</div>
<span>
<Counter />
</span>
这将会销毁老的Counter并重新挂载新的Counter。
2.2 DOM Elements of The Same Type
当比较两个相同类型的React DOM元素，React查看两者的属性，保持相同的DOM节点，仅更新属性：
<div className="before" title="stuff" />
<div className="after" title="stuff" />
通过比较这两个元素，React知道DOM节点只修改了className。
2.3 Component Elements of The Same Type
当一个组件更新，其实例保持相同，因此，渲染器维持状态不变。React更新组件实例的属性来满足新的元素，并调用 componentWillReceiveProps() 以及componentWillUpdate()。
注：最新的v16.13.1中，不再建议使用 componentWillReceiveProps()。
接下来，render()将会被调用，diff算法递归遍历前后结果。
2.4 Recursing on Children
默认情况下，当递归一个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>树。
如果你的实现很随意（原文是naively，天真的...），在一开始插入元素将有较差的性能，例如：
<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>子树。
这里的意思是：
- 老树中的Duke树将被Connecticut替代；
- Villanova树将被Duke替换；
- 然后，再插入新的Villanova；
即每个子树节点（实例）都销毁，或者新建了....（为啥？因为没有key啊，下面会讲到）。
2.5 Keys
为了解决这个问题（2.4中的），React支持一个key属性。当子元素有key时，React使用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知道了key为‘2014’的元素是新元素，而key为‘2015’，‘2016’的元素只需要移动即可。
实际中，发现一个key通常并不难。将要显示的元素存在一个唯一的ID，而这仅仅来自于你的数据：
<li key={item.id}>{item.name}</li>
当这不再是问题，你可以添加一个新ID属性到你的模型中，或者hash某些内容来生成一个key。
这个key仅在其兄弟节点中唯一，并不全局唯一。
作为最后一个手段，你可以传递一个数组的下标作为key。如果这个节点没有重排序就能工作良好，而重排序则会变慢。当组件使用下标作为key时，重排序会导致其状态的问题。组件实例的更新和重用取决于它们的key。如果，key是下标，移动时将会改变。结果是，组件的状态就像不可控的输入一样，使得其混乱和非期望的方式更新。
2.6 Tradeoffs（权衡取舍）
记住调和器算法的实现细节是很重要的。React能够重渲染整个app在每一次行为时，最终结果将是相同的。说清楚点，重渲染在这次上下文中意味着对所有组件调用渲染器，并不是React将会unmount和remount。它只适用于这些在以前状态规则的不同。
我们定期改进启发式（heuristics）是为了使通常的案例更快。在当前实现中，你能够表达一颗子树在其兄弟间移动的情况，但无法指出移动到其它地方。（如果移动到其它地方）算法将会重渲染整颗子树。
因为React依赖启发式，如果假设不满足，性能将会变差：
- 算法不会尝试匹配不同类型组件的子树。如果你改动在两个组件类型有相似的输出，你可能希望使得它们有相同的类型。实际上我们无法发现这个问题；
- key应该稳定、可预测且唯一。不稳定的key（Math.random()产生的）将导致许多组件实例和DOM节点被无谓的重建，这将导致性能下降，以及子组件的状态丢失；
