[React Hooks長文總結系列一]初出茅廬,狀態與副作用

寫在開頭

React Hooks在我的上一個項目中得到了充分的使用,對於這個項目來說,我們跳過傳統的類組件直接過渡到函數組件,確實是一個不小的挑戰。在項目開發過程中也發現項目中的其他小夥伴(包括我自己)有時候會存在使用不當的情況,因此對官方的幾個鉤子函數做一個較為全面的總結。

函數式組件出現的原因

為什麼會出現函數式組件,因為傳統的類組件確實有不少缺點:

  • 類組件中的 this 指向有點繞
  • 通過選項去組織程式碼,在組件比較大的時候會很痛苦,因為類組件天生分離,不符合內聚性原則
  • 組件復用不方便,尤其是 mixin,很容易帶來數據來源指向不清楚的問題

函數式組件居然「有狀態了」

我們知道,在過去,函數式組件被稱作「傻瓜組件」,因為它並不具有自身的狀態,通常被用來做一些渲染視圖的工作,即UI = render(props)。這是一個純粹的輸入輸出模型,無任何副作用。但是React Hooks的出現,讓函數式組件擁有自身的狀態成為了可能。

函數式組件在運行過程中會被調用很多次,假如我們將狀態保存在函數體裡面,毫無疑問是不可行的。因為函數是一種「用完即銷毀」的東西。

這正是是Hooks所做的事情:將一個函數組件的狀態保存在函數外面。準確來說,是這個函數組件對應的Hooks鏈表。當函數式組件需要用到該狀態的時候,通過Hooks這一鉤子將狀態從函數體外部「鉤進來」。

函數式組件其實也有「生命周期」

函數式組件的生命周期可以分為以下三部分:

初次渲染(first-render) —> 重渲染 (re-render) —> 銷毀(destroy

當我們第一次使用函數式組件的時候,會觸發初次渲染(first-render);若其 props 改變,就會調用該 render 函數,觸發重渲染(re-render)。

每一次的渲染,都是獨立的。這正是函數式組件的美妙之處。

那麼react如何決定要不要調用 render 函數來更新 UI 視圖呢?這取決於data有沒有更新。從整個組件樹來看,data指的是整個組件的state;從具體到某個功能組件來看,data也可以被認為是props和自身state的結合體。

render 的執行取決於 data 變化,而 data 中的 state 數據是保存在鏈表中的。

鏈表的特性是啥?就是每個元素都有一個next指針指向下一個元素,一環扣一環關聯起來。所以為什麼 hooks 不能用在條件判斷/循環/嵌套中,因為這些都不能保證每次渲染時讀取 hooks 鏈表的順序是完全一致的。尤其對於狀態讀取來說,讀取順序和初次渲染鏈表記錄的順序不一致,會直接導致一些 useState 鉤子讀取到錯誤的狀態值。

useSate,狀態保存之處

用法

const [count, setCount] = useState(0);

原理

首先,useState 會生成一個狀態和修改狀態的函數。這個狀態會保存在函數式組件外面,每次重渲染時,這一次渲染都會去外面把這個狀態鉤回來,讀取成常量並寫進該次渲染中。

通過調用修改狀態的函數,會觸發重渲染。到這裡我們總結:props 的改變和 setState 的調用,都會觸發 re-render

由於每次渲染都是獨立的,所以每次渲染都會讀到一個獨立的狀態值,這個狀態值,就是通過鉤子鉤到的 state 並讀取到的常量。

這就是所謂的capture value特性,每次的渲染都是獨立的,每次渲染的狀態其實都只是常量罷了。

深入本質

讓我們看深入一下本質,看看 useStatere-render 到底如何關聯起來:

  1. 函數式組件初次渲染,一個個的 useState 依次執行,生成hooks鏈表,裡面記錄了每個 state 的初始值和對應的 setter 函數
  2. 這個鏈表會掛在這個函數式組件的外面,可以被 useState 或相應 setter 訪問
  3. 當某個時刻調用了 setSetter,將會直接改變這個hooks鏈表
  4. hooks鏈表其實就是這個函數式組件的狀態表,它的改變等效於狀態改變,會引起函數式組件重渲染
  5. 這個函數式組件重渲染,執行到 useState 時,因為初次執行已經掛載過一個 hooks 鏈表了,這個時候就會直接讀取鏈表的相應值

這也就是為什麼叫useState,而不是createState

useRef,DOM訪問與外部狀態保存

useRef有啥用

useRef主要有兩個作用:

  • 用來訪問DOM;
  • 用來保存變數到當前函數式組件外部。

訪問DOM

我們先來看看前者怎麼用吧:

const inputRef = useRef(null);

const handleClick = () => {
  inputRef.current?.focus();
}

return (
  <input ref={inputRef} />
  <button onClick={handleClick}>點擊</button>
)

這樣就可以方便地訪問DOM節點。

保存可變值

前面我們提到,useState可以方便地保存狀態值,但是由於函數式組件的capture value特性,使得我們並不能以一種比較方便的形式獲取到更改後的狀態值。

const [num, setNum] = useState(0);

const increaseNum = () => {
    setNum(prev => prev + 1);
    console.log(num); // 列印的仍然是舊值,因為num在這一幀被常量化了
}

useRef將會創建一個ref對象,並把這個ref對象保存在函數式組件外部,這樣的好處在於:

  1. 獨立於capture value之外存儲,不用擔心獲得過時變數的問題;
  2. 可以同步修改狀態。

我們試驗如下:

const numRef = useRef(0);

const increaseNum = () => {
    numRef.current += 1;
    console.log(numRef.current); // 能獲取最新值
}

但是要注意⚠️:由於引用沒變,上述操作並不會引起函數式組件的重渲染。 這是一個很容易引起錯誤的地方!

useEffect,生命周期與觀察者

用法及建議

useEffect 的模型十分之簡潔,如下:

useEffect(effectFn, deps);

useEffect 可以模擬舊時代的三個生命周期:componentDidMountshouldComponentUpdatecomponentWillUnmount,相當於三個生命周期合併為一個 api。

所謂shouldComponentUpdate,其實就是去除deps依賴數組,如此一來這個副作用的 effectFn 會在首次渲染之後和每次重渲染之後執行,相當於模擬了 shouldComponentUpdate 這一生命周期,如下:

useEffect(() => {
  // xxx
});

而所謂componentDidMount,則是傳入一個空數組作為依賴,因為當有 deps 數組時,裡面 effectFn 是否執行取決於 deps 數組內的數據是否變化,空數組內無數據,所以對比自然也就無變化,使用如下:

useEffect(() => {
  // xxx
}, []);

componentWillUnmount,則是在effectFn中返回一個清除函數,如下:

useEffect(() => {
  // 執行副作用
  // ...
  return () => {
    // 清除上面的副作用
    // ...
  };
}, []);

此外我們應該始終遵循一個原則:那就是不要對 deps 依賴撒謊。否則會引發一系列 bug。當然編輯器的 linter 也不會允許我們這樣做,這一點非常關鍵。

原理

effectFn 就是當依賴變化時執行的副作用函數,這裡的副作用,並不是一個貶義詞,而是一個中性詞。

函數內部與外部發生的任何交互都算副作用,比如列印個日誌、開啟一個定時器,發一個請求,讀取全局變數等等等等。

好,現在這個 effectFn 可以返回一個清理函數cleanUp,用於清除這個副作用。典型的清理函數,如:clearIntervalclearTimeout,如:

useEffect(() => {
  const timer = setTimeout(() => console.log("over"), 1000);
  return () => clearTimout(timer);
});

useEffect 其實是每次渲染完成後都會執行,但是 effectFn 是否執行,就要看依賴有沒有變化了。執行 useEffect 的時候,會拿這次渲染的依賴跟上次渲染的對應依賴對比,如果沒變化,就不執行 effectFn,如果有變化,才執行 effectFn

如果連依賴都沒有,那 react 就認為每次都有變化,每次運行 useEffect 必運行 effectFn

useEffect 有典型的三大特點:

  • 會在每次渲染完成後才執行,不會阻塞渲染,從而提高性能
  • 在每次運行 effectFn 之前,要把前一次運行 effectFn 遺留的cleanUp函數執行掉(如果有的話)
  • 在組件銷毀時,會把最後一次運行effectFn 遺留的 cleanUp 函數執行掉。

deps 數組裡面的各個依賴與上次的依賴是否相同,需要通過Object.is來比較,比如:

Object.is(2222); // true

Object.is([], []); // false

這樣就會有一個隱患,當 deps 數組裡面的子元素為引用類型的時候,每次對比都會是false,從而執行effectFn。因為 Object.is 對比引用類型的時候,比較的是兩個指針是否指向堆記憶體中的同一個地址。

useEffect 的執行機制,是在初次渲染時,執行到 useEffect 就將內部的 effectFn 放到兩個地方:一個是 hooks 鏈表中,另外一個則是EffectList 隊列中。在渲染完成後,會依次執行 EffectList 裡面的 effectFn 集合。

所以,說白了,要不要 re-render,完全取決於鏈表裡面的東西有沒有變化。

細節

不同於 vue 裡面有async mounted,在 useEffect 裡面的 effectFn,應該始終堅持一個原則:要麼不返回,要麼返回一個 cleanUp 清除函數。像下面這樣寫是不行的:

// 錯誤的用法❌
useEffect(async () => {
  const response = await fetch("...");
  // ...
});

另外我們很容易發現:我們並不需要把 useState 返回的第二個 Setter 函數作為useEffect 的依賴。實際上,React 內部已經對 Setter 函數做了 Memoization 處理,因此每次渲染拿到的 Setter 函數都是完全一樣的,不需要把這個Setter函數放到deps數組裡面。

Tags: