背景
在最近的一次需求開發過程中，有再次使用到Vuex，在狀態更新這一方面，我始終遵循着官方的“叮囑”，謹記“一定不要在action中修改state，而是要在mutation中修改”；於是我不禁產生了一個疑問：Vuex為什么要給出這個限制，它是基於什么原因呢？帶着這個疑問我查看Vuex的源碼，下面請大家跟着我的腳步，來一起揭開這個問題的面紗。
一起閱讀源碼吧~
1.首先我們可以在src/store.js這個文件的Store類中找到下面這段代碼
|
1
2
3
4
5
6
7
8
|
// ...
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方法的核心代碼大致如下：
|
1
2
3
4
5
6
7
8
9
|
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方法的代碼如下：
|
1
2
3
4
5
6
|
_withCommit (fn) {
const committing =
this
._committing
this
._committing =
true
fn()
this
._committing = committing
}
|
是的，你沒有看錯，它真的只有4行代碼；這里我們注意到有一個標志位_committing，在執行fn前，這個標志位會被置為true，這個點我們先記下，一會兒會用到
4.接下來，我要為大家要介紹的是resetStoreVM這個函數，它的作用是初始化store，它首次被執行是在Store的構造函數中
|
1
2
3
4
5
6
7
|
function
resetStoreVM (store, state, hot) {
// ...
if
(store.strict) {
enableStrictMode(store)
}
// ...
}
|
在這里有一處需要我們注意：resetStoreVM對strict（是否啟用嚴格模式）做了判斷，這里假設我們啟用嚴格模式，那么就會執行enableStrictMode這個函數，下面繼續來看看它的內部實現
|
1
2
3
4
5
6
7
|
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這個文件中
|
1
2
3
|
export
function
assert (condition, msg) {
if
(!condition)
throw
new
Error(`[vuex] ${msg}`)
}
|
這個方法很簡單，就是判斷第一個參數是否為truly值，如果不為真，就拋出一個異常
到此，我們已簡單地了解了commit和mutation的邏輯，下面再來看看dispatch和action
dispatch&action
6.dispatch代碼大致如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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實例：P1、P2、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（斷言）這行代碼
|
1
2
3
4
5
6
7
|
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，所以也就不會存在返回結果先后問題
|
1
2
3
4
5
6
7
|
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中修改狀態“這個問題的分析，希望對大家有所幫助，也歡迎指正