React高頻面試題梳理，看看面試怎麼答？（上）

  • 2019 年 10 月 4 日
  • 筆記

這是ConardLi的第67篇原創，謝謝你的支持！

文中流程圖都為ConardLi原創，如需使用，請標明來源。

前段時間準備面試，總結了很多，下面是我在準備React面試時，結合自己的實際面試經歷，以及我以前源碼分析的文章，總結出來的一些 React高頻面試題目。

以前我寫的源碼分析的文章，並沒有很多人看，因為大部分情況下你不需要深入源碼也能懂得其中原理，並解決實際問題，這也是我總結這些面試題的原因，讓你在更短的時間內獲得更大的收益。

由於是以面試題的角度來討論，所以某些點可能不能非常深入，我在問題下面都貼了相關鏈接，如果想深入理解，請點擊這些文章。

由於題目較多，分為上、下兩篇，本篇文章我們先來討論如下19個題目：

  • React生命周期有哪些，16版本生命周期發生了哪些變化？
  • setState是同步的還是異步的？
  • 為什麼有時連續多次 setState只有一次生效？
  • React如何實現自己的事件機制？
  • 為何 React事件要自己綁定 this？
  • 原生事件和 React事件的區別？
  • React的合成事件是什麼？
  • React和原生事件的執行順序是什麼？可以混用嗎？
  • 虛擬Dom是什麼？
  • 虛擬Dom比 普通Dom更快嗎？
  • 虛擬Dom中的 $$typeof屬性的作用是什麼？
  • React組件的渲染流程是什麼？
  • 為什麼代碼中一定要引入 React？
  • 為什麼 React組件首字母必須大寫？
  • React在渲染 真實Dom時做了哪些性能優化？
  • 什麼是高階組件？如何實現？
  • HOC在業務場景中有哪些實際應用場景？
  • 高階組件( HOC)和 Mixin的異同點是什麼？
  • Hook有哪些優勢？

React生命周期有哪些，16版本生命周期發生了哪些變化？

15生命周期

  • 初始化階段
    • constructor 構造函數
    • getDefaultProps props默認值
    • getInitialState state默認值
  • 掛載階段
    • componentWillMount 組件初始化渲染前調用
    • render 組件渲染
    • componentDidMount組件掛載到 DOM後調用
  • 更新階段
    • componentWillReceiveProps 組件將要接收新 props前調用
    • shouldComponentUpdate 組件是否需要更新
    • componentWillUpdate 組件更新前調用
    • render 組件渲染
    • componentDidUpdate 組件更新後調用
  • 卸載階段
    • componentWillUnmount 組件卸載前調用

16生命周期

  • 初始化階段
    • constructor 構造函數
    • getDefaultProps props默認值
    • getInitialState state默認值
  • 掛載階段
    • staticgetDerivedStateFromProps(props,state)
    • render
    • componentDidMount

getDerivedStateFromProps：組件每次被 rerender的時候，包括在組件構建之後(虛擬 dom之後，實際 dom掛載之前)，每次獲取新的 props或 state之後；每次接收新的props之後都會返回一個對象作為新的 state，返回null則說明不需要更新 state；配合 componentDidUpdate，可以覆蓋 componentWillReceiveProps的所有用法

  • 更新階段
    • staticgetDerivedStateFromProps(props,state)
    • shouldComponentUpdate
    • render
    • getSnapshotBeforeUpdate(prevProps,prevState)
    • componentDidUpdate

getSnapshotBeforeUpdate：觸發時間: update發生的時候，在 render之後，在組件 dom渲染之前；返回一個值，作為 componentDidUpdate的第三個參數；配合 componentDidUpdate, 可以覆蓋 componentWillUpdate的所有用法

  • 卸載階段
    • componentWillUnmount
  • 錯誤處理
    • componentDidCatch

React16新的生命周期棄用了 componentWillMount、componentWillReceivePorps，componentWillUpdate新增了 getDerivedStateFromProps、getSnapshotBeforeUpdate來代替棄用的三個鉤子函數。

React16並沒有刪除這三個鉤子函數，但是不能和新增的鉤子函數混用， React17將會刪除這三個鉤子函數，新增了對錯誤的處理（ componentDidCatch）

setState是同步的還是異步的？

  • 生命周期和合成事件中

在 React的生命周期和合成事件中， React仍然處於他的更新機制中，這時無論調用多少次 setState，都會不會立即執行更新，而是將要更新的·存入 _pendingStateQueue，將要更新的組件存入 dirtyComponent。

當上一次更新機制執行完畢，以生命周期為例，所有組件，即最頂層組件 didmount後會將批處理標誌設置為 false。這時將取出 dirtyComponent中的組件以及 _pendingStateQueue中的 state進行更新。這樣就可以確保組件不會被重新渲染多次。

componentDidMount() {      this.setState({        index: this.state.index + 1      })      console.log('state', this.state.index);    }

所以，如上面的代碼，當我們在執行 setState後立即去獲取 state，這時是獲取不到更新後的 state的，因為處於 React的批處理機制中， state被暫存起來，待批處理機制完成之後，統一進行更新。

所以。setState本身並不是異步的，而是 React的批處理機制給人一種異步的假象。

  • 異步代碼和原生事件中
componentDidMount() {      setTimeout(() => {        console.log('調用setState');        this.setState({          index: this.state.index + 1        })        console.log('state', this.state.index);      }, 0);    }

如上面的代碼，當我們在異步代碼中調用 setState時，根據 JavaScript的異步機制，會將異步代碼先暫存，等所有同步代碼執行完畢後在執行，這時 React的批處理機制已經走完，處理標誌設被設置為 false，這時再調用 setState即可立即執行更新，拿到更新後的結果。

在原生事件中調用 setState並不會出發 React的批處理機制，所以立即能拿到最新結果。

  • 最佳實踐

setState的第二個參數接收一個函數，該函數會在 React的批處理機制完成之後調用，所以你想在調用 setState後立即獲取更新後的值，請在該回調函數中獲取。

this.setState({ index: this.state.index + 1 }, () => {        console.log(this.state.index);      })

推薦閱讀：由實際問題探究setState的執行機制

為什麼有時連續多次setState只有一次生效？

例如下面的代碼，兩次打印出的結果是相同的：

componentDidMount() {      this.setState({ index: this.state.index + 1 }, () => {        console.log(this.state.index);      })      this.setState({ index: this.state.index + 1 }, () => {        console.log(this.state.index);      })    }

原因就是 React會批處理機制中存儲的多個 setState進行合併，來看下 React源碼中的 _assign函數，類似於 Object的 assign：

_assign(nextState, typeof partial === 'function' ? partial.call(inst, nextState, props, context) : partial);

如果傳入的是對象，很明顯會被合併成一次，所以上面的代碼兩次打印的結果是相同的：

Object.assign(    nextState,    {index: state.index+ 1},    {index: state.index+ 1}  )

注意， assign函數中對函數做了特殊處理，處理第一個參數傳入的是函數，函數的參數 preState是前一次合併後的結果，所以計算結果是準確的：

componentDidMount() {      this.setState((state, props) => ({          index: state.index + 1      }), () => {        console.log(this.state.index);      })      this.setState((state, props) => ({          index: state.index + 1      }), () => {        console.log(this.state.index);      })    }

所以上面的代碼兩次打印的結果是不同的。

  • 最佳實踐

React會對多次連續的 setState進行合併，如果你想立即使用上次 setState後的結果進行下一次 setState，可以讓 setState 接收一個函數而不是一個對象。這個函數用上一個 state 作為第一個參數，將此次更新被應用時的 props 做為第二個參數。

React如何實現自己的事件機制？

React事件並沒有綁定在真實的 Dom節點上，而是通過事件代理，在最外層的 document上對事件進行統一分發。

組件掛載、更新時：

  • 通過 lastProps、 nextProps判斷是否新增、刪除事件分別調用事件註冊、卸載方法。
  • 調用 EventPluginHub的 enqueuePutListener進行事件存儲
  • 獲取 document對象。
  • 根據事件名稱（如 onClick、 onCaptureClick）判斷是進行冒泡還是捕獲。
  • 判斷是否存在 addEventListener方法，否則使用 attachEvent（兼容IE）。
  • 給 document註冊原生事件回調為 dispatchEvent(統一的事件分發機制）。

事件初始化：

  • EventPluginHub負責管理 React合成事件的 callback，它將 callback存儲在 listenerBank中，另外還存儲了負責合成事件的 Plugin。
  • 獲取綁定事件的元素的唯一標識 key。
  • 將 callback根據事件類型，元素的唯一標識 key存儲在 listenerBank中。
  • listenerBank的結構是： listenerBank[registrationName][key]。

觸發事件時：

  • 觸發 document註冊原生事件的回調 dispatchEvent
  • 獲取到觸發這個事件最深一級的元素
  • 遍歷這個元素的所有父元素，依次對每一級元素進行處理。
  • 構造合成事件。
  • 將每一級的合成事件存儲在 eventQueue事件隊列中。
  • 遍歷 eventQueue。
  • 通過 isPropagationStopped判斷當前事件是否執行了阻止冒泡方法。
  • 如果阻止了冒泡，停止遍歷，否則通過 executeDispatch執行合成事件。
  • 釋放處理完成的事件。

React在自己的合成事件中重寫了 stopPropagation方法，將 isPropagationStopped設置為 true，然後在遍歷每一級事件的過程中根據此遍歷判斷是否繼續執行。這就是 React自己實現的冒泡機制。

推薦閱讀：【React深入】React事件機制

為何React事件要自己綁定this？

在上面提到的事件處理流程中， React在 document上進行統一的事件分發， dispatchEvent通過循環調用所有層級的事件來模擬事件冒泡和捕獲。

在 React源碼中，當具體到某一事件處理函數將要調用時，將調用 invokeGuardedCallback方法。

function invokeGuardedCallback(name, func, a) {    try {      func(a);    } catch (x) {      if (caughtError === null) {        caughtError = x;      }    }  }

可見，事件處理函數是直接調用的，並沒有指定調用的組件，所以不進行手動綁定的情況下直接獲取到的 this是不準確的，所以我們需要手動將當前組件綁定到 this上。

原生事件和React事件的區別？

  • React 事件使用駝峰命名，而不是全部小寫。
  • 通過 JSX , 你傳遞一個函數作為事件處理程序，而不是一個字符串。
  • 在 React 中你不能通過返回 false 來阻止默認行為。必須明確調用 preventDefault。

React的合成事件是什麼？

React 根據 W3C 規範定義了每個事件處理函數的參數，即合成事件。

事件處理程序將傳遞 SyntheticEvent 的實例，這是一個跨瀏覽器原生事件包裝器。它具有與瀏覽器原生事件相同的接口，包括 stopPropagation() 和 preventDefault()，在所有瀏覽器中他們工作方式都相同。

React合成的 SyntheticEvent採用了事件池，這樣做可以大大節省內存，而不會頻繁的創建和銷毀事件對象。

另外，不管在什麼瀏覽器環境下，瀏覽器會將該事件類型統一創建為合成事件，從而達到了瀏覽器兼容的目的。

React和原生事件的執行順序是什麼？可以混用嗎？

React的所有事件都通過 document進行統一分發。當真實 Dom觸發事件後冒泡到 document後才會對 React事件進行處理。

所以原生的事件會先執行，然後執行 React合成事件，最後執行真正在 document上掛載的事件

React事件和原生事件最好不要混用。原生事件中如果執行了 stopPropagation方法，則會導致其他 React事件失效。因為所有元素的事件將無法冒泡到 document上，導致所有的 React事件都將無法被觸發。。

虛擬Dom是什麼？

在原生的 JavaScript程序中，我們直接對 DOM進行創建和更改，而 DOM元素通過我們監聽的事件和我們的應用程序進行通訊。

而 React會先將你的代碼轉換成一個 JavaScript對象，然後這個 JavaScript對象再轉換成真實 DOM。這個 JavaScript對象就是所謂的虛擬 DOM。

當我們需要創建或更新元素時， React首先會讓這個 VitrualDom對象進行創建和更改，然後再將 VitrualDom對象渲染成真實DOM。

當我們需要對 DOM進行事件監聽時，首先對 VitrualDom進行事件監聽， VitrualDom會代理原生的 DOM事件從而做出響應。

推薦閱讀：【React深入】深入分析虛擬DOM的渲染過程和特性

虛擬Dom比普通Dom更快嗎？

很多文章說 VitrualDom可以提升性能，這一說法實際上是很片面的。

直接操作 DOM是非常耗費性能的，這一點毋庸置疑。但是 React使用 VitrualDom也是無法避免操作 DOM的。

如果是首次渲染， VitrualDom不具有任何優勢，甚至它要進行更多的計算，消耗更多的內存。

VitrualDom的優勢在於 React的 Diff算法和批處理策略， React在頁面更新之前，提前計算好了如何進行更新和渲染 DOM。實際上，這個計算過程我們在直接操作 DOM時，也是可以自己判斷和實現的，但是一定會耗費非常多的精力和時間，而且往往我們自己做的是不如 React好的。所以，在這個過程中 React幫助我們"提升了性能"。

所以，我更傾向於說， VitrualDom幫助我們提高了開發效率，在重複渲染時它幫助我們計算如何更高效的更新，而不是它比 DOM操作更快。

虛擬Dom中的$$typeof屬性的作用是什麼？

ReactElement中有一個 $$typeof屬性，它被賦值為 REACT_ELEMENT_TYPE：

var REACT_ELEMENT_TYPE =    (typeof Symbol === 'function' && Symbol.for && Symbol.for('react.element')) ||    0xeac7;

可見， $$typeof是一個 Symbol類型的變量，這個變量可以防止 XSS。

如果你的服務器有一個漏洞，允許用戶存儲任意 JSON對象， 而客戶端代碼需要一個字符串，這可能會成為一個問題：

// JSON  let expectedTextButGotJSON = {    type: 'div',    props: {      dangerouslySetInnerHTML: {        __html: '/* put your exploit here */'      },    },  };  let message = { text: expectedTextButGotJSON };  <p>    {message.text}  </p>

JSON中不能存儲 Symbol類型的變量。

ReactElement.isValidElement函數用來判斷一個 React組件是否是有效的，下面是它的具體實現。

ReactElement.isValidElement = function (object) {    return typeof object === 'object' && object !== null && object.$$typeof === REACT_ELEMENT_TYPE;  };

可見 React渲染時會把沒有 $$typeof標識，以及規則校驗不通過的組件過濾掉。

當你的環境不支持 Symbol時， $$typeof被賦值為 0xeac7，至於為什麼， React開發者給出了答案：

0xeac7看起來有點像 React。

React組件的渲染流程是什麼？

  • 使用 React.createElement或 JSX編寫 React組件，實際上所有的 JSX代碼最後都會轉換成 React.createElement(...)， Babel幫助我們完成了這個轉換的過程。
  • createElement函數對 key和 ref等特殊的 props進行處理，並獲取 defaultProps對默認 props進行賦值，並且對傳入的孩子節點進行處理，最終構造成一個 ReactElement對象（所謂的虛擬 DOM）。
  • ReactDOM.render將生成好的虛擬 DOM渲染到指定容器上，其中採用了批處理、事務等機制並且對特定瀏覽器進行了性能優化，最終轉換為真實 DOM。

為什麼代碼中一定要引入React？

JSX只是為 React.createElement(component,props,...children)方法提供的語法糖。

所有的 JSX代碼最後都會轉換成 React.createElement(...)， Babel幫助我們完成了這個轉換的過程。

所以使用了 JSX的代碼都必須引入 React。

為什麼React組件首字母必須大寫？

babel在編譯時會判斷 JSX中組件的首字母，當首字母為小寫時，其被認定為原生 DOM標籤， createElement的第一個變量被編譯為字符串；當首字母為大寫時，其被認定為自定義組件， createElement的第一個變量被編譯為對象；

React在渲染真實Dom時做了哪些性能優化？

在 IE（8-11）和 Edge瀏覽器中，一個一個插入無子孫的節點，效率要遠高於插入一整個序列化完整的節點樹。

React通過 lazyTree，在 IE（8-11）和 Edge中進行單個節點依次渲染節點，而在其他瀏覽器中則首先將整個大的 DOM結構構建好，然後再整體插入容器。

並且，在單獨渲染節點時， React還考慮了 fragment等特殊節點，這些節點則不會一個一個插入渲染。

什麼是高階組件？如何實現？

高階組件可以看作 React對裝飾模式的一種實現，高階組件就是一個函數，且該函數接受一個組件作為參數，並返回一個新的組件。

高階組件（ HOC）是 React中的高級技術，用來重用組件邏輯。但高階組件本身並不是 ReactAPI。它只是一種模式，這種模式是由 React自身的組合性質必然產生的。

function visible(WrappedComponent) {    return class extends Component {      render() {        const { visible, ...props } = this.props;        if (visible === false) return null;        return <WrappedComponent {...props} />;      }    }  }

上面的代碼就是一個 HOC的簡單應用，函數接收一個組件作為參數，並返回一個新組件，新組建可以接收一個 visible props，根據 visible的值來判斷是否渲染Visible。

我們可以通過以下兩種方式實現高階組件：

屬性代理

函數返回一個我們自己定義的組件，然後在 render中返回要包裹的組件，這樣我們就可以代理所有傳入的 props，並且決定如何渲染，實際上 ，這種方式生成的高階組件就是原組件的父組件，上面的函數 visible就是一個 HOC屬性代理的實現方式。

function proxyHOC(WrappedComponent) {    return class extends Component {      render() {        return <WrappedComponent {...this.props} />;      }    }  }

對比原生組件增強的項：

  • 可操作所有傳入的 props
  • 可操作組件的生命周期
  • 可操作組件的 static方法
  • 獲取 refs

反向繼承

返回一個組件，繼承原組件，在 render中調用原組件的 render。由於繼承了原組件，能通過this訪問到原組件的 生命周期、props、state、render等，相比屬性代理它能操作更多的屬性。

function inheritHOC(WrappedComponent) {    return class extends WrappedComponent {      render() {        return super.render();      }    }  }

對比原生組件增強的項：

  • 可操作所有傳入的 props
  • 可操作組件的生命周期
  • 可操作組件的 static方法
  • 獲取 refs
  • 可操作 state
  • 可以渲染劫持

推薦閱讀：【React深入】從Mixin到HOC再到Hook

HOC在業務場景中有哪些實際應用場景？

HOC可以實現的功能：

  • 組合渲染
  • 條件渲染
  • 操作 props
  • 獲取 refs
  • 狀態管理
  • 操作 state
  • 渲染劫持

HOC在業務中的實際應用場景：

  • 日誌打點
  • 權限控制
  • 雙向綁定
  • 表單校驗

具體實現請參考我這篇文章：https://juejin.im/post/5cad39b3f265da03502b1c0a

高階組件(HOC)和Mixin的異同點是什麼？

Mixin和 HOC都可以用來解決 React的代碼復用問題。

圖片來源於網絡

  • Mixin 可能會相互依賴，相互耦合，不利於代碼維護
  • 不同的 Mixin中的方法可能會相互衝突
  • Mixin非常多時，組件是可以感知到的，甚至還要為其做相關處理，這樣會給代碼造成滾雪球式的複雜性

而 HOC的出現可以解決這些問題：

  • 高階組件就是一個沒有副作用的純函數，各個高階組件不會互相依賴耦合
  • 高階組件也有可能造成衝突，但我們可以在遵守約定的情況下避免這些行為
  • 高階組件並不關心數據使用的方式和原因，而被包裹的組件也不關心數據來自何處。高階組件的增加不會為原組件增加負擔

Hook有哪些優勢？

  • 減少狀態邏輯復用的風險

Hook和 Mixin在用法上有一定的相似之處，但是 Mixin引入的邏輯和狀態是可以相互覆蓋的，而多個 Hook之間互不影響，這讓我們不需要在把一部分精力放在防止避免邏輯復用的衝突上。在不遵守約定的情況下使用 HOC也有可能帶來一定衝突，比如 props覆蓋等等，使用 Hook則可以避免這些問題。

  • 避免地獄式嵌套

大量使用 HOC的情況下讓我們的代碼變得嵌套層級非常深，使用 HOC，我們可以實現扁平式的狀態邏輯復用，而避免了大量的組件嵌套。

  • 讓組件更容易理解

在使用 class組件構建我們的程序時，他們各自擁有自己的狀態，業務邏輯的複雜使這些組件變得越來越龐大，各個生命周期中會調用越來越多的邏輯，越來越難以維護。使用 Hook，可以讓你更大限度的將公用邏輯抽離，將一個組件分割成更小的函數，而不是強制基於生命周期方法進行分割。

  • 使用函數代替class

相比函數，編寫一個 class可能需要掌握更多的知識，需要注意的點也越多，比如 this指向、綁定事件等等。另外，計算機理解一個 class比理解一個函數更快。Hooks讓你可以在 classes之外使用更多 React的新特性。

下篇預告：

  • ReactDiff算法的策略是什麼？
  • React中 key的作用是什麼？
  • ReactFiber是什麼？為什麼要引入？
  • 為什麼推薦在 componentDidMount中發起網絡請求？
  • React代碼優化？
  • React組件設計要掌握哪些原則？
  • Redux的核心原理是什麼？
  • 什麼是 Redux中間件？
  • Reduxconnect函數的實現策略？
  • Mox的核心原理是什麼？
  • Redux和 Mobx的異同點，如何選擇？

VirMach 便宜 VPS

QNews

QNews