前端狀態(tài)管理是很多流行框架統(tǒng)一在做的事，翻開官方文檔都有相關(guān)的介紹。React框架有Redux，Vue框架有Vuex。但是官方文檔并不是萬能的解藥，依舊沒有從本質(zhì)上解決大家理解這個(gè)東西的疑惑。

我習(xí)慣將一些復(fù)雜的知識(shí)點(diǎn)結(jié)合Web發(fā)展過程總結(jié)一些自己的看法，以下是我理解的所謂狀態(tài)管理，如有偏頗僅代表我個(gè)人見解，歡迎吐槽。

我們先假設(shè)一個(gè)背景，就是以下所有的故事背景都發(fā)生在沒有電子設(shè)備和即時(shí)聊天工具的年代。

場景一

我和老王是好朋友，每天下班我們都會(huì)坐在公司樓下的酒館聊天。每天的內(nèi)容五花八門，后來我們每天都討論技術(shù)相關(guān)的東西，不亦樂乎。有天我們聊得內(nèi)容很多，第二天突然想起有個(gè)比較關(guān)鍵的內(nèi)容，向老王求解，結(jié)果他也忘了。后來每次去酒館都會(huì)帶上一個(gè)本子記下某個(gè)關(guān)鍵內(nèi)容，防止無從查找，而且兩個(gè)人都能翻閱。

這個(gè)場景描述的是Web之前很少有兩個(gè)以上的頁面或者組件發(fā)生數(shù)據(jù)的交互，大家各自記得自己的狀態(tài)就好，而當(dāng)兩個(gè)組件或者頁面交互時(shí)，通常會(huì)采用Storage或者父子組件監(jiān)聽兄弟組件Bus來完成，能實(shí)現(xiàn)功能就是當(dāng)前最優(yōu)方案。

場景二

后來公司組織技術(shù)培訓(xùn)會(huì)，一下來了很多人，每個(gè)人都準(zhǔn)備了很多要說的內(nèi)容。不光有集中討論還有小組討論，大家都積極發(fā)言。但是最后要寫會(huì)議紀(jì)要的時(shí)候，所有人都懵了，因?yàn)檎l也不記得誰都說了什么，或者誰補(bǔ)充了誰的技術(shù)觀點(diǎn)，場面無比的尷尬。

然后大家重新翻開自己和小組的內(nèi)容記錄一條一條的寫在了會(huì)議室的白板上。關(guān)鍵內(nèi)容和補(bǔ)充內(nèi)容一一匹配，花了很長時(shí)間，終于搞定了。大家心里不停的罵街，卻都無可奈何。

這個(gè)場景描述的是，當(dāng)出現(xiàn)多個(gè)組件，或者多個(gè)層級(jí)的組件進(jìn)行數(shù)據(jù)交互時(shí)，在多個(gè)混亂的操作下，數(shù)據(jù)狀態(tài)的修改和更新都沒有按照預(yù)期的方向發(fā)展，也就是組件與組件之間互相維護(hù)多個(gè)單獨(dú)數(shù)據(jù)狀態(tài)，數(shù)據(jù)狀態(tài)的不集中導(dǎo)致多個(gè)組件的數(shù)據(jù)發(fā)生混亂。

場景三

再后面每次參加公司的技術(shù)討論會(huì)，我們都按順序在白板上寫上對(duì)應(yīng)的內(nèi)容，有人補(bǔ)充或者反駁都會(huì)修改白板上的內(nèi)容，大家也都能看到。小組討論出結(jié)果也會(huì)同步修改白板上的內(nèi)容，這樣隨便找個(gè)人寫會(huì)議紀(jì)要就可以了，大家終于不罵街了。

后來聽說隔壁的兩家公司也借鑒了我們的方法，說明我們的方法還是有很多可取之處的。忘了說了我們公司叫Angular，隔壁兩家公司一個(gè)叫React，另一個(gè)叫Vue。我覺得都沒有我們公司牛X，我們是第一個(gè)想到這個(gè)方法的。

通過以上這三個(gè)場景，我覺得能讓大家直觀的看到什么是狀態(tài)管理。在Angular框架中，所有的狀態(tài)其實(shí)是掛在全局上的，每次更新和修改都是通知全局，然后由全局通知所有用到這個(gè)狀態(tài)的組件。因?yàn)槭?strong>狀態(tài)集中管理和分發(fā)機(jī)制，所有組件都沒有全部所屬權(quán)。React和Vue框架都借鑒了這一點(diǎn)，但是是通過一個(gè)獨(dú)立的模塊Redux或Vuex來完成。

小結(jié)

前端狀態(tài)管理實(shí)際上解決的就是組件通訊以及狀態(tài)集中管理和分發(fā)的問題。不管官方文檔如何去描述，核心就是這樣。而市面上很多講解的書籍或者文章也都是官方術(shù)語闡述，說實(shí)話有的時(shí)候太干未必是一件好事。