怎樣解析React 狀態(tài)管理

狀態(tài)管理的本質(zhì)是什么

社區(qū)中對(duì) React 狀態(tài)管理方案的討論從未停息過，特別是自從 Hooks 誕生以來，各種“新穎”的狀態(tài)管理方案層出不窮，為了能更理性的看待這個(gè)問題，我們不妨把那些具體的框架/庫(kù)都拋在腦后，先來聊一聊，抽象層面上的“狀態(tài)管理”到底意味著什么。

?  

給一個(gè)抽象的東西下定義，是非常難的。例如我們?cè)谟懻摗皶鞘裁础睍r(shí)，有些人可能會(huì)認(rèn)為書就是紙張構(gòu)成的一本印刷冊(cè)，可有的人認(rèn)為手寫的一本稿子也算是書，而又有的人會(huì)認(rèn)為電子產(chǎn)品中的一部文字的集合也算是廣義上的書?？照劯拍畹亩x是沒有什么意義的，很多概念的邊界是模糊的，與其浪費(fèi)時(shí)間去爭(zhēng)出一個(gè)大家都認(rèn)同的“邊界”，不如先找出一個(gè)粗略的定義，畢竟我們只是想借助對(duì)定義的探討，來反觀現(xiàn)實(shí)。

?  

在我個(gè)人的觀念里，狀態(tài)管理主要有兩個(gè)方面的職能：

1. 「數(shù)據(jù)的共享」    
   在 React 應(yīng)用中，在組件間優(yōu)雅的共享一些數(shù)據(jù)并非易事，而各種狀態(tài)管理工具都給出了自己對(duì)“數(shù)據(jù)共享”的標(biāo)準(zhǔn)方案
2. 「邏輯的組織」    
   狀態(tài)不單單是數(shù)據(jù)項(xiàng)的堆砌，更重要的是把各項(xiàng)數(shù)據(jù)之間的邏輯、數(shù)據(jù)與其他系統(tǒng)模塊之間的互動(dòng)邏輯進(jìn)行組織，例如 A 需要在用戶點(diǎn)擊按鈕時(shí)發(fā)生變化，而 B 又需要在 A 變化時(shí)跟著變化（可能是同步的也可能是異步的）

不知道這是不是 redux 或 mobx 的初衷，但這確實(shí)是我一直以來對(duì)狀態(tài)管理工具的“「痛點(diǎn)需求」”。
那么接下來，我們不妨在這兩個(gè)方面分別討論：

數(shù)據(jù)共享：局部還是全局？

既然要共享數(shù)據(jù)，那么最簡(jiǎn)單粗暴的方案就是直接做成「全局」性的（redux 也確實(shí)是這么做的），于是很多人的都漸漸形成了一種認(rèn)知：React 應(yīng)用中的狀態(tài)有兩種，一種是組件內(nèi)部的（this.state / useState），另一種是全局的（redux）。但是，「內(nèi)部狀態(tài)」的反義詞從來都不是「全局狀態(tài)」，而是「共享狀態(tài)」，全局只是共享的一種途徑罷了，并不能成為其本身。
目前來看，在組件間進(jìn)行狀態(tài)的共享，有兩種比較可靠的途徑，其一就是剛剛提到的「全局狀態(tài)共享」，而另一種，也是我個(gè)人更加傾向的，是「局部狀態(tài)共享」。React 提供了非常簡(jiǎn)潔易用的 Context API，用于在一個(gè)組件樹中共享數(shù)據(jù)，局部狀態(tài)共享的思路大致就是來自于此，在一個(gè)組件樹（而非整個(gè)應(yīng)用）內(nèi)進(jìn)行數(shù)據(jù)共享。
可是這樣做又能有什么好處呢？

1. 「自治」    
   一個(gè)組件樹可以完成邏輯的封閉，減輕對(duì)全局的依賴和干擾，甚至還對(duì)組件的封裝非常有益
2. 「多例」    
   局部共享的狀態(tài)也可以像組件（樹）一樣擁有多例的能力，可以打破全局單例對(duì)很多邏輯場(chǎng)景的限制
3. 「生命周期」    
   局部狀態(tài)跟隨組件樹創(chuàng)建和銷毀，干凈而且易于維護(hù)，最常見的場(chǎng)景是讓共享狀態(tài)的生命周期和頁面的生命周期保持同步

當(dāng)然，反對(duì)的聲音也是存在的：

1. 「不夠規(guī)范」    
   局部狀態(tài)滿天飛，容易讓邏輯變亂，排查問題也會(huì)變得非常困難
2. 「需要一定的認(rèn)知成本」    
   局部狀態(tài)不如全局狀態(tài)那么直觀，雖然靈活但也增加了使用成本

其實(shí)大家不難發(fā)現(xiàn)，局部狀態(tài)中“局部”是可大可小的，不論是小至包裹在一個(gè)組件外面（雖然不會(huì)有人真的這樣寫代碼），還是包裹到整個(gè)應(yīng)用外面，都可以稱之為“局部”。因此準(zhǔn)確的講，全局狀態(tài)只是局部狀態(tài)的一個(gè)「子集」、一個(gè)「特例」。局部狀態(tài)這種模式，只是把枷鎖解掉了，并非和全局狀態(tài)互斥。

邏輯組織：Hooks 究竟改變了什么？

我覺得狀態(tài)管理中真正的痛點(diǎn)在于“和數(shù)據(jù)相粘連的邏輯”如何組織，而 Hooks 提供了一整套完備的管理邏輯的方案，從狀態(tài)到副作用到性能優(yōu)化到異步。
在以前，對(duì)于組件內(nèi)部的狀態(tài)，邏輯組織能力是非常薄弱的，因此很多人求助于把狀態(tài)抽到外部（例如 redux），因?yàn)橥獠康臓顟B(tài)管理器中可以更好的組織業(yè)務(wù)邏輯。甚至更極端的，會(huì)試圖把整個(gè)應(yīng)用狀態(tài)都放在 redux 中，而 React 組件內(nèi)不允許保留狀態(tài)。
但是 Hooks 的誕生讓組件內(nèi)部狀態(tài)的邏輯組織能力得到了大幅提升，我覺得是完全不輸甚至更強(qiáng)于 flux 模式的。如果我們能夠把組件內(nèi)部狀態(tài)和共享狀態(tài)全部都用 Hooks 進(jìn)行組織，那我們就再也不需要對(duì)一份數(shù)據(jù)該存放在哪里而感到糾結(jié)了，因?yàn)槲覀冎恍枰P(guān)心一點(diǎn)：這份數(shù)據(jù)被誰需要了？是只有這個(gè)組件自己，還是多個(gè)組件之間？
Hooks 不是為了狀態(tài)管理而生的，但卻可以深刻地改變整個(gè)生態(tài)。就像智能手機(jī)不是為了購(gòu)物而生的，但卻可以顛覆人們的消費(fèi)和生活方式。

我們真的需要狀態(tài)管理么

狀態(tài)管理之所以一直以來被人們特意強(qiáng)調(diào)，一定程度上恰恰是因?yàn)樗母窀癫蝗?，需要被人們?nèi)为?dú)學(xué)習(xí)和特別注意。如果大膽猜測(cè)一下的話，我會(huì)覺得在不久的將來，我們之前熱衷于討論的“狀態(tài)管理”這個(gè)詞，會(huì)更多的意味著“狀態(tài)共享”，甚至于銷聲匿跡。一個(gè) React 應(yīng)用的狀態(tài)構(gòu)成也會(huì)從“組件內(nèi)的狀態(tài) + 狀態(tài)管理器中的狀態(tài)”變成“組件內(nèi)的狀態(tài)+組件間共享的狀態(tài)”。