vuex爲何不建議在action中修改state

背景

在最近的一次需求開發過程當中，有再次使用到Vuex，在狀態更新這一方面，我始終遵循着官方的「叮囑」，謹記「必定不要在action中修改state，而是要在mutation中修改」；因而我不由產生了一個疑問：Vuex爲何要給出這個限制，它是基於什麼緣由呢？帶着這個疑問我查看Vuex的源碼，下面請你們跟着個人腳步，來一塊兒揭開這個問題的面紗。

一塊兒閱讀源碼吧~

1.首先咱們能夠在src/store.js這個文件的Store類中找到下面這段代碼

// ...
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兩個最核心的API：dispatch & commit，它們是分別用來提交action和mutation的 那麼既然咱們今天的目的是爲了「瞭解爲何不能在action中修改state」，因此咱們就先看看mutation是怎樣修改state的，然而mutation是經過commit提交的，因此咱們先看一下commit的內部實現

commit&mutation

2.commit方法的核心代碼大體以下：

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

不難看出，Vuex在commit（提交）某種類型的mutation時，會先用_withCommit包裹一下這些mutation，即做爲參數傳入_withCommit；那麼咱們來看看_withCommit的內部實現（ps：這裏之因此說」某種類型的mutation「，是由於Vuex的確支持聲明多個同名的mutation，不過前提是它們在不一樣的namespace下；action同理）

3._withCommit方法的代碼以下：

_withCommit (fn) {
    const committing = this._committing
    this._committing = true
    fn()
    this._committing = committing
  }
複製代碼

是的，你沒有看錯，它真的只有4行代碼；這裏咱們注意到有一個標誌位_committing，在執行fn前，這個標誌位會被置爲true，這個點咱們先記下，一下子會用到

4.接下來，我要爲你們要介紹的是resetStoreVM這個函數，它的做用是初始化store，它首次被執行是在Store的構造函數中

function resetStoreVM (store, state, hot) {
  // ...
  if (store.strict) {
    enableStrictMode(store)
  }
// ...
}
複製代碼

在這裏有一處須要咱們注意：resetStoreVM對strict（是否啓用嚴格模式）作了判斷，這裏假設咱們啓用嚴格模式，那麼就會執行enableStrictMode這個函數，下面繼續來看看它的內部實現

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 })
}
複製代碼

這裏對Vue組件實例的state作了監聽，一旦監聽到變化，就會執行asset（斷言），它斷言的恰巧就是剛纔我讓你們記住的那個_committing標誌位，那麼咱們再來看看這個asset作了些什麼

5.asset方法在src/util.js這個文件中

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

這個方法很簡單，就是判斷第一個參數是否爲truly值，若是不爲真，就拋出一個異常

到此，咱們已簡單地瞭解了commit和mutation的邏輯，下面再來看看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)
  // ...
  }
複製代碼

這裏咱們注意到，當某種類型的action只有一個聲明時，action的回調會被看成普通函數執行，而當若是有多個聲明時，它們是被視爲Promise實例，而且用Promise.all執行，總所周知，Promise.all在執行Promise時是不保證順序的，也就是說，假若有3個Promise實例：P一、P二、P3，它們3個之中不必定哪一個先有返回結果，那麼咱們仔細思考一下：若是同時在多個action中修改了同一個state，那會有什麼樣的結果？

其實很簡單，咱們在多個action中修改同一個state，由於頗有可能每一個action賦給state的新值都有所不一樣，而且不能保證最後一個有返回結果action是哪個action，因此最後賦予state的值多是錯誤的

那麼Vuex爲何要使用Promise.all執行action呢？其實也是出於性能考慮，這樣咱們就能夠最大限度進行異步操做併發

眼尖的同窗可能已經發如今dispatch中並無看到_committing的身影，就是Vuex對action修改state的限制：當action想要修改state時，由於_committing沒有事先被置爲true，而致使asset階段沒法經過

但這個限制只限於開發階段，由於在enableStrictMode函數中，Webpack加入了對環境的判斷，若是不是生產環境（也就是開發環境）纔會輸出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 })
}
複製代碼

那麼也就是說若是你強行在生產環境中用action修改state，Vuex也不會阻止你，它可能僅僅是給你一個警告；並且按道理來講，若是咱們可以保證同一類型的action只有一個聲明，那麼不管是使用action仍是mutation來修改state結果都是同樣的，由於Vuex針對這種狀況，沒有使用Promise.all執行action，因此也就不會存在返回結果前後問題

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

可是凡是靠人遵照的約定都是不靠譜的，因此咱們在平時使用Vuex時，最好仍是遵照官方的約束，不然線上代碼有可能出現bug，這不是咱們所指望的。

結束語

Vuex這一限制其實也是出於代碼設計考慮，action和mutation各司其事，本質上也是遵照了「單一職責」原則。以上就是我對「Vuex爲何不容許在action中修改狀態「這個問題的分析，但願對你們有所幫助，也歡迎指正

關注咱們