日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

為什么要學習 React Hooks 原理

在霍爾果斯等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供成都網(wǎng)站設計、成都網(wǎng)站建設 網(wǎng)站設計制作定制網(wǎng)站制作,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,成都品牌網(wǎng)站建設,營銷型網(wǎng)站建設,成都外貿網(wǎng)站制作,霍爾果斯網(wǎng)站建設費用合理。

首先，功利點來說：目前前端框架三分天下：React、Vue、Angular，而 React 自從 v16.8.0 版本正式推出 React Hooks 概念后，風勢已經從原來的類組件猛地轉向函數(shù)組件，這是一個在設計模式、心智模型層次，且非常近期的革新，因此只要是你談到自己會 React ，就一定會在面試中被問到 React Hooks 的原理。

再者，從實際角度出發(fā)，了解 React Hooks 原理對我們日常開發(fā)調試都有莫大的好處；我們可以認識到 React Hooks 其實也并不是什么黑魔法，我們在開發(fā)中碰到的奇奇怪怪的問題，只不過是我們還沒有掌握 React Hooks 導致的，也不需要用一些 tricky 的方法來解決。

useState / useReducer

useState 和 useReducer 都是關于狀態(tài)值的提取和更新，從本質上來說沒有區(qū)別，從實現(xiàn)上，可以說 useState 是 useReducer 的一個簡化版，其背后用的都是同一套邏輯。

React Hooks 如何保存狀態(tài)

React 官方文檔中有提到，React Hooks 保存狀態(tài)的位置其實與類組件的一致；翻看源碼后，我發(fā)現(xiàn)這樣的說法沒錯，但又不全面：

•  兩者的狀態(tài)值都被掛載在組件實例對象FiberNode的memoizedState屬性中。
•  兩者保存狀態(tài)值的數(shù)據(jù)結構完全不同；類組件是直接把 state 屬性中掛載的這個開發(fā)者自定義的對象給保存到memoizedState屬性中；而 React Hooks 是用鏈表來保存狀態(tài)的，memoizedState屬性保存的實際上是這個鏈表的頭指針。

下面我們來看看這個鏈表的節(jié)點是什么樣的 —— Hook 對象：

 
 
 
 
  
  
  
  
// react-reconciler/src/ReactFiberHooks.js  
  
  
  
  
export type Hook = {  
  
  
  
  
  memoizedState: any, // 最新的狀態(tài)值  
  
  
  
  
  baseState: any, // 初始狀態(tài)值，如`useState(0)`，則初始值為0  
  
  
  
  
  baseUpdate: Update | null,  
  
  
  
  
  queue: UpdateQueue | null, // 臨時保存對狀態(tài)值的操作，更準確來說是一個鏈表數(shù)據(jù)結構中的一個指針  
  
  
  
  
  next: Hook | null,  // 指向下一個鏈表節(jié)點  
  
  
  
  
}; 
 
 
 

官方文檔一直強調 React Hooks 的調用只能放在函數(shù)組件/自定義 Hooks 函數(shù)體的頂層，這是因為我們只能通過 Hooks 調用的順序來與實際保存的數(shù)據(jù)結構來關聯(lián)：

PS：雖然上面一致都是以 useState 和 useReducer 來作為例子說明，但實際上所有 React Hooks 都是用這種鏈表的方式來保存的。

React Hooks 如何更新狀態(tài)

熟悉 useState API 的話，我們都知道怎么去更新狀態(tài)：

 
 
 
 
  
  
  
  
const [name, setName] = useState('')  
  
  
  
  
setName('張三') 
 
 
 

那么，由 useState 返回的這個用來更新狀態(tài)的函數(shù)（下文稱為 dispatcher），運行的原理是怎么樣的呢？

當我們在每次調用 dispatcher 時，并不會立刻對狀態(tài)值進行修改（對的，狀態(tài)值的更新是異步的），而是創(chuàng)建一條修改操作——在對應 Hook 對象的queue屬性掛載的鏈表上加一個新節(jié)點：

在下次執(zhí)行函數(shù)組件，再次調用 useState 時， React 才會根據(jù)每個 Hook 上掛載的更新操作鏈表來計算最新的狀態(tài)值。你也許會好奇，為什么要把更新操作都保存起來呢，只保存最新的一次更新操作不就行了嗎？你會這樣想，大概是忘了 useState 支持這樣的語法了吧：

 
 
 
 
  
  
  
  
const [name, setName] = useState('')  
  
  
  
  
setName(name => name + 'a')  
  
  
  
  
setName(name => name + 'b')  
  
  
  
  
setName(name => name + 'c')  
  
  
  
  
// 下次執(zhí)行時就可以得到 name 的最新狀態(tài)值為'abc'啦 
 
 
 

useEffect

useEffect 的保存方式與 useState / useReducer 類似，也是以鏈表的形式掛載在FiberNode.updateQueue中。

下面我們按 mount 和 update 這兩個組件生命周期來闡述 useEffect 的執(zhí)行原理：

mount 階段：mountEffect

1.  根據(jù)函數(shù)組件函數(shù)體中依次調用的 useEffect 語句，構建成一個鏈表并掛載在FiberNode.updateQueue中，鏈表節(jié)點的數(shù)據(jù)結構為： 

 
 
 
 
  
  
  
  
 const effect: Effect = {  
  
  
  
  
    tag, // 用來標識依賴項有沒有變動  
  
  
  
  
    create, // 用戶使用useEffect傳入的函數(shù)體  
  
  
  
  
    destroy, // 上述函數(shù)體執(zhí)行后生成的用來清除副作用的函數(shù)  
  
  
  
  
    deps, // 依賴項列表  
  
  
  
  
    next: (null: any),  
  
  
  
  
}; 
 
 
 

1.  組件完成渲染后，遍歷鏈表執(zhí)行。

update 階段：updateEffect

1.  同樣在依次調用 useEffect 語句時，判斷此時傳入的依賴列表，與鏈表節(jié)點Effect.deps中保存的是否一致（基本數(shù)據(jù)類型的值是否相同；對象的引用是否相同），如果一致，則在Effect.tag標記上NoHookEffect。

執(zhí)行階段

在每次組件渲染完成后，就會進入 useEffect 的執(zhí)行階段：function commitHookEffectList()：

1.  遍歷鏈表
2.  如果遇到Effect.tag被標記上NoHookEffect的節(jié)點則跳過。
3.  如果Effect.destroy為函數(shù)類型，則需要執(zhí)行該清除副作用的函數(shù)（至于這Effect.destroy是從哪里來的，下面馬上說到）
4.  執(zhí)行Effect.create，并將執(zhí)行結果保存到Effect.destroy（如果開發(fā)者沒有配置return，那得到的自然是undefined了，也就是說，開發(fā)者認為對于當前 useEffect 代碼段，不存在需要清除的副作用）；注意由于閉包的緣故，Effect.destroy實際上可以訪問到本次Effect.create函數(shù)作用域內的變量。

我們重點請注意到：是先清除上一輪的副作用，然后再執(zhí)行本輪的 effect 的。

其它 React Hooks Api

其它的的 React Hooks Api ，其實也差不多是這樣的原理：用鏈表數(shù)據(jù)結構來做全局狀態(tài)保持；判斷依賴項決定是否要更新狀態(tài)等等，這里不再累述。

總結

本文用比較精煉的語言來闡述了 React Hooks 的原理，目的是讓讀者有一個感性的認識，也便于應付面試；但實際上 React Hooks 還有非常多的實現(xiàn)細節(jié)，有興趣請閱讀源碼，入口在此。

當前標題：前端面試必考題：React Hooks原理剖析
分享網(wǎng)址：http://www.dlmjj.cn/article/djjopso.html