` 都会触发一个完整的重建流程。
-
-当卸载一棵树时，对应的 DOM 节点也会被销毁。组件实例将执行 `componentWillUnmount()` 方法。当建立一棵新的树时，对应的 DOM 节点会被创建以及插入到 DOM 中。组件实例将执行 `UNSAFE_componentWillMount()` 方法，紧接着 `componentDidMount()` 方法。所有与之前的树相关联的 state 也会被销毁。
-
-在根节点以下的组件也会被卸载，它们的状态会被销毁。比如，当比对以下更变时：
-
-```xml
-
-
-
-
-
-
-
-```
-
-React 会销毁 `Counter` 组件并且重新装载一个新的组件。
-
->注意：
->
->这些方法被认为是过时的，在新的代码中应该[避免使用它们](/blog/2018/03/27/update-on-async-rendering.html)：
->
->- `UNSAFE_componentWillMount()`
-
-### 对比同一类型的元素 {#dom-elements-of-the-same-type}
-
-当对比两个相同类型的 React 元素时，React 会保留 DOM 节点，仅比对及更新有改变的属性。比如：
-
-```xml
-
-
-
-```
-
-通过对比这两个元素，React 知道只需要修改 DOM 元素上的 `className` 属性。
-
-当更新 `style` 属性时，React 仅更新有所更变的属性。比如：
-
-```xml
-
-
-
-```
-
-通过对比这两个元素，React 知道只需要修改 DOM 元素上的 `color` 样式，无需修改 `fontWeight`。
-
-在处理完当前节点之后，React 继续对子节点进行递归。
-
-### 对比同类型的组件元素 {#component-elements-of-the-same-type}
-
-当一个组件更新时，组件实例会保持不变，因此可以在不同的渲染时保持 state 一致。React 将更新该组件实例的 props 以保证与最新的元素保持一致，并且调用该实例的 `UNSAFE_componentWillReceiveProps()`、`UNSAFE_componentWillUpdate()` 以及 `componentDidUpdate()` 方法。
-
-下一步，调用 `render()` 方法，diff 算法将在之前的结果以及新的结果中进行递归。
-
->注意：
->
->这些方法已过时，在新代码中应避免[使用它们](/blog/2018/03/27/update-on-async-rendering.html)：
->
->- `UNSAFE_componentWillUpdate()`
->- `UNSAFE_componentWillReceiveProps()`
-
-### 对子节点进行递归 {#recursing-on-children}
-
-默认情况下，当递归 DOM 节点的子元素时，React 会同时遍历两个子元素的列表；当产生差异时，生成一个 mutation。
-
-在子元素列表末尾新增元素时，更新开销比较小。比如：
-
-```xml
-
-
-
- - first
- - second
- - third
-
-```
-
-React 会先匹配两个 `
first` 对应的树，然后匹配第二个元素 `
second` 对应的树，最后插入第三个元素的 `
third` 树。
-
-如果只是简单的将新增元素插入到表头，那么更新开销会比较大。比如：
-
-```xml
-
-
-
- - Connecticut
- - Duke
- - Villanova
-
-```
-
-React 并不会意识到应该保留 `
Duke` 和 `
Villanova`，而是会重建每一个子元素。这种情况会带来性能问题。
-
-### Keys {#keys}
-
-为了解决上述问题，React 引入了 `key` 属性。当子元素拥有 key 时，React 使用 key 来匹配原有树上的子元素以及最新树上的子元素。以下示例在新增 `key` 之后，使得树的转换效率得以提高：
-
-```xml
-
-
-
- - Connecticut
- - Duke
- - Villanova
-
-```
-
-现在 React 知道只有带着 `'2014'` key 的元素是新元素，带着 `'2015'` 以及 `'2016'` key 的元素仅仅移动了。
-
-实际开发中，编写一个 key 并不困难。你要展现的元素可能已经有了一个唯一 ID，于是 key 可以直接从你的数据中提取：
-
-```js
-
{item.name}
-```
-
-当以上情况不成立时，你可以新增一个 ID 字段到你的模型中，或者利用一部分内容作为哈希值来生成一个 key。这个 key 不需要全局唯一，但在列表中需要保持唯一。
-
-最后，你也可以使用元素在数组中的下标作为 key。这个策略在元素不进行重新排序时比较合适，如果有顺序修改，diff 就会变慢。
-
-当基于下标的组件进行重新排序时，组件 state 可能会遇到一些问题。由于组件实例是基于它们的 key 来决定是否更新以及复用，如果 key 是一个下标，那么修改顺序时会修改当前的 key，导致非受控组件的 state（比如输入框）可能相互篡改，会出现无法预期的变动。
-
-在 Codepen 有两个例子，分别为 [展示使用下标作为 key 时导致的问题](codepen://reconciliation/index-used-as-key)，以及[不使用下标作为 key 的例子的版本，修复了重新排列，排序，以及在列表头插入的问题](codepen://reconciliation/no-index-used-as-key)。
-
-## 权衡 {#tradeoffs}
-
-请谨记协调算法是一个实现细节。React 可以在每个 action 之后对整个应用进行重新渲染，得到的最终结果也会是一样的。在此情境下，重新渲染表示在所有组件内调用 `render` 方法，这不代表 React 会卸载或装载它们。React 只会基于以上提到的规则来决定如何进行差异的合并。
-
-我们定期优化启发式算法，让常见用例更高效地执行。在当前的实现中，可以理解为一棵子树能在其兄弟之间移动，但不能移动到其他位置。在这种情况下，算法会重新渲染整棵子树。
-
-由于 React 依赖启发式算法，因此当以下假设没有得到满足，性能会有所损耗。
-
-1. 该算法不会尝试匹配不同组件类型的子树。如果你发现你在两种不同类型的组件中切换，但输出非常相似的内容，建议把它们改成同一类型。在实践中，我们没有遇到这类问题。
-
-2. Key 应该具有稳定，可预测，以及列表内唯一的特质。不稳定的 key（比如通过 `Math.random()` 生成的）会导致许多组件实例和 DOM 节点被不必要地重新创建，这可能导致性能下降和子组件中的状态丢失。
diff --git a/content/docs/reference-dom-elements.md b/content/docs/reference-dom-elements.md
deleted file mode 100644
index e7c8bac7e8..0000000000
--- a/content/docs/reference-dom-elements.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-id: dom-elements
-title: DOM 元素
-layout: docs
-category: Reference
-permalink: docs/dom-elements.html
-redirect_from:
- - "docs/tags-and-attributes.html"
- - "docs/dom-differences.html"
- - "docs/special-non-dom-attributes.html"
- - "docs/class-name-manipulation.html"
- - "tips/inline-styles.html"
- - "tips/style-props-value-px.html"
- - "tips/dangerously-set-inner-html.html"
----
-
-> Try the new React documentation.
->
-> These new documentation pages teach modern React and include live examples:
->
-> - [Common components (e.g. `