[Proposal] Allow existing store modules to provide additional properties like the customActions, etc.

[jskrzypek]

Current 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: jskrzypek/feathers-vuex@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?

[dortamiguel]

Maybe feathers-vuex services can be prepended by and underscore or something like that?

Although a solution like this is not very elegant...

[jskrzypek]

That's not the best because then it would make it more awkward for consumers to use in the simple example where they have no custom modules, etc.

One reason I thought about this issue was that I find the current solution with the customActions, etc added to the options passed to the service or the global modules options to be awkward and hard to maintain.

Right now to use feathers-vuex alongside existing custom modules or to integrate it with existing actions/getters/mutations/state, we have to migrate all of our existing store logic moving out of the clean structure dictated by vuex and into wherever we are calling the feathersVuex plugin.

I want to be able to manage the rest of my store as normal and then slowly add logic that exposes or integrates the actions/getters/mutations/state that feathers-vuex builds for my services.

[dortamiguel]

Maybe you can rename the modules that you already have until you fully migrate to this solution.

Other problem is that you have to be careful of not naming a store module like one of your services.

[jskrzypek]

@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:

const feathersClient = feathers()
  .configure(hooks())
  .configure(socketio(socket))
  .configure(auth({ storage: window.localStorage }))
  .configure(rx(RxJS, {idField: '_id'}))
  .configure(feathersVuex(store, {
    idField: '_id',
    auth: {
      userService: '/users'
    }
  }, {
    'messages': { namespace: 'feathersMessagesServiceModule' },
    'users': { namespace:  'feathersUsersServiceModule' }
  }))

or to illustrate the arguments to feathersVuex better:

const feathersVuexOptions = {
  idField: '_id',
  auth: {
    userService: '/users'
  }
}

const feathersVuexModules = {
  'messages': 'feathersMessagesServiceModule', // or { namespace: 'feathersMessagesServiceModule'  },
  'users': 'feathersUsersServiceModule' // or { namespace:  'feathersUsersServiceModule' }
}

const feathersClient = feathers()
  .configure(hooks())
  .configure(socketio(socket))
  .configure(auth({ storage: window.localStorage }))
  .configure(rx(RxJS, {idField: '_id'}))
  .configure(feathersVuex(store, feathersVuexOptions, feathersVuexModules))

[marshallswain]

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: #40. I'm closing this issue. Feel free to reopen after trying the new version, if needed.