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

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

我曾經(jīng)寫過關(guān)于構(gòu)建用戶界面中遇到的挑戰(zhàn)的文章。但是本文將會(huì)用另外一種方式來講述 React —— 因?yàn)樗袷且环N編程運(yùn)行時(shí)。

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

? 注意：如果你還在學(xué)習(xí) React ，請(qǐng)移步到官方文檔進(jìn)行學(xué)習(xí)

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

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

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

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

宿主樹

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

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

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

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

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

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

宿主實(shí)例

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

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

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

(這和 React 沒有任何聯(lián)系 — 因?yàn)槲以谥v述宿主環(huán)境。)

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

渲染器

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

React 渲染器能以下面兩種模式之一進(jìn)行工作。

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

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

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

React 元素

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

React 元素是一個(gè)普通的 JavaScript 對(duì)象。它用來描述一個(gè)宿主實(shí)例。

 
 
 

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

React 元素是輕量級(jí)的，因?yàn)闆]有任何宿主實(shí)例與它綁定在一起。同樣，它只是對(duì)你想要在屏幕上看到的內(nèi)容的描述。

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

 
 
 

  
  
  
// JSX 是用來描述這些對(duì)象的語(yǔ)法糖。
  
  
  
// 

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

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

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

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

我喜歡將 React 元素比作電影中放映的每一幀。它們捕捉 UI 在特定的時(shí)間點(diǎn)的樣子。它們永遠(yuǎn)不會(huì)再改變。

入口

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

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

 
 
 

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

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

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

 
 
 

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

在我們的例子中，React 會(huì)這樣做：

 
 
 

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

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

協(xié)調(diào)

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

 
 
 

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

  
  
  
// ... 之后 ...
  
  
  

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

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

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

 
 
 

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

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

 
 
 

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

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

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

在我們的例子中，它很簡(jiǎn)單。我們之前渲染了

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

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

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

 
 
 

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

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

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

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

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

 
 
 

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

  
  
  
    
  
  
  
  

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

• dialog → dialog ：能重用宿主實(shí)例嗎?能 — 因?yàn)轭愋褪瞧ヅ涞摹?
  • input → p ：能重用宿主實(shí)例嗎?不能，類型改變了! 需要?jiǎng)h除已有的 input 然后重新創(chuàng)建一個(gè) p 宿主實(shí)例。
  • (nothing) → input ：需要重新創(chuàng)建一個(gè) input 宿主實(shí)例。

因此，React 會(huì)像這樣執(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); 
 
 
 

這樣的做法并不科學(xué)因?yàn)槭聦?shí)上 并沒有被

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

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

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

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

 
 
 

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

  
  
  
      {message}
  
  
  
      
  
  
  
    
  
  
  
  );
  
  
  
} 
 
 
 

這個(gè)例子并不會(huì)遇到剛剛我們所描述的問題。讓我們用對(duì)象注釋而不是 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 ，在渲染的過程中 總是在第二個(gè)孩子的位置且不會(huì)改變。

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

• dialog → dialog ：能夠重用宿主實(shí)例嗎?能 — 因?yàn)轭愋推ヅ洹?
  • (null) → p ：需要插入一個(gè)新的 p 宿主實(shí)例。
  • input → input ：能夠重用宿主實(shí)例嗎?能 — 因?yàn)轭愋推ヅ洹?/li>

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

 
 
 

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

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

列表

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

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

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

 
 
 

  
  
  
function ShoppingList({ list }) {
  
  
  
  return (
  
  
  
    

  
  
  
      {list.map(item => (
  
  
  
        

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

  
  
  
      ))}
  
  
  
    
  
  
  
  )
  
  
  
} 
 
 
 

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

所以 React 會(huì)對(duì)這十個(gè)商品進(jìn)行類似如下的重排序：

 
 
 

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

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

這就是為什么每次當(dāng)輸出中包含元素?cái)?shù)組時(shí)，React 都會(huì)讓你指定一個(gè)叫做 key 的屬性：

 
 
 

  
  
  
function ShoppingList({ list }) {
  
  
  
  return (
  
  
  
    

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

  
  
  
      ))}
  
  
  
    
  
  
  
  )
  
  
  
} 
 
 
 

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

當(dāng) 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)部的某個(gè)地方
   
  
  
let type = reactElement.type; // Form
   
  
  
let props = reactElement.props; // { showMessage: true }
   
  
  
let result = type(props); // 無論 Form 會(huì)返回什么
  
 
 

  
 
 

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

          
 
 

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

           
  
  
  

           
  
  
    Some text