Friends who know vuex know that it is a container used by vue to centrally manage state. Friends who know Reduce may be familiar with it when they see it. They are all used to manage the global state and access data between different components.We will not introduce vuex here, but will focus on vuex split store s and multimodule management.We know that if a project is very large, there will be a lot of states. If all States are maintained in one state without categorization, state management will become very confusing, which is very detrimental to the later maintenance of the project.We now advocate modular development in the front end so as to improve the efficiency of development and maintenance and avoid duplication of work.So how does vuex solve this problem?At this time, the protagonist modules we're going to talk about today will shine.
Actually, this is very simple to use. Normally, when we use vuex, we define it like this:
states.js //Save applied state values
export default {
bookList:["Journey to the West","Water Margin","The Dream of Red Mansion","Romance of the Three Kingdoms"]
}
mutations.js //Defines operations on state values, additions, deletions, and alterations in this file.
export default {//Be careful not to do asynchronous operations inside mutations here
ADD_BOOK(state,book){
state.bookList.push(book);
return true;
},
DELETE_BOOK(state,id){
}
}
getters.js //Expose the values we define in the stats to the store.getters object so that we can access the data in the component through the store.getters.bookList
export default {
bookList:function(state){
return state.bookList;
}
}
actions.js //Actually, the method defined here only encapsulates the method defined in mutation.js once, that is, to trigger the method in mutations.js.If the passed parameter needs to be acquired asynchronously, we can wait here for the method in the trigger mutations after the asynchronous return is successful.Both of the methods defined in the files in the component can be called directly. The methods defined in mutations are called through store.dispath('ADDBOK', book), while actons are called through store.commit('ADD_BOOK', book).
export default {//Asynchronous operations can be performed in an action.
add_book({commit},book){
commit('ADD_BOOK',book);
},
delete_book({commit},book){
commit('DELETE_BOOK',id);
}
}
Sometimes we may also see a file called mutations_type.js. In fact, this file defines the method name in mutations. I did not define this file when I used it. I will define it if I like it.
Once the files defined above are defined, we can add the objects we defined to the tore of vuex
store.js
import vue from 'vue'
import vuex from 'vuex'
import states from './state.js'
import mutatons from './mutations.js'
import actons from './actions.js'
import getters from './getters'
vue.use(vuex);
export default new vuex.Store({
ststes,
mutatons,
getters,
actions
});
So we've written a whole store.We can see that we only have one total module here, so what should we define if we want to split the total module into several small modules?
import vue from 'vue'
import vuex from 'vuex'
import states from './state.js'
import mutatons from './mutations.js'
import actons from './actions.js'
import getters from './getters'
vue.use(vuex);
export default new vuex.Store({
modules:{
mod1:{
states,
mutatons,
getters,
actions
},
mod2:{}
}
});
import vue from 'vue'
import vuex from 'vuex'
import states from './state.js'
import mutatons from './mutations.js'
import actons from './actions.js'
import getters from './getters'
vue.use(vuex);
export default new vuex.Store({
modules:{
mod1:{states,
mutatons,
getters,
actions
},
mod2:{}
}
});
When I do my own projects, I usually write a sub-module state, mutations, actions, getter in a file such as:
mod1.js
export default {
state:{},
mutatons:{},
actions:{},
getters:{}
}
mod2.js
export default {
state:{},
mutatons:{},
actions:{},
getters:{}
}
Then merge several mod s into the store:
import vue from 'vue'
import vuex from 'vuex'
import mod1 from './mod1.js'
import mod2 from './mod2.js'
vue.use(vuex);
export default new vuex.Store({
modules:{
mod1:mod1,
mod2:mod1
}
});
I feel the code structure is more intuitive and clear when I write this.Normally, a sub-module will not have too many states and methods.Of course, if there are really too many state,actions,getters,mutations in a project, we recommend that you write them in separate files, and then put them in a folder to represent a sub-state management module.
By splitting up the overall store, we become more aware of state management and maintenance.
After creating the store, we need to mount the store onto vue
import vue from 'vue'
import store from './store'
var vue = new Vue({
store,
ยทยทยทยท
}).$mount("#app")
The previously defined state can then be used and managed in the build.
<template>
</template>
<script>
export default{
computed{
bookList:this.$store.mod1.bookList,
},
methods:{
addBook:book=>this.$store.mod1.commit('ADD_BOOK',book);//Note here that if you are using sub-modules in this way you need to add the module name this is mod1, if not you don't need to add it.
deleteBook:id=>this.$store.mod1.disaptch('DELETE_BOOK',id);
}
}
</script>
Summary:
Splitting store s can help us better manage the state of our projects and make our project maintenance easier and more efficient.Development between modules does not affect each other.
Okay, this time it's just a brief introduction here, this time it's mainly about how to use it.It doesn't go deep into his implementation principle, and I feel it's enough for people who are not very familiar with vue.
In the end, I would like to make it clear that, because I am used to writing kana characters, please ignore the words in the text.You'll see!