Reconciliation

嘗試新的 React 文件。

這些新的文件頁面教導 modern React 並包括即時範例：

Preserving and Resetting State

新的文件將會很快取代目前的文件，它將會被歸檔。提供回饋。

React 提供聲明式 (declarative) 的 API，讓開發者在使用 React 時，可以不用關注每次 Component 更新時底層有什麼改變。這讓開發應用程式簡單許多，但也可能讓開發者對 React 底層的相關實作不夠瞭解。因此在這篇文章中描述了實作 React 底層中「diffing」演算法時，我們採取什麼策略讓 component 的更新是可預測的，同時可以滿足要求高效能的應用程式。

動機

在使用 React 時，每次呼叫 render() 函式，我們都可以當成是建立了一顆由 React element 構成的樹狀結構。而在每一次有 state 或 props 更新時，render() 函式就會回傳一顆不同的 tree。因此，React 需要判斷如何有效率的把 UI 從舊的 tree 更新成新的 tree。

對於這個「如何用最少操作去將舊的 tree 轉換成新的 tree」的演算法問題有一些通用的解法，但即使是目前最先進的演算法都還需要 O(n³) 的時間複雜度（n 為 tree 中 element 的數量）。

假設 React 使用這種演算法，則呈現 1000 個 element 需要 10 億次的比較。因為這個比較成本實在太高，所以 React 在以下兩個假設下採用了一個 O(n) 的啓發式 (heuristic) 演算法：

兩個不同類型的 element 會產生出不同的 tree
開發者可以通過 key prop 來指出哪些子 element 在不同的 render 下能保持不變；

而事實上，以上假設在幾乎所有實務上會出現的場景都成立。

Diffing 演算法

當比對兩顆 tree 時，React 首先比較兩棵 tree 的 root element。不同類型的 root element 會有不同的處理方式。

比對不同類型的 Element

當比對的兩個 root element 為不同類型的元素時，React 會將原有的 tree 整顆拆掉並且重新建立起新的 tree。例如，當一個元素從 <a> 變成 <img>、從 <Article> 變成 <Comment>、或從 <Button> 變成 <div> 時，都會觸發一個完整的重建流程。

當拆掉一顆 tree 時，舊的 DOM 節點會被銷毀，且該 component instance 會執行 componentWillUnmount() 函式。當建立一顆新的 tree 時，新建立的 DOM 節點會被插入到 DOM 中，且該 component instance 會依次執行 UNSAFE_componentWillMount() 與 componentDidMount() 方法。而所有跟之前舊的 tree 所關聯的 state 也會被銷毀。

任何在 root 以下的 component 也會被 unmount，它們的狀態會被銷毀。例如，當比對以下變更時：

<div>
  <Counter />
</div>

<span>
  <Counter />
</span>

React 會 destroy 舊的 Counter 並且重新建立一個新的。

筆記：

這個方法已經被認為已過時，你在寫新程式應避免使用他們：

UNSAFE_componentWillMount()

比對同一類型的 DOM Element

當比對兩個相同類型的 React element 時，React 會保留 DOM 節點，只比對及更新有改變的 attribute。例如：

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

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

透過比對這兩個 element，React 知道只需要修改 DOM 節點上的 className。

當更新 style 時，React 僅更新有所更變的屬性。例如：

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

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

透過比對這兩個 element，React 知道只需要修改 color 的樣式，而不需修改 fontWeight。

在處理完目前節點之後，React 會繼續對 children 進行遞迴處理。

比對同類型的 Component Element

當一個 component 更新時，該 component 的 instance 保持不變，這樣 state 能夠被保留在不同次的 render 中。React 會更新該 component instance 的 props 以跟最新的 element 保持一致，並且呼叫該 instance 的 UNSAFE_componentWillReceiveProps() 、 UNSAFE_componentWillUpdate() 和 componentDidUpdate() 方法。

接下來，該 instance 會再呼叫 render() 方法，而 diff 算法將會遞迴處理舊的結果以及新的結果。

筆記：

下列方法已過時，你在寫新程式應避免使用他們：

UNSAFE_componentWillUpdate()

UNSAFE_componentWillReceiveProps()

對 Children 進行遞迴處理

在預設條件下，當遞迴處理 DOM 節點的 children 時，React 只會同時遍歷兩個 children 的 array，並在發現差異時，產生一個 mutation。

例如，當在 children 的 array 尾端新增一個 element 時，在這兩個 tree 之間的轉換效果很好：

<ul>
  <li>first</li>
  <li>second</li>
</ul>

<ul>
  <li>first</li>
  <li>second</li>
  <li>third</li>
</ul>

React 會先匹配兩個 <li>first</li> 對應的 tree，然後匹配第二個元素 <li>second</li> 對應的 tree，最後插入第三個元素 <li>third</li> 的 tree。

如果只是單純的實作，則在 array 開頭插入新元素會讓效能變差。例如，在兩個 tree 之間的轉換效果很差：

<ul>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

<ul>
  <li>Connecticut</li>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

這個情況下，React 會針對每個 child 都進行 mutate，而不是讓兩個相同的 <li>Duke</li> 和 <li>Villanova</li> subtree 不參與 mutate。這種低效率的情況下可能會帶來效能問題。

Keys

為了解決以上問題，React 提供了 key 屬性。當 children 擁有 key 屬性時，React 使用 key 來匹配原有 tree 上的 children 以及後續 tree 的 children。例如，以下範例在新增 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 知道只有帶著 '2014' key 的 element 是新的，而帶著 '2015' 以及 '2016' key 的 element 只是相對位置移動了。

實際上，找出一個 key 通常並不困難。你要顯示的 element 可能已經具有唯一的 ID 了，這個 key 可能是來自於你的資料：

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

當以上情況不成立時，你可以新增一個 ID 字串到你的 Model 中，或者利用一部分內容作為 hash 來產生一個 key。這個 key 不需要是全域唯一，但在 array 中需要保持唯一。

最後，你也可以使用元素在 array 中的索引值作為 key。這個方法在元素不進行重新排序時比較合適，但如果有順序修改，diff 就會變慢。

當使用 array 索引值作為 key 的 component 進行重新排序時，component state 可能會遇到一些問題。由於 component instance 是基於它們的 key 來決定是否更新以及重複使用，如果 key 是一個索引值，那麼修改順序時會修改目前的 key，導致 component 的 state（例如不受控制輸入框）可能相互篡改導致無法預期的變動。

下面是一個在 Codepen 上的範例，示範使用索引值作為 key 時導致的問題，以及一個修復了重新排列、排序、以及在 array 開頭插入的問題，且不使用索引值作為 key 的版本。

權衡

請記得 Reconciliation 只是一個實作細節，即使 React 在每個動作後之後對整個應用進行重新 render，得到的最終結果也會和進行 Reconciliation 後是一樣的。在這個情形下，重新 render 表示在所有 component 內呼叫 render，這不代表 React 會 unmount 或重新 mount 它們。React 只會基於以上提到的規則來決定如何進行差異的合併。

我們會定期改善啟發式演算法，讓常見的使用場景能夠更有效率地執行。在目前的實作中，可以理解為一棵 subtree 能在其相同階層的兄弟之間移動，但不能移動到其他位置。如果移動到其他位置，則演算法會重新 render 整棵 subtree。

由於 React 依賴啓發式的演算法，因此當以下假設沒有得到滿足，效能將會有所影響。

該演算法不會嘗試匹配不同 component 類型的 subtree。如果你發現你在兩種不同類型的 component 中切換，但輸出非常相似的內容，建議把它們改成同一類型。實際上，我們沒有發現在改成同一種類型後會發生問題。
Key 應該具有穩定、可預測、以及 array 內唯一的特質。不穩定的 key（例如透過 Math.random() 隨機生成的）會導致許多 component instance 和 DOM 節點被不必要地重新建立，這可能導致效能低下和 child component 中的 state 丟失。

Is this page useful?Edit this page