image

人從出生到死亡走的這段路程宠蚂，稱為生命周期。

應(yīng)用從啟動到關(guān)閉經(jīng)歷的這段過程童社，也稱為生命周期——因此這是一個(gè)仿生概念求厕，基于相應(yīng)結(jié)構(gòu)的應(yīng)用也會有與人類相似的行為特點(diǎn)。

初接觸時(shí)扰楼，我們會為如何去更好的在這個(gè)過程中去實(shí)踐狀態(tài)管理焦頭爛額呀癣，糾結(jié)于不同架構(gòu)的各個(gè)節(jié)點(diǎn)對應(yīng)的職責(zé)，特別是在涉及異步和副作用的處理的過程中弦赖，很難快速找到一個(gè)“最佳實(shí)踐”项栏。那么，既然應(yīng)用具有仿生設(shè)計(jì)蹬竖，我們自然可以從基于作為人類的自身的角度去理解它沼沈。

狀態(tài)（State）

先來看一張圖：

5bd347bce4b098334411b4eb (1).png

從上圖可以看到，如果將一些過程和行為抽象出來币厕，人與 App 是具有高度的相似性的列另。

其中：

從書面意思理解：
<p align="center"><b>狀態(tài)是人或事物表現(xiàn)出來的形態(tài)。是指現(xiàn)實(shí)（或虛擬）事物處于生成暴心、生存妓盲、發(fā)展、消亡時(shí)期或各轉(zhuǎn)化臨界點(diǎn)時(shí)的形態(tài)或事物態(tài)勢专普。</b></p>

簡單來說悯衬，就是任一對象在特定狀況下的存在形態(tài)。
具體到人檀夹，可以是情緒甚亭、職業(yè)、資產(chǎn)等击胜。
具體到應(yīng)用，可以是一些布爾值役纹、狀態(tài)碼偶摔、具體數(shù)據(jù)等。

由這些可以對對象進(jìn)行描述的單元結(jié)合促脉，就構(gòu)成人或應(yīng)用辰斋。

全局狀態(tài)（Global State）

• 在人類的角度來看，我們剛形成胚胎便會有了性別瘸味、膚色宫仗、瞳色等基因決定的特征，我們因而為人旁仿，這些生理特征體現(xiàn)在我們生命歷程中的任何一個(gè)時(shí)刻藕夫。
• 對于應(yīng)用來說，靜態(tài)資源被運(yùn)行環(huán)境執(zhí)行的過程，就好比胚胎的生長過程毅贮，然后到了初始化狀態(tài)容器（Store）的時(shí)候办悟，便開始獲取初始數(shù)據(jù)，這些數(shù)據(jù)就包含了一系列初始狀態(tài)滩褥，它們可以是可用性病蛉、登錄狀態(tài)、角色策略瑰煎、顏色主題铺然、語言環(huán)境等等。

在人身上酒甸，本能魄健、認(rèn)知等因素往往是伴隨一生的，他們的有效性是覆蓋到所有其他情形下的烘挫，比如我吃飯的時(shí)候不知道美國總統(tǒng)是特朗普诀艰，那么我上廁所睡覺的時(shí)候同樣不會知道；有一天我在吃飯的時(shí)候得知了這個(gè)消息饮六，那么從此我上廁所睡覺的時(shí)候同樣也知道了其垄。

在應(yīng)用中，登錄狀態(tài)卤橄、顏色主題绿满、語言環(huán)境等也有這樣的特點(diǎn)。在一個(gè)應(yīng)用周期內(nèi)窟扑，每一次修改這些狀態(tài)喇颁，都是會應(yīng)用到全局的，至少是主體同步嚎货。

對于這些狀態(tài)橘霎，我們統(tǒng)稱為全局狀態(tài)

局部狀態(tài)（Module/Feature/Partial)

我們上廁所的時(shí)候，一般會向”抽紙盒“發(fā)起請求殖属，然后拿幾張紙姐叁，這是在如廁時(shí)的”后事“預(yù)備狀態(tài)；而我們在大街上則不會同樣拿著紙準(zhǔn)備擦屁股洗显，我們可能因?yàn)榭诳誓弥馇保驗(yàn)橘徫锬弥?/p>

在應(yīng)用里，具有不同職責(zé)的頁面展示的內(nèi)容也不同挠唆，我們不會沒事兒在首頁展示用戶的優(yōu)惠券詳情处窥，也不會沒事兒在課程詳情頁展示用戶余額。

在這些具有不同職責(zé)的場景下“獨(dú)有”的狀態(tài)玄组，我們稱為局部狀態(tài)

全局狀態(tài)和局部狀態(tài)的劃分

兩種狀態(tài)的特點(diǎn)其實(shí)很好理解滔驾，其實(shí)它們的劃分才是難點(diǎn)谒麦。

狀態(tài)本身就具有“全局性”，因?yàn)闋顟B(tài)一旦拿到嵌灰，那么不管是否是在對應(yīng)場景弄匕，它都存在于本次生命周期中，它隨時(shí)可能在新需求來到的時(shí)候被其他場景需要沽瞭，而你不一定總是能夠事先知曉迁匠。

當(dāng)然了，像用戶信息驹溃、登錄時(shí)間城丧、語言環(huán)境等因素是很好區(qū)分的，但更多更細(xì)的狀態(tài)是否需要放到全局豌鹤，或者說由公共性更高的模塊來管理亡哄，就很難一次性下定論了。

因此界定某個(gè)狀態(tài)的類型布疙，并不是一蹴而就的蚊惯，而是要在長期的迭代中進(jìn)行總結(jié)。

對于人來說灵临，這個(gè)問題不算是個(gè)問題截型，因?yàn)槲覀儞碛袕?qiáng)大的復(fù)雜問題處理能力，而計(jì)算機(jī)幾乎是沒有這樣的能力的儒溉，它們處理問題的方式都是人為定義的宦焦，即便 AI、ML 等技術(shù)蓬勃如今顿涣，也遠(yuǎn)遠(yuǎn)達(dá)不到人類的思維水平波闹。

我們以一個(gè)真實(shí)應(yīng)用里的一些實(shí)現(xiàn)為例：

5bd41e2de4b021eeb31e0377 (1).png

這是 WPS精品課 產(chǎn)品的移動端 Web App。

以職責(zé)劃分

第一張圖中涛碑，在兩個(gè)功能不同的頁面（場景）中都出現(xiàn)了分類這一數(shù)據(jù)形式精堕，并且數(shù)據(jù)是一致的，也就是說蒲障，這兩個(gè)頁面出現(xiàn)了公共狀態(tài)锄码。而這兩個(gè)公共狀態(tài)總是覆蓋全局的，那么我們就應(yīng)當(dāng)將它們提升到更高一層的狀態(tài)模塊中晌涕。

注意，提升到更高一層并不意味著提升到 global 的級別痛悯。有時(shí)候余黎，可能分類并不是一個(gè)簡單的數(shù)據(jù)，它可能是根據(jù)不同的用戶策略進(jìn)行展示的载萌，對于不同的用戶級別惧财，分類可能會呈現(xiàn)多態(tài)（比如普通用戶看不到 VIP 專屬的類別）巡扇。從前后端交互的角度來看，分類相關(guān)的接口往往也是獨(dú)立于其他數(shù)據(jù)的垮衷。因此厅翔，當(dāng)分類具有了一定的復(fù)雜性和具體規(guī)則，它應(yīng)當(dāng)有屬于自己的管理單元搀突，使得數(shù)據(jù)的吞吐和處理有更加清晰的思路刀闷，而不是去破壞性的影響全局狀態(tài)的職責(zé)。

就像人類在左右腦的統(tǒng)一調(diào)配下仰迁，有視覺中樞甸昏、聽覺中樞、運(yùn)動中樞徐许。如果它們產(chǎn)生了紊亂施蜜，使得腦功能失調(diào)，人就會出現(xiàn)各種各樣的問題雌隅，如少兒多動癥翻默、認(rèn)知障礙等。

以路由劃分

為什么是一個(gè)圓圈呢恰起？

其實(shí)這個(gè)頁面雖然常見修械，但在狀態(tài)管理中，它的確比較特殊村缸，因?yàn)樗仁且粋€(gè)路由單元祠肥，又是一個(gè)狀態(tài)單元。如果說一個(gè)頁面通常是由多個(gè)狀態(tài)組合而成的梯皿，那么“我的”頁面可能就只需要一個(gè)狀態(tài)就夠了——即用戶狀態(tài)仇箱。它往往包含了用戶基本信息，信用卡信息东羹，功能定制等——是的剂桥，往往我們就把它們放在 global 中。當(dāng)然根據(jù)應(yīng)用的類型和復(fù)雜度不同属提，用戶信息也可能劃分成若干單元权逗，因此，如此形式的按路由劃分冤议，其實(shí)是按職責(zé)劃分的一個(gè)變種斟薇。

然而，還有一種情況就不同了恕酸。比如某些活動型頁面堪滨，它們可能只包含一些運(yùn)營內(nèi)容，有一套自己的邏輯和交互蕊温，獨(dú)立于任何其他的頁面袱箱，但頁面本身的生命周期或許只有幾個(gè)星期甚至幾天遏乔，這時(shí)候可能就沒有必要為其設(shè)計(jì)和維護(hù)一個(gè)狀態(tài)單元了，得不償失发笔。

好比一個(gè)人要出國旅游一段時(shí)間盟萨，立馬給手機(jī)開了一系列便捷的境外服務(wù)，但回國后往往就立馬停掉了了讨，而不是為這些長期用不到的東西付費(fèi)捻激。

改變狀態(tài)

我們已經(jīng)探討了關(guān)于狀態(tài)的一些基礎(chǔ)內(nèi)容，現(xiàn)在問題來到了如何對狀態(tài)進(jìn)行“改查”量蕊。

首先铺罢，狀態(tài)是對象在特定環(huán)境和具體時(shí)機(jī)下的某種存在表現(xiàn)，隨著環(huán)境和時(shí)機(jī)的改變残炮，它便會發(fā)生相應(yīng)的更新韭赘。

我們拿“時(shí)間”舉例，它是最客觀最不可阻擋的狀態(tài)流势就。

對于人類泉瞻，在一個(gè)時(shí)間單元內(nèi)（指，年苞冯、月袖牙、日等）我們會根據(jù)具體的時(shí)間點(diǎn)調(diào)整我們自身的狀態(tài)——睡覺、起床舅锄、工作鞭达、小憩等等；
對于應(yīng)用皇忿，最常見的就是一些即時(shí)服務(wù)的開關(guān)畴蹭。比如某購物 App，白天一直到晚上九點(diǎn)會有針對會員的“一小時(shí)送達(dá)”的服務(wù)鳍烁，但過了這個(gè)時(shí)間點(diǎn)叨襟，這個(gè)服務(wù)便進(jìn)入休眠狀態(tài)。

那么從外部條件改變到對象自身的狀態(tài)更改幔荒，中間經(jīng)歷了什么呢糊闽？

我們來看幾個(gè)當(dāng)下炙手可熱的前端數(shù)據(jù)流模型：

5bdfe666e4b002916e39d322.png

So You See！

這里面似乎有一個(gè)恒定的范式：
<p align="center"><b>Action - Update state</b></p>

Store 和 State

Store是狀態(tài)中心爹梁，而State就是這里面的一個(gè)個(gè)狀態(tài)集合右犹。

在 Flux 和 Redux 的模型中，我們可以顯式的看到Store節(jié)點(diǎn)姚垃，而 Mobx 和 Vuex 里這個(gè)節(jié)點(diǎn)似乎由State代替了念链。這個(gè)是由于兩種風(fēng)格不同的狀態(tài)聲明方式導(dǎo)致的，這里以最常見的 Redux 和 Vuex 的Store構(gòu)建方式為例：

reduxvsvuex

可以看到，源于 Flux 思想的 Redux 的Store聲明過程更像是將各個(gè)獨(dú)立的狀態(tài)單元（Reducer钓账，詳見后文）整合（combine）在一起，形成一個(gè)自Store而下的狀態(tài)樹絮宁，實(shí)現(xiàn)單向數(shù)據(jù)流梆暮。其工作特點(diǎn)是所有的行為都要經(jīng)過Store。
PS：其中的Action Handlers的實(shí)際形式其實(shí)是switch語法下的一個(gè)個(gè)模式绍昂，并非具體函數(shù)或方法啦粹，這里只是根據(jù)其職責(zé)進(jìn)行了類比理解。

而 Vuex 呢窘游，其實(shí)也是源于 Flux 的唠椭，但它吸取了 Redux 樣板代碼繁瑣的“教訓(xùn)”，將combine的過程用聲明的方式規(guī)避了忍饰，同時(shí)將狀態(tài)單元細(xì)分成各個(gè)module贪嫂，每個(gè)module包含了一套State和對應(yīng)的規(guī)則，比起 Redux 來說艾蓝，是一種“高類聚力崇、低耦合”的方案，節(jié)省了一些聲明和管理狀態(tài)的成本赢织。工作特點(diǎn)眼下就是各個(gè)module各司其職亮靴，只影響自己的State。
然而于置，Vuex 在實(shí)際的工作過程中茧吊，其實(shí)還是由Store作為中心進(jìn)行分發(fā)，只是其構(gòu)建方式讓我們覺得Store并沒有被總是調(diào)起八毯。

總的來說搓侄，Store的地位如同我們的大腦，我們的任何決策宪彩、行為都會經(jīng)過大腦進(jìn)行評估休讳、加工。但隨著某種刺激的不斷觸發(fā)尿孔，其對應(yīng)的反應(yīng)行為也會出現(xiàn)得越來越快俊柔，等到形成相對固定的范式的時(shí)候，我們可能就感覺不到思維在這個(gè)過程中的行動了活合，體現(xiàn)為“反應(yīng)快”雏婶。
對于普通應(yīng)用開發(fā)來說，我們則可以直接定義這種“范式”白指，這更有利于我們整體上的把握應(yīng)用的規(guī)則留晚，強(qiáng)化和優(yōu)化應(yīng)用的邏輯。良好的狀態(tài)管理實(shí)踐會讓應(yīng)用更加高效，也更好維護(hù)错维。

Action

在上面的幾種數(shù)據(jù)流模型中奖地，在對狀態(tài)進(jìn)行修改前，都會經(jīng)過一個(gè)叫Action的節(jié)點(diǎn)赋焕，這個(gè)節(jié)點(diǎn)我們可以理解成行為参歹。

Action 即是向Store發(fā)起更新請求的最小單元。

它的結(jié)構(gòu)通常是:

// pureObject
const myAction = {
  type: 'GO_TO_BED',
  payload: Medicine.Estazolam
}
// functional
const myFunctionalAction = arg => {
  let payload
  // TODO
  return {
    type: 'GO_TO_BED',
    payload
  }
}

其中：

• type: 對這個(gè)行為的描述隆判，Store 根據(jù)這個(gè)字段去尋找對應(yīng)的處理方案
• payload?：荷載犬庇，攜帶實(shí)現(xiàn)該行為要使用的一些數(shù)據(jù)

這個(gè)比較好理解，要做一件事侨嘀，得先明確這是什么事臭挽，如果有需要還要帶上相應(yīng)的東西。比如：大便要帶紙咬腕；而小便可能帶欢峰，也可能不帶；只是去洗手就什么都不用帶了郎汪。

可見赤赊，Action最終只是一個(gè)對象，那它如何傳遞給Store呢煞赢？

Dispatch

我們完成一個(gè)“刺激——反應(yīng)”的時(shí)候抛计，通常先是神經(jīng)末梢收到接收刺激，然后大腦得到神經(jīng)末梢發(fā)來的信息照筑，做出反應(yīng)吹截。在這個(gè)過程中，攜帶信息的介質(zhì)被稱為神經(jīng)遞質(zhì)凝危，它活動在突觸之間波俄。
而在各類應(yīng)用狀態(tài)管理的模型中，通常都會有一個(gè)dispatch方法蛾默，它就聲明在Store上懦铺，負(fù)責(zé)調(diào)用各個(gè)Action，然后由Store上對應(yīng)的分發(fā)機(jī)制進(jìn)行處理支鸡。同時(shí)冬念，異步Action的實(shí)現(xiàn)，即是將這個(gè)方法作為參數(shù)傳給對應(yīng)的ActionCreator牧挣，然后等到異步工作流完成后急前，將最終的Action傳遞給Store。例如構(gòu)建一個(gè)redux-thunk中的異步Action：

const asyncAction = id => {
  // 集成 redux-thunk 后瀑构，redux 會將 dispatch 等一系列方法傳遞給 actionCreator 返回的函數(shù)裆针，供異步工作完成后 actionCreator 能配合 Redux 進(jìn)行工作
  return dispatch => {
    fetch('/getData?id=' + id)
      .then(response => response.json())
      .then(data => {
        dispatch({
          type: 'SET_DATA',
          payload: data
        })
      })
  }
}

Reducer / Mutation

現(xiàn)在到了更新狀態(tài)的時(shí)候了，簡單抽象出來就是newState = updatedState，不難理解世吨，主要看下實(shí)現(xiàn)澡刹。

在 Flux 和 Mobx 的模型中，對狀態(tài)的修改比較直接耘婚，不多贅述像屋，那么“矯情”一些的 Redux 和 Vuex 是如何實(shí)踐的呢。

我們從其實(shí)現(xiàn)上分別說明它們的作用

Reducer

先來看一個(gè)簡單 Reducer 實(shí)現(xiàn)：

function myReducer (state = { age: 1 }, action) {
  switch (action.type) {
    case 'HappyBirthDay': return {
      age: ++state.age
    }
    default: return Object.assign({}, state)
  }
}

Reducer 的工作方式是边篮，接收一個(gè)Action，然后在 switch 流中匹配action.type奏甫，做出相應(yīng)處理戈轿，然后返回一個(gè)新的對象。其源碼可以看這里

為什么是新的對象呢阵子？

因?yàn)?Redux 是一個(gè)實(shí)踐函數(shù)式編程（FP）理念的庫思杯。函數(shù)式編程有個(gè)要素就是——純函數(shù)不能有副作用，而副作用簡單概括來說就是對該函數(shù)內(nèi)部環(huán)境以外的變量進(jìn)行了修改挠进、銷毀等操作色乾。

回過頭來，在 Redux 中领突，Reducer 原則上就是一個(gè)純函數(shù)暖璧。
這有什么意義呢？

答案是數(shù)據(jù)不可變君旦，它也是函數(shù)式編程中的一個(gè)要點(diǎn)澎办。
函數(shù)式編程認(rèn)為可變和共享是“萬惡之源”，原數(shù)據(jù)的更新只能通過返回新的數(shù)據(jù)金砍。否則隨意修改的數(shù)據(jù)可能讓應(yīng)用產(chǎn)生難以預(yù)料的問題局蚀，而“共享”加“可變”帶來的副作用更是容易容易讓我們得到錯(cuò)誤并且難以捕獲的內(nèi)容。

Mutaion

Vuex 是在Mutation中修改狀態(tài)的恕稠，其代碼一般如下：

// module
export default {
  //...
  mutations: {
    SET_DATA (state, payload) {
      state.data = payload
    }
  },
  
  actions: {
    async getData ({ commit }, payload) {
      const res = await api.data.get(payload.id)()
      
      commit('SET_DATA', res.data)
    }
  }
}

// component
export default {
  mounted () {
    store.dispatch('getData', this.id)
  }
}

其中琅绅，觸發(fā)一個(gè)Action依然是通過dispatch方法，然而鹅巍，修改狀態(tài)為什么需要commit一下呢千扶？
其實(shí)我們直須將mutations和actions中的各個(gè)成員都理解成Action，因?yàn)槟阋部梢灾苯釉?code>Store上調(diào)用commit來修改狀態(tài)昆著。 commit的職責(zé)相當(dāng)簡單县貌，就是修改本地狀態(tài)。

而Action的職責(zé)在于可以實(shí)現(xiàn)異步流和Action流（在action中dispatch又一個(gè)（可以是自己）action）凑懂，最后提交到Mutation中來修改狀態(tài)煤痕。但從源碼來看，其實(shí) Vuex 同樣賦予了Action改變狀態(tài)的能力，它將State作為第一個(gè)參數(shù)的其中一個(gè)屬性傳遞給了Action摆碉，其目的是為了你可以使用State上的狀態(tài)和數(shù)據(jù)塘匣，原則上這是只讀的，但結(jié)合 MVVM 的特點(diǎn)巷帝，你在這里修改它忌卤，同樣也會引起視圖的改變。

源碼里是這樣寫的：

function registerMutation (store, type, handler, local) {
  const entry = store._mutations[type] || (store._mutations[type] = [])
  entry.push(function wrappedMutationHandler (payload) {
    // store 會調(diào)用 commit 方法來啟用這個(gè) mutation楞泼，并且只傳入了本地 state 和一系列荷載
    handler.call(store, local.state, payload)
  })
}

function registerAction (store, type, handler, local) {
  const entry = store._actions[type] || (store._actions[type] = [])
  entry.push(function wrappedActionHandler (payload, cb) {
    // action 就比較厲害了驰徊，這么多...
    let res = handler.call(store, {
      dispatch: local.dispatch,
      commit: local.commit,
      getters: local.getters,
      state: local.state,
      rootGetters: store.getters,
      rootState: store.state
    }, payload, cb)
    if (!isPromise(res)) {
      res = Promise.resolve(res)
    }
    if (store._devtoolHook) {
      return res.catch(err => {
        store._devtoolHook.emit('vuex:error', err)
        throw err
      })
    } else {
      return res
    }
  })
}

可見，你甚至可以不顧一切的在Action中修改全局的State堕阔。

在行為心理學(xué)中棍厂，其中一種行為的分類方式即是將行為分為外顯行為和內(nèi)隱行為。外顯行為就是我們?nèi)庋劭梢姷某剑忻鞔_外在表現(xiàn)的行為牺弹；內(nèi)隱行為則是外表之下，發(fā)生于機(jī)體內(nèi)部的情緒變化时呀、思維運(yùn)作张漂、激素分泌等不會彰顯出來的行為。但往往我們改變大腦中的某個(gè)狀態(tài)谨娜，使之顯于或不顯于我們的姿態(tài)的時(shí)候航攒，這些內(nèi)隱行為是不可能避免的，因?yàn)槲覀兊拇竽X活動就是各類遞質(zhì)工作下的一系列的化學(xué)反應(yīng)趴梢。

這與Action和Mutation的關(guān)系很像屎债，Vuex 告訴我們修改狀態(tài)的唯一方法是提交Mutation，也就是說你不應(yīng)該在Action中的直接修改State垢油，就好像我們的外顯行為總是要經(jīng)過內(nèi)隱行為來提交給大腦一樣盆驹。

當(dāng)然了，既然職責(zé)不同滩愁，角色肯定就不同躯喇，理解成Action是為了我們便于理解。

再次提醒硝枉，Vuex 明確告訴我們改變狀態(tài)的唯一方法是提交Mutation廉丽，因此我們應(yīng)當(dāng)遵循這個(gè)原則，將Action中的各個(gè)響應(yīng)式引用視為只讀妻味，以保證應(yīng)用的邏輯性不會被破壞正压。（當(dāng)然，直接 commit 啦责球，想想mapMutations方法＝孤摹）

總結(jié)

通過一張圖來梳理一下狀態(tài)管理與人類行為的共通之處：

5be14bcce4b067b9db579b11.png

PS

這不是一篇論述拓劝，狀態(tài)管理也遠(yuǎn)遠(yuǎn)不止這幾種模型，小生僅僅在前端應(yīng)用及其比較有代表性的狀態(tài)管理方案的背景下分享了這個(gè)角度嘉裤，因此這個(gè)理解方式必然有一定的局限性或者是未被完全論證郑临。如果能幫助到讀者，小生就非常榮幸了屑宠。

理解狀態(tài)管理的方式有很多厢洞，這只是其中一種思路，或許這種思路能在應(yīng)用開發(fā)的同時(shí)也鍛煉我們的邏輯思維典奉。

同時(shí)躺翻，實(shí)際場景下的狀態(tài)管理必然一個(gè)更加復(fù)雜的東西，隨著應(yīng)用的規(guī)模和深度越來越大卫玖，我們需要更深刻思考它获枝，如何劃分模塊？如何共享模塊骇笔？如何構(gòu)建容器？如何提升效率嚣崭？這都是需要逐步探索的笨触，當(dāng)然，最快的方式雹舀，就是在已有的狀態(tài)管理范式中思考芦劣，組織、優(yōu)化。

最后，要記住的是：
<p align="center"><b>你可能不需要狀態(tài)管理</b></p>