React 面試籌備不徹底指南

開篇

咱們今天主要講解的內容就是關於 React 面試相關的，我相信你在面試中，也會被問到各類各樣的很是多的問題，我舉幾個例子你看看，在本身內心想想，你會怎麼回答？

爲何 React 選擇使用 JSX ？

JSX 映射虛擬 Dom 的原理

setState 究竟是同步的，仍是異步的？

如何面向組件跨層級通訊？

聊聊 Redux 和 Vuex 的設計思想有什麼不一樣和相同之處？

React 事件與 DOM 事件有什麼區別？

爲何 React 要加入 Hook ?

說一下你對 diff 算法的理解

談一談 React 的數據流管理

上面這些問題，很是的常見，除此以外，相似的問題還有不少，一個一個的講，根本講不完，也不可能每一個都講到；固然網上有不少面試寶典，各類典型面試題都會涉及到，你們可能最近都在準備面試，迫切想要知道這些問題的答案，這也是你們最容易陷入的一個職場誤區，對本身的現狀不滿，想要跳槽漲薪，又缺少平常積累，面試前瘋狂的刷一些面試題，應付當前的幾場面試，1-2年後，又一次輪迴，忽略平常的積累和總結，總想着臨陣才磨槍，卻是會有些閃亮，但永遠不會鋒利；

解這些題，並非今天的重點，我想給你的，是一套方法論，是解決這一類問題的通用方法：

整體來講分爲三個部分：

1：對 React 框架的全面瞭解；

這須要你在平常的開發中，不斷積累總結，有意識的主動探索和思考，今天我就分享一下我本身的總計和思考，沒有絕對的正確，但我相信必定對你有所啓發；

2：面試問題解答的思路和技巧；

我對 React 的使用有不少經驗了，寫過幾個項目，也有了本身的思考和理解，可是，在面試的時候，是否是又這樣的狀況呢？知道這個知識點，但不能準確完整地表達、不知道該如何描述，但當面試官提起的時候，又能記憶起來，說，「對對對，就是那個，我剛確實不知道該怎麼講」。肚子裏有東西，卻在嘴上吃了大虧？

3：經典面試題案例解答

前面介紹了這些思路和技巧，那麼如何應用到具體的問題解答上呢？咱們使用幾個比較典型的面試題案例來解答；

如何理解 React 框架？

先從前端框架的發展來看，以前是沒有前端框架這樣的工具的，可是前端的業務量愈來愈大，頁面變得愈來愈複雜，前端的工程也開始龐大了起來，如何組織代碼結構，如何有效提高複用率，開始成爲大型前端項目迫切須要解決的問題。2009年，帶有大量的 Java 開發思想的 AngularJS 問世：angular.cn/ ；

AngularJS 提供了一攬子全家桶解決方案，從底層開始深度封裝，向上提供了路由、雙向綁定、指令、組件等框架特性。如今也同樣，你須要的，它所有都有，可是學習成本過高了，各類全新概念目不暇接，讓咱們一度懷疑我寫的不是 前端代碼，而是 AngularJS 代碼；

而 React 的思惟模式是徹底不一樣的，概念也極爲簡單：「一切皆組件」，而 組件 == Function / Class ；

官方手冊 react.docschina.org/ 的第一句話就是 「 用於構建用戶界面的 JavaScript 庫 」 ；

從各自的 「一句話」 介紹中，咱們也能夠看到，React 把本身定義爲 「 JavaScript 庫 」，而 AngularJS 纔是 「框架」，雖然咱們常常說 「React 框架」，可是人家歷來都說本身是個 庫 的，框架這個名字，是咱們強加給人家的，不要以爲這僅僅是一個稱呼而已，其實從必定程度上，確實誤導了不少人，尤爲是新手，甚至有過幾年工做經驗的老油條，也在誤會着 React ，那這個誤會是怎麼來的呢？

其實在 React 中，只有組件，沒有頁面，沒有控制器，也沒用模型，在 AngularJS 框架中這些習覺得常的概念，React 通通沒有。沒有頁面？那就用組件組合生成一個頁面，沒有控制器，那就用組件充當控制器。就像搭建樂高玩具同樣，組件就是組成整個應用惟一零部件。

可是從實際編碼上來說，能夠是純函數組件或者類組件，也可能在函數中產生影響 UI 生成的反作用，好比直接操做 DOM 或者綁定事件等。在 React 中咱們只須要關心兩件事：數據與組件。React 負責組件開發者負責數據；這也就是我所理解的 MVVM 框架的概念；程序員負責 MV 的處理，React 負責 VM 的構建；那麼對於 React 自己來講就只負責構建視圖的工做了，所以在適用場景上遠比傳統框架更爲普遍，你可使用 React-dom 開發 PC 網頁或者移動端網頁；使用 React-Native，開發 iOS 與 Android 應用；還有 React-360 能夠開發 VR 應用；甚至可使用 React-ink 開發命令行應用。

固然 React 也有缺點， 因爲 React 並非一個典型的框架，好比路由、狀態管理這樣的功能，React 團隊更但願交給社區來解決。因此致使在技術選型與學習使用上有比較高的成本。但也正由於社區蓬勃發展，非官方的一攬子解決方案仍是有的，好比 Redux、 React Router 、組件庫 Antd 、長列表 React-window 等填補了生態位的缺失。而平常開發應用，這些總要去學習使用，而更多的人，將這些社區的方案看成了 React 的一部分，所以就以爲 React 是個 「框架」 了，這樣的說法雖然不許確，但其實也不必必須糾正，由於 「React+社區方案」 的組合，確實是一個框架應該有的樣子；也正爲如此，React 成了一個使用者上限與下限差距極大的框架， 而社區方案的組合和應用能力，也成爲了進大廠的必考內容；

雖然我這裏在必定程度上拿 AngularJS 和 React 再作對比，可是請注意，若是你以爲 AngularJS 無懈可擊宇宙無敵吊炸天，那必定是你說的對，而若是你以爲 Vue 無懈可擊宇宙無敵吊炸天，那固然也是你說的對；

對於各類框架的對比調查也有不少，正巧，前一段時間 stateofjs2020 剛剛發佈，你們感興趣能夠去看看一下；

stateofjs 2020 年度前端開發者調查報告：2020.stateofjs.com/zh-Hans/tec…

報告顯示，React 的佔用量明顯高於 Vue 和 AngularJS , 80%的調查者使用英語語種，說白了，就是歐美方面的調查，並不能說明國內的狀況，而 react 在 Github 的 star 是 164K，Vue2.x 在 Github 的star 是 180K，你們也能夠本身去看看，github.com/facebook/re… NPM 的下載數；

其實，我想說的是，不要作那個框架好的對比， Vue 和 React 或者AngularJS 或者其餘 MVVM 框架，都是很是優秀且值得學習的，也都有各自的優勢和缺點；與其在網絡上撕逼，不如認真學習學習，奉勸各位，井蛙不可語海，夏蟲不可語冰；

總結一下：

React 本質上就是一個構建用戶界面的 JavaScript 庫，經過組件化的方式解決視圖層開發複用的問題；

組件化的優點在於視圖的拆分與模塊複用，能夠更容易作到高內聚低耦合，

通用性更強，一次學習，隨處編寫。好比 React Native，React 360 等， 這裏主要靠虛擬 DOM 來保證明現。

這使得 React 的適用範圍變得足夠廣

但做爲一個視圖層的框架，React 的劣勢也十分明顯。它並無提供傳統框架的一整套完整解決方案，在開發大型前端應用時，須要向社區尋找並整合解決方案。雖然必定程度上促進了社區的繁榮，但也爲開發者在技術選型和學習適用上形成了必定的成本。

爲何 React 選擇使用 JSX ？

這裏問 「爲何 React 選擇使用 JSX ？」，其引伸含義是 「爲何不用 A、B、C？」

舉個例子，你二嬸兒給你介紹了倆對象，一個溫婉可愛小鳥依人，一個上得廳堂下得廚房，結果你依然選擇單身不找對象，你二嬸兒就問你爲啥呀？你若是說單身有多好，你必定會被懟？怎麼回答呢？溫柔的太粘人，賢惠的長得醜；而後在說單身有多好；

套路就是，之因此選擇x，是由於 y 和 z 很差，而後再說明 x 怎麼怎麼好；

可是，放到技術上，要答好這個問題，爲何 React 選擇使用 JSX ？你須要先了解 React 可選的其餘解決方案，而後才能知道有什麼很差的地方；其實相關方案有不少，最直觀的就是 模板，Vue 和 AngularJS 都選擇使用模板方案，而 React 團隊認爲引入模板是一種不佳的實現，你以爲模板很差嗎？我以爲還行啊，你以爲醜，我以爲美若天仙啊；這不只僅是眼光不一樣，更多的是基於不一樣的角度來思考，再結合自身的特性作出的選擇，React 團隊之因此認爲模板不是最佳實現，緣由在於，React 團隊認爲模板分離了技術棧，分散了組件內的關注點，其次模板還會引入更多的概念，相似模板語法、模板指令等，JSX 並不會引入太多新的概念，它仍然是 JavaScript，就連條件表達式和循環都仍然是 JavaScript 的方式。更具備可讀性，更貼近 HTML。而對於關注點分離這個問題，咱們能夠用兩段代碼來展現：

上面的兩端代碼分別使用了 React 及 Vue 的單文件組件來呈現，在 React 中，聲明的 Users 類就是一個組件，所有的 方法、數據及 UI 視圖，能夠以任意的方式呈現， 而在 Vue 的組件中，很明確的要將 UI 部分寫入 template 模板標籤中(固然還能夠在 component 方法中使用 template 字符串 )，功能及數據相關的 要寫入 script 標籤中，而相對應的數據展現能力，則須要使用模板指令進行呈現，如：@click 指令綁定點擊事件，v-for 循環遍歷數據及樣式結構；而在 JSX 中，所有都是 JavaScript 的，沒什麼規矩可言；

兩種方式各有不一樣，我本身也說不上喜歡那個，可是，站在技術角度，我比較喜歡 JSX ，而站在產品研發角度，我更傾向於 Vue 的模板方式；

就相似我媽作飯超級好吃，選媳婦就選小鳥依人的，可是我媽作飯根本無法吃，我仍是選下得廚房的媳婦要好一些。畢竟程序員是不須要愛情的……

若是你想解答的更加完善，還能夠加入其餘方式進行闡述，好比 模板字符、JXON；篇幅有限，我這裏就不展開說了；

對於 爲何 React 選擇使用 JSX ？到這裏，咱們其實已經說的差很少了，可是，總以爲少點什麼，那就是對於 JSX 自己的闡述還不到位；

那麼 JSX 究竟是什麼呢？

咱們知道它不是字符串也不是 HTML，是一個 JavaScript 的語法擴展，用於描述組件 UI 。 實際上，官方手冊上早就說的很清楚了，JSX 僅僅只是 React.createElement(component, props, ...children) 函數的語法糖，最終會被編譯爲 React.createElement() 函數調用返回稱爲 「React 元素」 的普通 JavaScript 對象。

咱們用一段簡單的代碼展現一下，具體來看看：

上面的代碼中，咱們直接將 JSX 的內容打印到控制檯，效果以下：

那麼，從 JSX 到控制檯打印的結果中，到底發生了什麼？手冊上說 JSX 僅僅只是 React.createElement() 函數的語法糖，那麼問題就來了，React.createElement 到底作了什麼呢？ 走，翻一下源碼看看就知道了

對於這段代碼，並無什麼高大上的騷操做，在這裏，我大體說一下，作了什麼事情：

React. createElement 二次處理 key、ref、self、 source 四個屬性值；

遍歷 config，篩出能夠提進 props 裏的屬性；

提取子元素，推入 childArray（也即 props.children）數組；

格式化 defaultProps；

結合以上數據做爲入參，發起 ReactElement調用；

那麼接着讓咱們進入到 ReactElement 方法，繼續查看 到底作了什麼事情：

而這些代碼就更有意思了，就是把傳入的內容，組裝進 element 對象並返回，注意，這個 element 實際就是咱們以前打印到控制檯的那個對象，其實這個對象就是咱們常說的 」虛擬 DOM 「 ，而從虛擬 DOM 到真實 DOM 的工做，就是咱們調用 ReactDOM.render 方法去作的事情了，這裏我們就再也不繼續分析了；

來波小總結

爲何 React 選擇使用 JSX ？本質就是蘿蔔青菜各有所愛，React 團隊認爲 JSX 不會引入太多新的概念，編碼更純淨，更具備可讀性，更貼近 HTML，而對於 JSX 自己來講，是 React.createElement() 函數的語法糖，createElement() 對參數進行拆解後，發起 ReactElement 調用生成虛擬 DOM 對象；