您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關怎樣解析React 狀態管理,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
社區中對 React 狀態管理方案的討論從未停息過,特別是自從 Hooks 誕生以來,各種“新穎”的狀態管理方案層出不窮,為了能更理性的看待這個問題,我們不妨把那些具體的框架/庫都拋在腦后,先來聊一聊,抽象層面上的“狀態管理”到底意味著什么。
?給一個抽象的東西下定義,是非常難的。例如我們在討論“書是什么”時,有些人可能會認為書就是紙張構成的一本印刷冊,可有的人認為手寫的一本稿子也算是書,而又有的人會認為電子產品中的一部文字的集合也算是廣義上的書。空談概念的定義是沒有什么意義的,很多概念的邊界是模糊的,與其浪費時間去爭出一個大家都認同的“邊界”,不如先找出一個粗略的定義,畢竟我們只是想借助對定義的探討,來反觀現實。
?
在我個人的觀念里,狀態管理主要有兩個方面的職能:
不知道這是不是 redux 或 mobx 的初衷,但這確實是我一直以來對狀態管理工具的“「痛點需求」”。
那么接下來,我們不妨在這兩個方面分別討論:
既然要共享數據,那么最簡單粗暴的方案就是直接做成「全局」性的(redux 也確實是這么做的),于是很多人的都漸漸形成了一種認知:React 應用中的狀態有兩種,一種是組件內部的(this.state / useState),另一種是全局的(redux)。但是,「內部狀態」的反義詞從來都不是「全局狀態」,而是「共享狀態」,全局只是共享的一種途徑罷了,并不能成為其本身。
目前來看,在組件間進行狀態的共享,有兩種比較可靠的途徑,其一就是剛剛提到的「全局狀態共享」,而另一種,也是我個人更加傾向的,是「局部狀態共享」。React 提供了非常簡潔易用的 Context API,用于在一個組件樹中共享數據,局部狀態共享的思路大致就是來自于此,在一個組件樹(而非整個應用)內進行數據共享。
可是這樣做又能有什么好處呢?
當然,反對的聲音也是存在的:
其實大家不難發現,局部狀態中“局部”是可大可小的,不論是小至包裹在一個組件外面(雖然不會有人真的這樣寫代碼),還是包裹到整個應用外面,都可以稱之為“局部”。因此準確的講,全局狀態只是局部狀態的一個「子集」、一個「特例」。局部狀態這種模式,只是把枷鎖解掉了,并非和全局狀態互斥。
我覺得狀態管理中真正的痛點在于“和數據相粘連的邏輯”如何組織,而 Hooks 提供了一整套完備的管理邏輯的方案,從狀態到副作用到性能優化到異步。
在以前,對于組件內部的狀態,邏輯組織能力是非常薄弱的,因此很多人求助于把狀態抽到外部(例如 redux),因為外部的狀態管理器中可以更好的組織業務邏輯。甚至更極端的,會試圖把整個應用狀態都放在 redux 中,而 React 組件內不允許保留狀態。
但是 Hooks 的誕生讓組件內部狀態的邏輯組織能力得到了大幅提升,我覺得是完全不輸甚至更強于 flux 模式的。如果我們能夠把組件內部狀態和共享狀態全部都用 Hooks 進行組織,那我們就再也不需要對一份數據該存放在哪里而感到糾結了,因為我們只需要關心一點:這份數據被誰需要了?是只有這個組件自己,還是多個組件之間?
Hooks 不是為了狀態管理而生的,但卻可以深刻地改變整個生態。就像智能手機不是為了購物而生的,但卻可以顛覆人們的消費和生活方式。
狀態管理之所以一直以來被人們特意強調,一定程度上恰恰是因為它的格格不入,需要被人們去單獨學習和特別注意。如果大膽猜測一下的話,我會覺得在不久的將來,我們之前熱衷于討論的“狀態管理”這個詞,會更多的意味著“狀態共享”,甚至于銷聲匿跡。一個 React 應用的狀態構成也會從“組件內的狀態 + 狀態管理器中的狀態”變成“組件內的狀態+組件間共享的狀態”。
看完上述內容,你們對怎樣解析React 狀態管理有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。