Redux你是個(gè)好人，只是我們不合適

當(dāng)聊到React狀態(tài)管理方案，很多人第一反應(yīng)是Redux。

Redux為什么這么有名，個(gè)人觀點(diǎn)，2個(gè)原因：

1. 出現(xiàn)時(shí)間早，當(dāng)時(shí)社區(qū)還沒有更好的狀態(tài)管理解決方案

2. 有React核心團(tuán)隊(duì)光環(huán)加持。Redux的作者「Dan」開發(fā)初版Redux后便加入React團(tuán)隊(duì)。另一位聯(lián)合作者「Andrew」也來自React核心團(tuán)隊(duì)

合適的出現(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 style="color: rgb(145, 109, 213);">「狀態(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?loaddiv>
??if?(!data)?return?<div>loading...div>
??return?<div>hello?{data.name}!div>
}

讓我們來看SWR如何滿足如上三個(gè)需求：

• 數(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)管理」方案的選擇，我們可以遵循如下原則選擇：

1. 區(qū)分「緩存」與「用戶交互」對(duì)應(yīng)的狀態(tài)，區(qū)別對(duì)待

2. 對(duì)于「用戶交互」的狀態(tài)，根據(jù)項(xiàng)目類型、復(fù)雜度選擇合適方案

Redux雖好，可不要濫用哦～

參考資料