What exactly is namespacing of modules in vuex

2020-07-03 09:08发布

问题:

I have recently started with vuex.

The official docs explains well what modules are but i am not sure if i understood the namespaces in modules right.

Can anybody put some light on namespaces in a better way? When/why to use it?

Much appreciated.

回答1:

When you have a big app with a very large state object, you will often devide it into modules.

Which basically means you break the state into smaller pieces. One of the caveats is that you can't use the same method name for a module since it is integrated into the same state, so for example:

moduleA {
  actions:{
    save(){}
  }
}

moduleB {
  actions:{
    //this will throw an error that you have the same action defined twice
    save(){}
  }
}

So in order to enable this you have the option to define the module as namespaced, and then you can use the same method in different modules:

moduleA {
  actions:{
    save(){}
  },
  namespaced: true
}

moduleB {
  actions:{  
    save(){}
  },
  namespaced: true
}

and then you call it like this:

this.$store.dispatch('moduleA/save')
this.$store.dispatch('moduleB/save')

Please note that it might complicate things a bit if you're using mapGetter or mapActions since the getters are now in the form of ['moduleA/client']

So use it only if you really need to.



回答2:

To using it, we can pass the module namespace string as the first argument to the helpers so that all bindings are done using that module as the context. The above can be simplified to:

...mapGetter('moduleA/client', {
    a: state => state.a
});


回答3:

I'm not an expert in vue.js but as I can see in the docs namespacing can be used to modify the path access to a module's getters/actions/mutations.

By default namespaced: false all of the getters, actions, mutations are available gloabally by the different modules so if you want to use the same getter/action/mutation in different modules you must flag them as namespaced: true, otherwise an error will be thrown.

Another use of this is to organize your getters/actions/mutations in different paths (the one that a module is registered at); this is very useful in large projects because you can know right away where the getter/action/mutation is defined so its easier to locate them.

HIH