Feature: per-instance pending status

[hamiltoes]

Summary

Adds per-instance, per-method pending status to FeathersVuex per discussion in #518

PR includes new state, new getters, new mutations, new BaseModel geters, and modifies the actions for create, update, patch and remove to call the new mutations.

What Problem am I Solving?

Currently, FeathersVuex tracks pending status for create, update, patch and remove per service... but only in an all-or-nothing way. This means that if any model is pending, the status for that service is set. As expressed in #518, it can be useful to have a status for this model is patching and that model is removing, or similar.

In my opinion, the most useful new thing in this PR is that the BaseModel now has the following geters:

• isCreatePending
• isUpdatePending
• isPatchPending
• isRemovePending
• isPending - true if any of the previous four statuses are true

Implementation

I decided to use Arrays of ids in the Vuex state for maintaining the pending status. I chose to use Arrays instead of Objects because for each id, if a method is called multiple times, an Array can track that there are multiple requests in progress and therefore the status will not clear until the last request finishes.

I decided to make the status part of the Vuex state instead of part of the Model class to keep the status in-sync between clones and originals. E.g. when a clone is modified and patched, the original model's status indicates that a patch is in progress.

❤️

[hamiltoes]

Added tests for state, mutations and getters.

Still need:

• tests for actions and BaseModel
• docs

[hamiltoes]

Added tests for actions and BaseModel

Still need to add documentation.

[J3m5]

A Map would have been nice for that... Maybe when Vue 3 will be the main supported version....
Anyway, thanks again for your contributions, it's awesome!

[fratzinger]

I like it! That's pretty awesome. I looked into it and have three annotations:

1. The setIdPending and unsetIdPending should catch a null id for a multi patch/update/remove.
2. Maybe a isSavePending getter would add a little bit of sugar like the save-method
3. What about also adding error-handling instance-wise? I think this could be useful and would be a consistent addition

[hamiltoes]

A Map would have been nice for that... Maybe when Vue 3 will be the main supported version....

@J3m5 could you help me understand how a map would be used here where an object wouldn't work?

[hamiltoes]

Thanks for the feedback @fratzinger !!

1. The setIdPending and unsetIdPending should catch a null id for a multi patch/update/remove.

setIdPending does ignore IDs that aren't typeof string or typeof number. I figured unsetIdPending doesn't need this check because when it goes to look up the index for null or undefined it will fail.

Or do you mean the patch/update/remove actions should all handle multi and pass all IDs to setIdPending?

2. Maybe a isSavePending getter would add a little bit of sugar like the save-method

I like this. Should just be an or of create/patch/update pending status? And should we keep isPending which is an or of all four? So many pending status getters! Ha

3. What about also adding error-handling instance-wise? I think this could be useful and would be a consistent addition

Yeah this should be easy and a straightforward addition.

[fratzinger]

setIdPending does ignore IDs that aren't typeof string or typeof number. I figured unsetIdPending doesn't need this check because when it goes to look up the index for null or undefined it will fail.

okay, perfect. As setIdPending has it, unsetIdPending doesn't need to check, I guess.

Or do you mean the patch/update/remove actions should all handle multi and pass all IDs to setIdPending?

I did not think of that. I think that's what the service-wise is${Patch|Update|Remove}Pending is for, isn't it? :)

I like this. Should just be an or of create/patch/update pending status? And should we keep isPending which is an or of all four? So many pending status getters! Ha

It's hard find the cut between to too little and too much sugar 😄 For me isSavePending feels natural. Also, in my applications I built a service-extension to have a isPending getter for all pending-states. So I would go with this as well.

Yeah this should be easy and a straightforward addition.

Maybe we can implement this after this PR, I don't know. Let me know, if I can help :)

[marshallswain]

Looks exciting, y'all! Let me know when you are ready to merge!

[hamiltoes]

I've added isSavePending sugar and tests for it. I've added docs for all new state, mutations, getters, and BaseModel attributes.

In my opinion, per-instance error handling should be a separate PR.

Marking this ready for review.

[marshallswain]

Finally getting this merged. Thank you! This adds huge time-saving features.