Add config options per service

[fratzinger]

Hey Marshall,

while changing the docs some points came in my mind:

1. why no whitelist and paramsForServer per service?
2. Why is there a Modelname, instanceDefaults and a setupInstance. Imo it should become deprecated because it just bloats the options.
3. For the authentication, why is there no servicePath option? Recently I wanted to add versions to my auth. For example app.service("api/v1/authentication")

I think that are small but useful changes. What do you think? If you're okay with it I would be happy to make a pull request with these added options in code & docs respectively deprecation warning in docs.

[marshallswain]

1. why no whitelist and paramsForServer per service?

Because I haven't needed it, yet. ;)

2. Why is there a modelName, instanceDefaults and a setupInstance. Imo it should become deprecated because it just bloats the options.

I don't have any comprehension of why you say it bloats the options. Maybe you say this because you're thinking that everything can go inside the Model class?

3. For the authentication, why is there no servicePath option? Recently I wanted to add versions to my auth. For example app.service("api/v1/authentication")

Same as number 1. I only build the things that I need and give them to everybody as a gift. ;)

[marshallswain]

(Also, at the time I made the plugin, I believe FeathersJS was hard-coded to use /authentication, but I don't remember.)

I'm open to adding both features to feathers-vuex if you want to champion the update.

[fratzinger]

Yeah, I'm happy to do so. But it will take some time for the features, docs & tests.

I don't have any comprehension of why you say it bloats the options. Maybe you say this because you're thinking that everything can go inside the Model class?

If I get it right a Model is required for the makeServicePlugin function. If not, forget everything I say.
Having two places where you can define the exact same thing: ìnstanceDefaults and setupInstance sounds ambiguous to me. You're right, bloating the options is definitely a smaller problem here. But debugging and error handling could be difficult with that.

If Model is required, instanceDefaults and setupInstance on the service feel like leftovers to me.

[marshallswain]

Ah. I see what you're saying about the ambiguity. I implemented the instanceDefaults before starting on the data Model feature, so I wanted to keep backwards compatibility for anybody not using models. My preference at this point is to move it to the model and remove it from the service. That's something we can put in the next major release, I imagine.

[fratzinger]

My preference at this point is to move it to the model and remove it from the service.

That is what I thought 👍 I don't want to interfere too much. That's why I asked first. Maybe I'll find time to change the docs and make a PR for that, too.