Use instanceDefaults before current getter has value

[midzdotdev]

Feature Request

Hi! Not sure how you guys feel about this but I think it would be great to be able to set defaults for a service's current property before it has a value. I'm assuming this would be an additional option when setting up the service plugin in the store so it could be disabled if the current null value is preferred.

If I'm using FeathersVuex in a way that is not encouraged please tell me. At the moment I'm mapping the current getter into computed. Also I haven't yet tried to modify the current object with this method. Would that work being a getter?

[J3m5]

Hi!
The "current" property will be removed in 2.0.
See #216
But you can manually set the value of the current property with its setter.

[midzdotdev]

Do you mean there will be no current anywhere in FeathersVuex? Would the best alternative be to clone the object or just set it as a variable in data?

[J3m5]

Yes,exactly.
The best and recommended alternative is to use the copy mutations.

The setCurrent mutation and currentId state encouraged use of a very limiting API. It's much more common for apps to require more than one current record. The createCopy, resetCopy (formerly called rejectCopy), commitCopy, and clearCopy mutations (since v1.x) provide a more flexible solution for implementing the same functionality. As a result of this, following have been removed from the modules:

• state: currentID
• getters: current
• mutations: setCurrent, clearList, copy

But if you still want to use the "current" API you can set it's value by using the setCurrent mutation.

[marshallswain]

Thanks, @james2mid and @J3m5. Yes! The "current" workflow is going away. It's pretty easy to create the same thing by providing custom mutations and state in the makeServicePlugin method.

Also, because the API in 2.0 has been updated to allow full JS/TS classes, you have a TON of flexibility in how things are initialized. "Getters" and "setters" tend to go best in the actual class definition, while other logic can go into the setupInstance and instanceDefaults static class methods. I'm still testing things out in my apps, but so far I'm loving the new API.

As for this issue, I already gave my two bits about the "current" workflow in the part that @J3m5 has quoted. It would probably be nice to have an example of how to implement the old workflow with custom mutations and state before we close this, but I won't put any of my time into it. There are other things which require my focus. If anybody wants to take a crack at providing an example in the docs, go for it. Otherwise, we can probably close this issue as a "won't fix".

Of course, I'm open to further dialogue, if desired.