Vuex: Inject store module into component instead of full store

[etki]

What problem does this feature solve?

I'm developing a component that requires Vuex, but may be be distributed across several applications, so i don't know in advance where exactly component state will be managed - will it be this.$store itself or something like this.$store.somePage.specificComponent. I don't want to pass store as prop, so, ideally, i would like to let end user to set specific store module when he or she instantiates my component.

What does the proposed API look like?

<!-- this passes $store as usual - no backward incompatibility -->
<my-component />
<!-- this passes $store.somePage.specificComponent as $store for my-component -->
<my-component v-store="somePage.specificComponent" />

Disclaimer

I couldn't find any issues like this, but i guess that issue of that kind should have been already raised - feel free to point me in that direction.

[ktsn]

I wonder why don't you provide Vuex module with your component so that the user can register it in their Vuex store to use your component?

I have created some component with the approach, for example https://github.com/ktsn/vuex-modal. It seems a common pattern to publish a component depending Vuex store.

[etki]

@ktsn i will do exactly so, but i don't know under which name my module will return back into component. As far as i understand, your component enforces end user to include it in non-namespaced fashion, occupying state.stack and getters.currentModal (i may be wrong here if i have false assumption of how Vuex works). I want to give end user an option to prevent such name clashing by allowing to add it as a namespaced module of any depth, so end user could do this:

import StoreModule from 'etki-custom-component'

new Vuex.Store({
   modules: {
     thatFooterThing: {...StoreModule, namespaced: true}
   }
})

but in such case i have to guess thatFooterThing in my component, so end user may help me with proposed directive v-store. Otherwise i have pretty decent chance to clash with something else since i use title and other common names in state and getters.

[ktsn]

namespaced: true just adds prefix for all getters/actions/mutations name in the module. So you can do the same thing in your module to avoid naming conflict.

occupying state.stack and getters.currentModal

state must not conflict with the userland module because it clearly separated with modules. getters.currentModal is indeed registered in global namespace but you can add any prefix to avoid conflict.

I understand it is a bit annoying for library developers. Maybe we need to provide another namespace config to set its value in the module.

[etki]

@ktsn

getters.currentModal is indeed registered in global namespace but you can add any prefix to avoid conflict.

The point is it is not me who adds the prefix, but end developer. Moreover, i expect that several instances of my component may coexist on page, so i can't even hardcode it and tell everyone else to use this very prefix.

I think the option to deliberately isolate yourself in particular namespace is very useful and would simplify life a lot.

[KostiantynKopytov]

I recently started to use vuex and was also wondering why working with global store even legal :)
It makes sense for root page components to access global store and pass its (sub)modules to child components but not allowing child components to access global store directly. It's same deal as working with global variables which should be generally avoided, isn't it?

[slimee]

Hello,

In the same kind, I face this case (maybe it's a design problem?):

2 components: Parent & Child
1 namespaced module used two times in the store (same action/getters/mutation but differents state instances)
Child appears two times inside parent template

Linking the good state to the good component is OK via prop
But mapping correctly getters, actions and mutations seems impossible: using createNamespacedHelpers in Child is like hard-coding every Child instances to the same module.

But you very much for developping this beautiful library :)

[mjmnagy]

any news on this?

[kiaking]

Closing the issue due to inactivity for now. Vuex is currently a single state tree management system, and we need single store to manage its modules for things like SSR as well.

You can always pass the namespace maybe to the components to let them know what module it should be using.

However, we're planning to do better on this part with the next iteration of Vuex.