vuex的mutations与actions的使用测试
这里不谈vuex如何使用等问题，只讨论 mutaions 中定义的方法需要在 actions 中进行转发一下吗？
mutations: {
muFn (state, data) {
state.data = data
}
}
actions: {
muFn ({commit}, data) {
commit.muFn(data)
}
}
现在纠结点在于，在 mutations 中定义了方法，还要在 actions 中再调用一遍吗
起因
在看一些github的项目时，一些人直接在 vue单文件中，直接调用 mutation 里的方法，而还有一部分人在 vue单文件中，直接调用 action 里的方法(action再去调用 mutation)。而这两者之间的项目获取的 start 都比较好，很难明说具体哪个更有优势。
采用 mutation
import {
RECORD_ADDRESS,
ADD_CART,
REDUCE_CART,
INIT_BUYCART,
CLEAR_CART,
RECORD_SHOPDETAIL,
RECORD_USERINFO,
GET_USERINFO,
CONFIRM_REMARK,
CONFIRM_INVOICE,
CHOOSE_SEARCH_ADDRESS,
SAVE_GEOHASH,
CONFIRM_ADDRESS,
CHOOSE_ADDRESS,
NEED_VALIDATION,
SAVE_CART_ID_SIG,
SAVE_ORDER_PARAM,
CHANGE_ORDER_PARAM,
ORDER_SUCCESS,
SAVE_SHOPID,
SAVE_ORDER,
OUT_LOGIN,
RETSET_NAME,
SAVE_AVANDER,
SAVE_ADDRESS,
SAVE_ADDDETAIL,
SAVE_QUESTION,
ADD_ADDRESS,
BUY_CART,
} from './mutation-types.js'
...
const state = {
logs: []
}
const mutations = {
ADD_ERROR_LOG: (state, log) => {
state.logs.push(log)
},
CLEAR_ERROR_LOG: (state) => {
state.logs.splice(0)
}
}
const actions = {
addErrorLog({ commit }, log) {
commit('ADD_ERROR_LOG', log)
},
clearErrorLog({ commit }) {
commit('CLEAR_ERROR_LOG')
}
}
export default {
namespaced: true,
state,
mutations,
actions
}
可以看出， mutation 与 action 根本不对等
采用 action
import {
getUser,
getAddressList
} from '../service/getData'
import {
GET_USERINFO,
SAVE_ADDRESS
} from './mutation-types.js'
export default {
async getUserInfo({
commit,
state
}) {
let res = await getUser();
commit(GET_USERINFO, res)
},
async saveAddress({
commit,
state
}) {
if(state.removeAddress.length > 0) return;
let addres = await getAddressList(state.userInfo.user_id);
commit(SAVE_ADDRESS, addres);
},
}
可以看出， mutation 里的方法都会在 action 中再定义一遍。
然后在 github 上找了一些相关的项目，两种方式都有，在使用 action 这种方式的，在vue单文件中，几乎看不到 commit 的存在，这样是不是有些太偏激了。然后找到了一个 尤大 写的项目，终于看到了 commit 。
尝试
基于此，我在本地起了一个项目，分别采用上面的方式进行处理，并没有发现因为使用 action 而有特别的待遇，只要在 mutaion 中卡住，代码依旧不会再执行。说是利用 action 的异步特性也没看出所以然来，可能个人偏好代码简化。若是大型项目，里面N多个 mutation 方法，那 action 真的不敢想。
总结
由于鄙人尝试了各种方式，没有找出两种写法的差别所在。因而还是看团队规范吧，但还是希望没必要特意去重复定义了，累赘不说，还增加了维护成本。
参考链接
