很多教程都把 React 作為一個 UI 庫來引入。這是很有道理的，因為 React 本身就是一個 UI 庫。就像官網(wǎng)上所說的那樣。

目前成都創(chuàng)新互聯(lián)公司已為上千多家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)站空間、成都網(wǎng)站托管、企業(yè)網(wǎng)站設計、蘄春網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

我曾經(jīng)寫過關(guān)于構(gòu)建用戶界面中遇到的挑戰(zhàn)的文章。但是本文將會用另外一種方式來講述 React —— 因為它更像是一種編程運行時。

本文不會教你任何有關(guān)如何創(chuàng)建界面的技巧。 但是它可能會幫你更加深入地理解 React 編程模型。

? 注意：如果你還在學習 React ，請移步到官方文檔進行學習

本文將會非常深入 —— 所以不適合初學者閱讀。在本文中，我會從***原則的角度盡可能地闡述 React 編程模型。我不會解釋如何使用它 —— 而是講解它的工作原理。

本文面向有經(jīng)驗的程序員，還有使用過其他 UI 庫，但在項目中權(quán)衡利弊之后最終選擇了 React 的人，我希望它會對你有所幫助!

一些人用了很多年 React 卻從沒有考慮過接下來我要講述的主題。 這絕對是以程序員而不是以設計者的角度來看待 React。但我認為站在兩個不同的角度來重新認識 React 并沒有什么壞處。

廢話少說，讓我們開始深入理解 React 吧!

宿主樹

一些程序輸出數(shù)字。另一些程序輸出詩詞。不同的語言和它們的運行時通常會對特定的一組用例進行優(yōu)化， React 也不例外。

React 程序通常會輸出一個會隨時間變化的樹。 它有可能是 DOM 樹 、iOS 視圖層、PDF 原語 ，或者是 JSON 對象 。不過通常我們希望用它來展示 UI 。我們稱它為“宿主樹”，因為它往往是 React 之外宿主環(huán)境中的一部分 —— 就像 DOM 或 iOS 。宿主樹通常有它自己的命令式 API 。而 React 就是它上面的那一層。

所以 React 到底有什么用呢?非常抽象，它可以幫助你編寫可預測的，并且能夠操控復雜的宿主樹進而響應像用戶交互、網(wǎng)絡響應、定時器等外部事件的應用程序。

當一個專業(yè)的工具可以施加特定的約束，并且能從中獲益時，它就比一般的工具要好。React 就是這樣的典范，并且它堅持兩個原則：

• 穩(wěn)定性。 宿主樹是相對穩(wěn)定的，大多數(shù)情況的更新并不會從根本上改變其整體結(jié)構(gòu)。如果應用程序每秒都會將其所有可交互的元素重新排列為完全不同的組合，那將會變得難以使用。那個按鈕去哪了?為什么我的屏幕在跳舞?
• 通用性。 宿主樹可以被拆分為外觀和行為一致的 UI 模式(例如按鈕、列表和頭像)而不是隨機的形狀。

這些原則恰好適用于大多數(shù) UI 。 不過當輸出沒有穩(wěn)定的“模式”時 React 并不適用。例如，React 也許可以幫你寫一個 Twitter 客戶端，但對于一個 3D 管道屏幕保護程序并沒有太大用處。

宿主實例

宿主樹由節(jié)點組成，我們稱之為“宿主實例”。

在 DOM 環(huán)境中，宿主實例就是我們通常所說的 DOM 節(jié)點 —— 就像當你調(diào)用 document.createElement('div') 時獲得的對象。在 iOS 中，宿主實例可以是從 JavaScript 到原生視圖唯一標識的值。

宿主實例有它們自己的屬性(例如 domNode.className 或者 view.tintColor )。它們也有可能將其他的宿主實例作為子項。

(這和 React 沒有任何聯(lián)系 — 因為我在講述宿主環(huán)境。)

通常會有原生 API 用于操控這些宿主實例。例如，在 DOM 環(huán)境中會提供像 appendChild、 removeChild、 setAttribute 等一系列的 API 。在 React 應用中，通常你不會調(diào)用這些 API ，因為那是 React 的工作。

渲染器

渲染器告訴 React 如何與特定的宿主環(huán)境通信，以及如何管理它的宿主實例。React DOM、React Native 甚至 Ink 都可以被稱作 React 渲染器。你也可以創(chuàng)建自己的 React 渲染器 。

React 渲染器能以下面兩種模式之一進行工作。

絕大多數(shù)渲染器都被用作“突變”模式。這種模式正是 DOM 的工作方式：我們可以創(chuàng)建一個節(jié)點，設置它的屬性，在之后往里面增加或者刪除子節(jié)點。宿主實例是完全可變的。

但 React 也能以”不變“模式工作。這種模式適用于那些并不提供像 appendChild 的 API 而是克隆雙親樹并始終替換掉***子樹的宿主環(huán)境。在宿主樹級別上的不可變性使得多線程變得更加容易。React Fabric 就利用了這一模式。

作為 React 的使用者，你永遠不需要考慮這些模式。我只想強調(diào) React 不僅僅只是從一種模式轉(zhuǎn)換到另一種模式的適配器。它的用處在于以一種更好的方式操控宿主實例而不用在意那些低級視圖 API 范例。

React 元素

在宿主環(huán)境中，一個宿主實例(例如 DOM 節(jié)點)是最小的構(gòu)建單元。而在 React 中，最小的構(gòu)建單元是 React 元素。

React 元素是一個普通的 JavaScript 對象。它用來描述一個宿主實例。

 
 
 

  
  
  
// JSX 是用來描述這些對象的語法糖。
  
  
  
// 
  
  
  
{
  
  
  
  type: 'button',
  
  
  
  props: { className: 'blue' }
  
  
  
} 
 
 
 

React 元素是輕量級的，因為沒有任何宿主實例與它綁定在一起。同樣，它只是對你想要在屏幕上看到的內(nèi)容的描述。

就像宿主實例一樣，React 元素也能形成一棵樹：

 
 
 

  
  
  
// JSX 是用來描述這些對象的語法糖。
  
  
  
// 

  
  
  
//   
  
  
  
//   
  
  
  
// 
  
  
  
{
  
  
  
  type: 'dialog',
  
  
  
  props: {
  
  
  
    children: [{
  
  
  
      type: 'button',
  
  
  
      props: { className: 'blue' }
  
  
  
    }, {
  
  
  
      type: 'button',
  
  
  
      props: { className: 'red' }
  
  
  
    }]
  
  
  
  }
  
  
  
} 
 
 
 

(注意：我省略了一些對此解釋不重要的屬性)

但是請記住 React 元素并不是永遠存在的 。它們總是在重建和刪除之間不斷循環(huán)。

React 元素具有不可變性。例如你不能改變 React 元素中的子元素或者屬性。如果你想要在稍后渲染一些不同的東西，需要從頭創(chuàng)建新的 React 元素樹來描述它。

我喜歡將 React 元素比作電影中放映的每一幀。它們捕捉 UI 在特定的時間點的樣子。它們永遠不會再改變。

入口

每一個 React 渲染器都有一個“入口”。正是那個特定的 API 讓我們告訴 React ，將特定的 React 元素樹渲染到真正的宿主實例中去。

例如，React DOM 的入口就是 ReactDOM.render ：

 
 
 

  
  
  
ReactDOM.render(
  
  
  
  // { type: 'button', props: { className: 'blue' } }
  
  
  
  ,
  
  
  
  document.getElementById('container')
  
  
  
); 
 
 
 

當我們調(diào)用 ReactDOM.render(reactElement, domContainer) 時，我們的意思是：“親愛的 React ，將我的 reactElement 映射到 domContaienr 的宿主樹上去吧?！?/p>

React 會查看 reactElement.type (在我們的例子中是 button )然后告訴 React DOM 渲染器創(chuàng)建對應的宿主實例并設置正確的屬性：

 
 
 

  
  
  
// 在 ReactDOM 渲染器內(nèi)部（簡化版）
  
  
  
function createHostInstance(reactElement) {
  
  
  
  let domNode = document.createElement(reactElement.type);  
  
  
  
  domNode.className = reactElement.props.className;
  
  
  
  return domNode;
  
  
  
} 
 
 
 

在我們的例子中，React 會這樣做：

 
 
 

  
  
  
let domNode = document.createElement('button');
  
  
  
domNode.className = 'blue';
  
  
  
domContainer.appendChild(domNode); 
 
 
 

如果 React 元素在 reactElement.props.children 中含有子元素，React 會在***次渲染中遞歸地為它們創(chuàng)建宿主實例。

協(xié)調(diào)

如果我們用同一個 container 調(diào)用 ReactDOM.render() 兩次會發(fā)生什么呢?

 
 
 

  
  
  
ReactDOM.render(
  
  
  
  ,  document.getElementById('container')
  
  
  
);
  
  
  

  
  
  
// ... 之后 ...
  
  
  

  
  
  
// 應該替換掉 button 宿主實例嗎？
  
  
  
// 還是在已有的 button 上更新屬性？
  
  
  
ReactDOM.render(
  
  
  
  ,  document.getElementById('container')
  
  
  
); 
 
 
 

同樣，React 的工作是將 React 元素樹映射到宿主樹上去。確定該對宿主實例做什么來響應新的信息有時候叫做協(xié)調(diào) 。

有兩種方法可以解決它。簡化版的 React 會丟棄已經(jīng)存在的樹然后從頭開始創(chuàng)建它：

 
 
 

  
  
  
let domContainer = document.getElementById('container');
  
  
  
// 清除掉原來的樹
  
  
  
domContainer.innerHTML = '';
  
  
  
// 創(chuàng)建新的宿主實例樹
  
  
  
let domNode = document.createElement('button');
  
  
  
domNode.className = 'red';
  
  
  
domContainer.appendChild(domNode); 
 
 
 

但是在 DOM 環(huán)境下，這樣的做法效率很低，而且會丟失 focus、selection、scroll 等許多狀態(tài)。相反，我們希望 React 這樣做：

 
 
 

  
  
  
let domNode = domContainer.firstChild;
  
  
  
// 更新已有的宿主實例
  
  
  
domNode.className = 'red'; 
 
 
 

換句話說，React 需要決定何時更新一個已有的宿主實例來匹配新的 React 元素，何時該重新創(chuàng)建新的宿主實例。

這就引出了一個識別問題。React 元素可能每次都不相同，到底什么時候才該從概念上引用同一個宿主實例呢?

在我們的例子中，它很簡單。我們之前渲染了

這與 React 如何思考并解決這類問題已經(jīng)很接近了。

如果相同的元素類型在同一個地方先后出現(xiàn)兩次，React 會重用已有的宿主實例。

這里有一個例子，其中的注釋大致解釋了 React 是如何工作的：

 
 
 

  
  
  
// let domNode = document.createElement('button');
  
  
  
// domNode.className = 'blue';
  
  
  
// domContainer.appendChild(domNode);
  
  
  
ReactDOM.render(
  
  
  
  ,
  
  
  
  document.getElementById('container')
  
  
  
);
  
  
  

  
  
  
// 能重用宿主實例嗎？能！(button → button)
  
  
  
// domNode.className = 'red';
  
  
  
ReactDOM.render(
  
  
  
  ,
  
  
  
  document.getElementById('container')
  
  
  
);
  
  
  

  
  
  
// 能重用宿主實例嗎？不能！(button → p)
  
  
  
// domContainer.removeChild(domNode);
  
  
  
// domNode = document.createElement('p');
  
  
  
// domNode.textContent = 'Hello';
  
  
  
// domContainer.appendChild(domNode);
  
  
  
ReactDOM.render(
  
  
  
  
Hello
,
  
  
  
  document.getElementById('container')
  
  
  
);
  
  
  

  
  
  
// 能重用宿主實例嗎？能！(p → p)
  
  
  
// domNode.textContent = 'Goodbye';
  
  
  
ReactDOM.render(
  
  
  
  
Goodbye
,
  
  
  
  document.getElementById('container')
  
  
  
); 
 
 
 

同樣的啟發(fā)式方法也適用于子樹。例如，當我們在

 
 
 

  
  
  
// ***次渲染
  
  
  
ReactDOM.render(
  
  
  
  

  
  
  
    
  
  
  
  

在這個例子中， 宿主實例會被重新創(chuàng)建。React 會遍歷整個元素樹，并將其與先前的版本進行比較：

• dialog → dialog ：能重用宿主實例嗎?能 — 因為類型是匹配的。
  • input → p ：能重用宿主實例嗎?不能，類型改變了! 需要刪除已有的 input 然后重新創(chuàng)建一個 p 宿主實例。
  • (nothing) → input ：需要重新創(chuàng)建一個 input 宿主實例。

因此，React 會像這樣執(zhí)行更新：

 
 
 

  
  
  
let oldInputNode = dialogNode.firstChild;
  
  
  
dialogNode.removeChild(oldInputNode);
  
  
  

  
  
  
let pNode = document.createElement('p');
  
  
  
pNode.textContent = 'I was just added here!';
  
  
  
dialogNode.appendChild(pNode);
  
  
  

  
  
  
let newInputNode = document.createElement('input');
  
  
  
dialogNode.appendChild(newInputNode); 
 
 
 

這樣的做法并不科學因為事實上 并沒有被

所替代 — 它只是移動了位置而已。我們不希望因為重建 DOM 而丟失了 selection、focus 等狀態(tài)以及其中的內(nèi)容。

所替代 — 它只是移動了位置而已。我們不希望因為重建 DOM 而丟失了 selection、focus 等狀態(tài)以及其中的內(nèi)容。

雖然這個問題很容易解決(在下面我會馬上講到)，但這個問題在 React 應用中并不常見。而當我們探討為什么會這樣時卻很有意思。

事實上，你很少會直接調(diào)用 ReactDOM.render 。相反，在 React 應用中程序往往會被拆分成這樣的函數(shù)：

 
 
 

  
  
  
function Form({ showMessage }) {
  
  
  
  let message = null;
  
  
  
  if (showMessage) {
  
  
  
    message = 
I was just added here!
;
  
  
  
  }
  
  
  
  return (
  
  
  
    

  
  
  
      {message}
  
  
  
      
  
  
  
    
  
  
  
  );
  
  
  
} 
 
 
 

這個例子并不會遇到剛剛我們所描述的問題。讓我們用對象注釋而不是 JSX 也許可以更好地理解其中的原因。來看一下 dialog 中的子元素樹：

 
 
 

  
  
  
function Form({ showMessage }) {
  
  
  
  let message = null;
  
  
  
  if (showMessage) {
  
  
  
    message = {
  
  
  
      type: 'p',
  
  
  
      props: { children: 'I was just added here!' }
  
  
  
    };
  
  
  
  }
  
  
  
  return {
  
  
  
    type: 'dialog',
  
  
  
    props: {
  
  
  
      children: [
  
  
  
        message,
  
  
  
        { type: 'input', props: {} }
  
  
  
      ]
  
  
  
    }
  
  
  
  };
  
  
  
}
 
 
 

不管 showMessage 是 true 還是 false ，在渲染的過程中 總是在第二個孩子的位置且不會改變。

如果 showMessage 從 false 改變?yōu)?true ，React 會遍歷整個元素樹，并與之前的版本進行比較：

• dialog → dialog ：能夠重用宿主實例嗎?能 — 因為類型匹配。
  • (null) → p ：需要插入一個新的 p 宿主實例。
  • input → input ：能夠重用宿主實例嗎?能 — 因為類型匹配。

之后 React 大致會像這樣執(zhí)行代碼：

 
 
 

  
  
  
let inputNode = dialogNode.firstChild; 
  
  
  
let pNode = document.createElement('p'); 
  
  
  
pNode.textContent = 'I was just added here!'; 
  
  
  
dialogNode.insertBefore(pNode, inputNode); 
 
 
 

這樣一來輸入框中的狀態(tài)就不會丟失了。

列表

比較樹中同一位置的元素類型對于是否該重用還是重建相應的宿主實例往往已經(jīng)足夠。

但這只適用于當子元素是靜止的并且不會重排序的情況。在上面的例子中，即使 message 不存在，我們?nèi)匀恢垒斎肟蛟谙⒅?，并且再沒有其他的子元素。

而當遇到動態(tài)列表時，我們不能確定其中的順序總是一成不變的。

 
 
 

  
  
  
function ShoppingList({ list }) {
  
  
  
  return (
  
  
  
    

  
  
  
      {list.map(item => (
  
  
  
        

  
  
  
          You bought {item.name}
  
  
  
          
  
  
  
          Enter how many do you want: 
  
  
  
        

  
  
  
      ))}
  
  
  
    
  
  
  
  )
  
  
  
} 
 
 
 

如果我們的商品列表被重新排序了，React 只會看到所有的 p 以及里面的 input 擁有相同的類型，并不知道該如何移動它們。(在 React 看來，雖然這些商品本身改變了，但是它們的順序并沒有改變。)

所以 React 會對這十個商品進行類似如下的重排序：

 
 
 

  
  
  
for (let i = 0; i < 10; i++) {
  
  
  
  let pNode = formNode.childNodes[i];
  
  
  
  let textNode = pNode.firstChild;
  
  
  
  textNode.textContent = 'You bought ' + items[i].name;
  
  
  
} 
 
 
 

React 只會對其中的每個元素進行更新而不是將其重新排序。這樣做會造成性能上的問題和潛在的 bug 。例如，當商品列表的順序改變時，原本在***個輸入框的內(nèi)容仍然會存在于現(xiàn)在的***個輸入框中 — 盡管事實上在商品列表里它應該代表著其他的商品!

這就是為什么每次當輸出中包含元素數(shù)組時，React 都會讓你指定一個叫做 key 的屬性：

 
 
 

  
  
  
function ShoppingList({ list }) {
  
  
  
  return (
  
  
  
    

  
  
  
      {list.map(item => (
  
  
  
        
  
  
  
          You bought {item.name}
  
  
  
          
  
  
  
          Enter how many do you want: 
  
  
  
        

  
  
  
      ))}
  
  
  
    
  
  
  
  )
  
  
  
} 
 
 
 

key 給予 React 判斷子元素是否真正相同的能力，即使在渲染前后它在父元素中的位置不是相同的。

當 React 在

  
 
 

   
  
  
function Form({ showMessage }) {
   
  
  
  let message = null;
   
  
  
  if (showMessage) {
   
  
  
    message = 
I was just added here!
;
   
  
  
  }
   
  
  
  return (
   
  
  
    

   
  
  
      {message}
   
  
  
      
   
  
  
    
   
  
  
  );
   
  
  
} 
  
 
 

  
 
 

   
  
  
function Button(props) {
   
  
  
  //  沒有作用
   
  
  
  props.isActive = true;
   
  
  
} 
  
 
 

  
 
 

   
  
  
function FriendList({ friends }) {
   
  
  
  let items = [];
   
  
  
  for (let i = 0; i < friends.length; i++) {
   
  
  
    let friend = friends[i];
   
  
  
    items.push(
   
  
  
      
   
  
  
    );
   
  
  
  }
   
  
  
  return 
{items}
;
   
  
  
}
  
 
 

  
 
 

   
  
  
function ExpenseForm() {
   
  
  
  // 只要不影響其他組件這是被允許的：
   
  
  
  SuperCalculator.initializeIfNotReady();
   
  
  

   
  
  
  // 繼續(xù)渲染......
   
  
  
}
  
 
 

  
 
 

   
  
  
let reactElement = Form({ showMessage: true }); 
   
  
  
ReactDOM.render(reactElement, domContainer); 
  
 
 

  
 
 

   
  
  
// { type: Form, props: { showMessage: true } }
   
  
  
let reactElement = ;
   
  
  
ReactDOM.render(reactElement, domContainer);
  
 
 

  
 
 

   
  
  
// React 內(nèi)部的某個地方
   
  
  
let type = reactElement.type; // Form
   
  
  
let props = reactElement.props; // { showMessage: true }
   
  
  
let result = type(props); // 無論 Form 會返回什么
  
 
 

  
 
 

   
  
  
console.log(.type); // 'form' 字符串 
   
  
  
console.log(.type); // Form 函數(shù) 
  
 
 

          
 
 

           
  
  
// 最終的 DOM 結(jié)構(gòu)
           
  
  

           
  
  
  

           
  
  
    Some text