needing a name spaced service plugin in the store state

@marshallswain I see you have been busy with more releases just want to say much appreciated!

So…I’m using my version of makeServicePlugin per below. When I ‘register’ each plugin in the store (see below) I get a property in the store.state with the same ‘name’ as service. This has been fine but I’ve been using the same property to store other values. So far no ‘collisions’ but I see this as way bad. I either need to namespace my stuff into another property say with a leading _ or I need to namespace the feathers vuex service plugin stuff in the .state. The getter/mutations/actions are fine (no conflicts don’t really need namespacing).

I guess what I need to do is use modules? They will create some kind of namespace in .state if I understand correctly? I’m not grokking how to do that with fv store plugin. I can’t find it in the fv api but it seems as makeServicePlugin has the store as it’s only argument https://vuex.vuejs.org/guide/plugins.html. No way to tell it to register as a module under some context. So… can you give me a pointer or two or what you’d consider best practice for isolating that state stuff feather-vuex plugins create from the rest of the store.state? What I’d really like to do is have all my fv plugins use the same context/prop like ._feathers-vuex. I mean like so store._feathers-vuex = {pluginservicename1:{},pluginservicename2:{}....}. Like so would mean 0% chance of namespace collisions.

import fVuex from 'feathers-vuex'

const addFeathers = async (store, db, opts = {}) => {
  const { makeServicePlugin, BaseModel } = fVuex(db.api, { serverAlias: opts.alias || 'api' })

  function createModelClass (name, Base) {
    const nameIt = (name, cls) => ({ [name]: class extends cls {} })[name]
    class Model extends Base {
      constructor (data, options) {
        super(data, options)
        this.modelName = name
      }
    static modelName = name
    }
    return nameIt(name, Model)
  }
  // registering plugins dyanmically here
  db.collections.forEach(name =>
    makeServicePlugin({ Model: createModelClass(name, BaseModel), service: db.api.service(name) })(store)
  )
}

export default addFeathers
export { addFeathers }

[dkebler]

Well finally, all these components are based on quasar (thus the q- tags). The cool one is the form component which is a dynamically rendered template based on a schema object which one gets from backend via a special ‘schema’ get id and a beforehook in the backend. You change/add a schema prop in the schema file in the backend and boom the document form has a new field and maybe behaviors. No change in the frontend code at all! I guess I need to get all this published at github with some explanation/documentation. But I am two weeks from an install of a 48 switch/circuit lighting application for which I wrote all this and need to get that done first. Anyway thanks for all your efforts. FV has been a critical piece of making it all work. So thx one more time.

[dkebler]

I wrote a whole nest of components service => collection => document => form the service and collection component have slots for adding service/collection related stuff around the collection. I also have a totally separate data system for passing json packets to/from a backend socket. I wrote get/set functions for the store that manaage a reactive any depth nested object (with a root namespace) and so I have a similar mixin for getting and setting those values. So what you say. “One of my plans for Feathers-Vuex is to decouple it from Feathers so that other sources can be used by building plugins that mimic the current Model API.” that is of great interest to me.