While I was looking through the examples of the 4.0 alpha version, I thought that when you have a large store it can become a bit annoying to declare getters and actions locally in every component you need. So I think it would be nice to have a some sort of a helper function that returns only (hopefully typed) store module you want to use.
const myModule = useStoreModule("module namespace")
console.log(myModule.state) // returns state of a module etc.
Otherwise we could add a “namespace” param for the useStore function that would resolve the needed module
const myStore = useStore() //returns entire store
const myModule = useStore("namespace") // returns module
Also having a some sort of "store mapper" would also be nice imo.
const myAction = useStoreActions("path to action")
I guess just wait as I expect the mapGetters and mapActions etc helpers will get ported over soon (or already had?)
Thanks for the feedback! Yes, I think we should have helper functions for composition api as well.
While retrieving module as complete set might be nice, I think we should start off with composition api version of mapXXX helpers named useXXX. So basically something like this.
const increment = useActions('increment')
We should obviously think about the best way to retrieve multiple actions in this case though.
I think it's going to be hard to support mapXXX inside composition api due to how it's implemented (it relies on this context).
We should be rethinking how Vuex should work with Vue 3, and it will probably be Vuex 5. But at the moment, goal for Vuex 4 is to provide smooth migration from Vuex 3 to Vuex 4 as possible. Regarding that, it make sense to provide very similar API of mapXXX helpers first 👍
Thank you @kiaking
At the moment we are using this library, it works well in the meantime. Perhaps you guys could elaborate to speed up the process?
https://github.com/u3u/vue-hooks
@hxhieu you might be interested in a library that I wrote recently
https://github.com/owlsdepartment/vuex-typed
It has a helper like you proposed
@kiaking @h311x Why Cant Just Import File That Contain Store and Just Call Store.commit or Store.dispatch.
import { Store } from '../store'
.
.
.
.
Store.commit('doSomething',val)
@bekalshenoy you are not wrong but that low-level and undesirable and unmaintainable approach.
Do you actually use it on your production code? i.e have you ever tried Vuex helpers?
With your suggestion, if we need to pass the state or an action to the template binding, then we will need to write scaffolding code i.e computed() and methods etc.
Also when to deal with Vuex namespaces, the low-level API above will even introduce more lengthy hard code strings.
Vuex helpers done all of those under the hood of course but they are maintained by the package and becomes a single point for bug reporting and improvement instead of everyone writing their own wrapper code.
@bekalshenoy You could do that if you're not doing SSR. It's valid approach. However, that's going to cause state pollution in SSR environment. It's really better to stick with using this.$store or useStore to prevent any unexpected behavior.
Seems like this is a duplicate of https://github.com/vuejs/vuex/issues/1579.
Given how little code is required for a wrapper such as vuex-stores, and the fact that importing the store does not work correctly for cases such as SSR, I agree that it's better to leave this in userland for now.
It would be nice if Vue 5 provided some useful abstractions to avoid using namespaces directly, though.
Yea I'm keeping this issue open since #1579 is not exactly the same feature, this issue proposes more like vuex-stores like feature and I'm thinking it might be worth considering after we implement useXXX helpers 👍
I just published a quick dev.to post about creating a useStoreModule composable! If you find this helpful @kiaking, I can create a PR?
Article: https://dev.to/baryla/vue-3-vuex-4-usestoremodule-composable-1e83
Gist: https://gist.github.com/baryla/dab7ebb745623dc70ff2d21f474591a1
I just published a quick dev.to post about creating a
useStoreModulecomposable! If you find this helpful @kiaking, I can create a PR?Article: https://dev.to/baryla/vue-3-vuex-4-usestoremodule-composable-1e83
Gist: https://gist.github.com/baryla/dab7ebb745623dc70ff2d21f474591a1
@baryla love this idea! it fits smoothly in new flow with setup function and gave me some cool ideas ;)
Most helpful comment
Thanks for the feedback! Yes, I think we should have helper functions for composition api as well.
While retrieving module as complete set might be nice, I think we should start off with composition api version of
mapXXXhelpers nameduseXXX. So basically something like this.We should obviously think about the best way to retrieve multiple actions in this case though.
I think it's going to be hard to support
mapXXXinside composition api due to how it's implemented (it relies onthiscontext).We should be rethinking how Vuex should work with Vue 3, and it will probably be Vuex 5. But at the moment, goal for Vuex 4 is to provide smooth migration from Vuex 3 to Vuex 4 as possible. Regarding that, it make sense to provide very similar API of
mapXXXhelpers first 👍