react reconciliation - Githubissues

Two assumptions make O(n3) become O(n)

1. Two elements of different types will produce different trees.
1. The developer can hint at which child elements may be stable across different renders with a key prop.

这两条假设看着简单，但理解起来确实让人摸不着头脑。这边的 different types 是指节点不同，比如 <Button> <Image> <Text> 这些。不同的节点，肯定意味着树不同。

React 采用广度优先的算法，来进行 virtual dom 树的比较。如果一颗树的子节点的 type 都不同，那么比较起来就比较简单，不同的节点就当作不同树进行替换就好。

但如果子节点的 type 有一样的，那要如何区分树相同还是不同呢？

或者当你新增或删除一个相同的子节点时，你知道新增或删除了哪个？

所以此时就需要第二条假设，除了用子节点类型来区分，还可以用一个 key 来区分。所以这边的 key 的主要作用是为了区分不同节点的，只是在用的好的话会带来性能上的优化。

默认会使用 index 作为 key，一般情况下，只要不在子节点的前面和中间位置进行增删操作就没有问题。

有了key属性后，就可以与组件建立了一种对应关系，react根据key来决定是销毁重新创建组件还是更新组件。

key相同，若组件属性有所变化，则react只更新组件对应的属性；没有变化则不更新。会执行到 componentWillReceiveProps() 和 componentWillUpdate()。
key值不同，则react先销毁该组件(有状态组件的componentWillUnmount会执行)，然后重新创建该组件（有状态组件的constructor和componentWillMount都会执行）

key 需要稳定、可预测、并且唯一，不要使用 index 和随机数作为key，使用随机数作为 key，会导致很多不必要的重建，影响性能。

{this.state.data.map((v,idx)=><Item key={idx} v={v} />)}
// 开始时：['a','b','c']=>
<ul>
    <li key="0">a <input type="text"/></li>
    <li key="1">b <input type="text"/></li>
    <li key="2">c <input type="text"/></li>
</ul>

// 数组重排 -> ['c','b','a'] =>
<ul>
    <li key="0">c <input type="text"/></li>
    <li key="1">b <input type="text"/></li>
    <li key="2">a <input type="text"/></li>
</ul>

上面实例中在数组重新排序后，key对应的实例都没有销毁，而是重新更新。具体更新过程我们拿key=0的元素来说明，数组重新排序后：

组件重新render得到新的虚拟dom；
新老两个虚拟dom进行diff，新老版的都有key=0的组件，react认为同一个组件，则只可能更新组件；
然后比较其children，发现内容的文本内容不同（由a--->c)，而input组件并没有变化，这时触发组件的componentWillReceiveProps方法，从而更新其子组件文本内容;
因为组件的children中input组件没有变化，其又与父组件传入的任props没有关联，所以input组件不会更新(即其componentWillReceiveProps方法不会被执行)，导致用户输入的值不会变化。

CPPAlien / JS-QA

react reconciliation #9