探討：Redux這么有名，只是我們不合適
當(dāng)聊到React狀態(tài)管理方案，很多人第一反應(yīng)是Redux。
Redux為什么這么有名，個(gè)人觀點(diǎn)，2個(gè)原因：
出現(xiàn)時(shí)間早，當(dāng)時(shí)社區(qū)還沒有更好的狀態(tài)管理解決方案
有React核心團(tuán)隊(duì)光環(huán)加持。Redux的作者「Dan」開發(fā)初版Redux后便加入React團(tuán)隊(duì)。另一位聯(lián)合作者「Andrew」也來自React核心團(tuán)隊(duì)
Dan
合適的出現(xiàn)時(shí)機(jī)加上大名氣，催生Redux相關(guān)生態(tài)在社區(qū)快速發(fā)展，成為很多前端團(tuán)隊(duì)標(biāo)配。
當(dāng)談?wù)摖顟B(tài)管理時(shí)，通常在談什么
當(dāng)談?wù)?strong>「狀態(tài)管理」時(shí)，一般會(huì)從「廣度」、「深度」兩個(gè)方面來。
廣度上，在其之后涌現(xiàn)的解決方案，似乎都在對(duì)標(biāo)Redux，提出自己獨(dú)到的解決方案。比如：
- 對(duì)標(biāo)Redux的單向數(shù)據(jù)流，Mobx使用雙向數(shù)據(jù)綁定
- 對(duì)標(biāo)Redux的「全局狀態(tài)」理念，recoil提出「原子狀態(tài)」理念
深度上，Redux社區(qū)不斷拓展，涌現(xiàn)了基于Redux的中間件，比如Redux-Saga。
在中間件之上，又涌現(xiàn)了更全面的解決方案，比如基于Redux-Saga的DVA。
除了這兩個(gè)緯度，還有其他視角么?
其實(shí)，我們可以從問題的本質(zhì)出發(fā)。
前端，需要哪些狀態(tài)?
從頁面交互角度看，狀態(tài)來源分為兩種：
- IO操作緩存的數(shù)據(jù)
- 用戶交互的中間狀態(tài)
IO操作緩存的數(shù)據(jù)
前端最常見的IO操作是從服務(wù)端請(qǐng)求數(shù)據(jù)。
如果沒使用「狀態(tài)管理」方案，常見方式是請(qǐng)求數(shù)據(jù)后保存在組件state中，如：
- function App() {
- const [data, updateData] = useState(null);
- useEffect(() => {
- fetchData('/api/user').then(data => updateData(data))
- }, [])
- // 處理data
- }
當(dāng)使用「狀態(tài)管理」方案如Redux，會(huì)將請(qǐng)求的數(shù)據(jù)序列化后保存在「全局狀態(tài)」中。
用戶交互的中間狀態(tài)
交互的中間狀態(tài)，比如isLoading、isOpen，同樣保存在組件內(nèi)部。
當(dāng)是可復(fù)用組件、或狀態(tài)需要跨組件層級(jí)傳遞，通常使用Context API。
再大范圍的狀態(tài)會(huì)使用「狀態(tài)管理」方案。
可以看到，不管對(duì)于「IO操作緩存的數(shù)據(jù)」還是「用戶交互的中間狀態(tài)」，常規(guī)方案是：一視同仁。
這就又回到了討論「廣度」(使用哪種狀態(tài))與「深度」(多深入的使用這種狀態(tài)管理方案)。
但事實(shí)上，這兩種狀態(tài)的特性是不同的。
處理緩存的狀態(tài)管理
對(duì)于第一種情況，不管是服務(wù)端請(qǐng)求、localStorage、indexedDB，本質(zhì)上說，都可以歸類為緩存。
所以，相比Redux等常規(guī)狀態(tài)管理方案，緩存處理方案可能更合適。
對(duì)于緩存，常見的需求是：
- 數(shù)據(jù)狀態(tài)，加載中?加載完成?發(fā)生錯(cuò)誤?
- 緩存失效后的更新
- 復(fù)用緩存數(shù)據(jù)
在React技術(shù)棧，SWR、react-query都是優(yōu)秀的解決方案。這里以SWR舉例：
對(duì)于剛才的例子：
- function App() {
- const [data, updateData] = useState(null);
- useEffect(() => {
- fetchData('/api/user').then(data => updateData(data))
- }, [])
- // 處理data
- }
SWR使用一個(gè)useSWR解決：
- function App() {
- const { data, error } = useSWR('/api/user', fetcher)
- if (error) return <div>failed to load</div>
- if (!data) return <div>loading...</div>
- return <div>hello {data.name}!</div>
- }
- 數(shù)據(jù)狀態(tài)：通過useSWR的返回值參數(shù)判斷請(qǐng)求狀態(tài)。比如!error && !data代表「請(qǐng)求中」。
- 緩存失效后的更新：SWR本身是stale-while-revalidate縮寫，一種基于RFC 5861[1]的緩存更新策略。
- 復(fù)用緩存數(shù)據(jù)：SWR會(huì)以請(qǐng)求url為key，請(qǐng)求對(duì)應(yīng)promise為value緩存數(shù)據(jù)，達(dá)到多個(gè)重復(fù)請(qǐng)求復(fù)用緩存的目的。
處理用戶交互的狀態(tài)管理
對(duì)于「用戶交互」產(chǎn)生的狀態(tài)管理需求，比如：全局modal的開關(guān)狀態(tài)，頁面皮膚切換。
我們可以按項(xiàng)目類型、復(fù)雜度選擇合適的狀態(tài)管理方案。
橫向來看，不同類型項(xiàng)目適合不同狀態(tài)管理：
- 前端邏輯很重的工具類項(xiàng)目(比如富文本編輯器)，需要完備的redo、ondo邏輯，Redux的「單向不可變數(shù)據(jù)流」是不二的選擇。
- 后臺(tái)管理系統(tǒng)，邏輯不復(fù)雜，但是繁瑣。則Mobx的「雙向數(shù)據(jù)綁定」開發(fā)效率可能更高。
縱向來看，我們需要考量項(xiàng)目的復(fù)雜度：
類似官網(wǎng)、邏輯不復(fù)雜的SPA、個(gè)人項(xiàng)目，「完全沒必要」使用額外的狀態(tài)管理方案。原生Context API是你最佳的選擇。
需要小團(tuán)隊(duì)合作的項(xiàng)目，復(fù)雜度不高的情況下，Context API就能滿足全部需要，只不過需要一點(diǎn)點(diǎn)寫法上的規(guī)范約束團(tuán)隊(duì)同學(xué)。這時(shí)候可以選擇Unstated[2]
- Unstated核心代碼只有40行，為項(xiàng)目帶來規(guī)范的狀態(tài)管理約束的同時(shí)不會(huì)引入額外的學(xué)習(xí)成本
只有對(duì)于更復(fù)雜的項(xiàng)目，才應(yīng)該考慮Redux、Mobx這類解決方案。
總結(jié)
對(duì)于「狀態(tài)管理」方案的選擇，我們可以遵循如下原則選擇：
區(qū)分「緩存」與「用戶交互」對(duì)應(yīng)的狀態(tài)，區(qū)別對(duì)待
對(duì)于「用戶交互」的狀態(tài)，根據(jù)項(xiàng)目類型、復(fù)雜度選擇合適方案
Redux雖好，可不要濫用哦～
參考資料
[1]RFC 5861:https://tools.ietf.org/html/rfc5861
[2]Unstated:https://github.com/jamiebuilds/unstated
