[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
特性,每次的渲染都是獨立的,每次渲染的狀態其實都只是常量罷了。
深入本質
讓我們看深入一下本質,看看 useState
和 re-render
到底如何關聯起來:
- 函數式組件初次渲染,一個個的
useState
依次執行,生成hooks鏈表,裡面記錄了每個state
的初始值和對應的setter
函數 - 這個鏈表會掛在這個函數式組件的外面,可以被
useState
或相應setter
訪問 - 當某個時刻調用了
setSetter
,將會直接改變這個hooks鏈表 - hooks鏈表其實就是這個函數式組件的狀態表,它的改變等效於狀態改變,會引起函數式組件重渲染
- 這個函數式組件重渲染,執行到
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
對象保存在函數式組件外部,這樣的好處在於:
- 獨立於
capture value
之外存儲,不用擔心獲得過時變數的問題; - 可以同步修改狀態。
我們試驗如下:
const numRef = useRef(0);
const increaseNum = () => {
numRef.current += 1;
console.log(numRef.current); // 能獲取最新值
}
但是要注意⚠️:由於引用沒變,上述操作並不會引起函數式組件的重渲染。 這是一個很容易引起錯誤的地方!
useEffect,生命周期與觀察者
用法及建議
useEffect
的模型十分之簡潔,如下:
useEffect(effectFn, deps);
useEffect 可以模擬舊時代的三個生命周期:componentDidMount
、shouldComponentUpdate
、componentWillUnmount
,相當於三個生命周期合併為一個 api。
所謂shouldComponentUpdate
,其實就是去除deps
依賴數組,如此一來這個副作用的 effectFn
會在首次渲染之後和每次重渲染之後執行,相當於模擬了 shouldComponentUpdate
這一生命周期,如下:
useEffect(() => {
// xxx
});
而所謂componentDidMount
,則是傳入一個空數組作為依賴,因為當有 deps
數組時,裡面 effectFn
是否執行取決於 deps
數組內的數據是否變化,空數組內無數據,所以對比自然也就無變化,使用如下:
useEffect(() => {
// xxx
}, []);
而componentWillUnmount
,則是在effectFn
中返回一個清除函數,如下:
useEffect(() => {
// 執行副作用
// ...
return () => {
// 清除上面的副作用
// ...
};
}, []);
此外我們應該始終遵循一個原則:那就是不要對 deps 依賴撒謊。否則會引發一系列 bug。當然編輯器的 linter 也不會允許我們這樣做,這一點非常關鍵。
原理
effectFn
就是當依賴變化時執行的副作用函數,這裡的副作用,並不是一個貶義詞,而是一個中性詞。
函數內部與外部發生的任何交互都算副作用,比如列印個日誌、開啟一個定時器,發一個請求,讀取全局變數等等等等。
好,現在這個 effectFn
可以返回一個清理函數cleanUp
,用於清除這個副作用。典型的清理函數,如:clearInterval
、clearTimeout
,如:
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(22, 22); // 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
數組裡面。