背景

在最近的一次需求開(kāi)發(fā)過(guò)程中，有再次使用到Vuex，在狀態(tài)更新這一方面，我始終遵循著官方的“叮囑”，謹(jǐn)記“一定不要在action中修改state，而是要在mutation中修改”；于是我不禁產(chǎn)生了一個(gè)疑問(wèn)：Vuex為什么要給出這個(gè)限制，它是基于什么原因呢？帶著這個(gè)疑問(wèn)我查看Vuex的源碼，下面請(qǐng)大家跟著我的腳步，來(lái)一起揭開(kāi)這個(gè)問(wèn)題的面紗。

一起閱讀源碼吧~

1.首先我們可以在src/store.js這個(gè)文件的Store類(lèi)中找到下面這段代碼

// ...
this.dispatch = function boundDispatch (type, payload) {
 return dispatch.call(store, type, payload)
}
this.commit = function boundCommit (type, payload, options) {
 return commit.call(store, type, payload, options)
}
// ...

上面是Vuex兩個(gè)最核心的API：dispatch & commit，它們是分別用來(lái)提交action和mutation的

那么既然我們今天的目的是為了“了解為什么不能在action中修改state”，所以我們就先看看mutation是怎樣修改state的，然而mutation是通過(guò)commit提交的，所以我們先看一下commit的內(nèi)部實(shí)現(xiàn)

commit&mutation

2.commit方法的核心代碼大致如下：

commit (_type, _payload, _options) {
  // ...
  this._withCommit(() => {
   entry.forEach(function commitIterator (handler) {
    handler(payload)
   })
  })
  // ...
}

不難看出，Vuex在commit（提交）某種類(lèi)型的mutation時(shí)，會(huì)先用_withCommit包裹一下這些mutation，即作為參數(shù)傳入_withCommit；那么我們來(lái)看看_withCommit的內(nèi)部實(shí)現(xiàn)（ps：這里之所以說(shuō)”某種類(lèi)型的mutation“，是因?yàn)閂uex的確支持聲明多個(gè)同名的mutation，不過(guò)前提是它們?cè)诓煌膎amespace下；action同理）

3._withCommit方法的代碼如下：

_withCommit (fn) {
  const committing = this._committing
  this._committing = true
  fn()
  this._committing = committing
 }

是的，你沒(méi)有看錯(cuò)，它真的只有4行代碼；這里我們注意到有一個(gè)標(biāo)志位_committing，在執(zhí)行fn前，這個(gè)標(biāo)志位會(huì)被置為true，這個(gè)點(diǎn)我們先記下，一會(huì)兒會(huì)用到

4.接下來(lái)，我要為大家要介紹的是resetStoreVM這個(gè)函數(shù)，它的作用是初始化store，它首次被執(zhí)行是在Store的構(gòu)造函數(shù)中

function resetStoreVM (store, state, hot) {
 // ...
 if (store.strict) {
  enableStrictMode(store)
 }
// ...
}

在這里有一處需要我們注意：resetStoreVM對(duì)strict（是否啟用嚴(yán)格模式）做了判斷，這里假設(shè)我們啟用嚴(yán)格模式，那么就會(huì)執(zhí)行enableStrictMode這個(gè)函數(shù)，下面繼續(xù)來(lái)看看它的內(nèi)部實(shí)現(xiàn)

function enableStrictMode (store) {
 store._vm.$watch(function () { return this._data.$$state }, () => {
  if (process.env.NODE_ENV !== 'production') {
   assert(store._committing, `do not mutate vuex store state outside mutation handlers.`)
  }
 }, { deep: true, sync: true })
}

這里對(duì)Vue組件實(shí)例的state做了監(jiān)聽(tīng)，一旦監(jiān)聽(tīng)到變化，就會(huì)執(zhí)行asset（斷言），它斷言的恰巧就是剛才我讓大家記住的那個(gè)_committing標(biāo)志位，那么我們?cè)賮?lái)看看這個(gè)asset做了些什么

5.asset方法在src/util.js這個(gè)文件中

export function assert (condition, msg) {
 if (!condition) throw new Error(`[vuex] ${msg}`)
}

這個(gè)方法很簡(jiǎn)單，就是判斷第一個(gè)參數(shù)是否為truly值，如果不為真，就拋出一個(gè)異常
到此，我們已簡(jiǎn)單地了解了commit和mutation的邏輯，下面再來(lái)看看dispatch和action

dispatch&action

6.dispatch代碼大致如下：

dispatch (_type, _payload) {
  const {
   type,
   payload
  } = unifyObjectStyle(_type, _payload)

  const action = { type, payload }
  const entry = this._actions[type]

 // ...
  const result = entry.length > 1
   ? Promise.all(entry.map(handler => handler(payload)))
   : entry[0](payload)
 // ...
 }

這里我們注意到，當(dāng)某種類(lèi)型的action只有一個(gè)聲明時(shí)，action的回調(diào)會(huì)被當(dāng)作普通函數(shù)執(zhí)行，而當(dāng)如果有多個(gè)聲明時(shí)，它們是被視為Promise實(shí)例，并且用Promise.all執(zhí)行，總所周知，Promise.all在執(zhí)行Promise時(shí)是不保證順序的，也就是說(shuō)，假如有3個(gè)Promise實(shí)例：P1、P2、P3，它們3個(gè)之中不一定哪個(gè)先有返回結(jié)果，那么我們仔細(xì)思考一下：如果同時(shí)在多個(gè)action中修改了同一個(gè)state，那會(huì)有什么樣的結(jié)果？

其實(shí)很簡(jiǎn)單，我們?cè)诙鄠€(gè)action中修改同一個(gè)state，因?yàn)楹苡锌赡苊總€(gè)action賦給state的新值都有所不同，并且不能保證最后一個(gè)有返回結(jié)果action是哪一個(gè)action，所以最后賦予state的值可能是錯(cuò)誤的

那么Vuex為什么要使用Promise.all執(zhí)行action呢？其實(shí)也是出于性能考慮，這樣我們就可以最大限度進(jìn)行異步操作并發(fā)
眼尖的同學(xué)可能已經(jīng)發(fā)現(xiàn)在dispatch中并沒(méi)有看到_committing的身影，就是Vuex對(duì)action修改state的限制：當(dāng)action想要修改state時(shí)，因?yàn)開(kāi)committing沒(méi)有事先被置為true，而導(dǎo)致asset階段無(wú)法通過(guò)

但這個(gè)限制只限于開(kāi)發(fā)階段，因?yàn)樵趀nableStrictMode函數(shù)中，Webpack加入了對(duì)環(huán)境的判斷，如果不是生產(chǎn)環(huán)境（也就是開(kāi)發(fā)環(huán)境）才會(huì)輸出asset（斷言）這行代碼

function enableStrictMode (store) {
 store._vm.$watch(function () { return this._data.$$state }, () => {
  if (process.env.NODE_ENV !== 'production') {
   assert(store._committing, `do not mutate vuex store state outside mutation handlers.`)
  }
 }, { deep: true, sync: true })
}

那么也就是說(shuō)如果你強(qiáng)行在生產(chǎn)環(huán)境中用action修改state，Vuex也不會(huì)阻止你，它可能僅僅是給你一個(gè)警告；而且按道理來(lái)說(shuō)，如果我們能夠保證同一類(lèi)型的action只有一個(gè)聲明，那么無(wú)論是使用action還是mutation來(lái)修改state結(jié)果都是一樣的，因?yàn)閂uex針對(duì)這種情況，沒(méi)有使用Promise.all執(zhí)行action，所以也就不會(huì)存在返回結(jié)果先后問(wèn)題

dispatch (_type, _payload) {
  // ...
  const result = entry.length > 1
   ? Promise.all(entry.map(handler => handler(payload)))
   : entry[0](payload)
  // ...
 }

但是凡是靠人遵守的約定都是不靠譜的，所以我們?cè)谄綍r(shí)使用Vuex時(shí)，最好還是遵守官方的約束，否則線上代碼有可能出現(xiàn)bug，這不是我們所期望的。

結(jié)束語(yǔ)

Vuex這一限制其實(shí)也是出于代碼設(shè)計(jì)考慮，action和mutation各司其事，本質(zhì)上也是遵守了“單一職責(zé)”原則。以上就是我對(duì)“Vuex為什么不允許在action中修改狀態(tài)“這個(gè)問(wèn)題的分析，希望對(duì)大家有所幫助，也歡迎指正

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。