[Proposal] Allow existing store modules to provide additional properties like the customActions, etc.
See original GitHub issueCurrent state
Currently, if the namespace for a service resolves to the namespace of an existing store module that is not a service module, the existing module is overwritten without consideration of its setup. This behavior may be confusing for some users and probably hurts adoption, as it makes it difficult to go from a working store with its own custom service interactions to a working store that uses feathers-vuex, since they are silently incompatible.
Proposal
I’d like to propose adding a flag to the vuexOptions
object (perhaps respectExisting
) that would instruct new service-modules to take on the state/getters/actions/mutations of any modules with the same resolved namespace that exist in the store.
I’ve made a POC: https://github.com/jskrzypek/feathers-vuex/compare/feat-array-namespaces...feat-respect-existing (this is based on my PR #35)
Alternatives
The other possible fix I can think of would be to automatically nest the service module on the existing module, though this can result in unpredictable namespaces.
What do you think?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top GitHub Comments
I’ve released the
1.0.0
beta, which include the ability to customize the store and fixes the “clobbering” of state, etc. Please check out the details here: https://github.com/feathersjs/feathers-vuex/issues/40. I’m closing this issue. Feel free to reopen after trying the new version, if needed.@ellipticaldoor I found a way around that specific problem, you currently can give specific namespaces to feathers-vuex before it clobbers your existing modules, you just need to do it in the initial call to feathers-vuex.
you can do it like this:
or to illustrate the arguments to
feathersVuex
better: