Reverting a offline mutation

[MitchellMonaghan]

Is your feature request related to a problem? Please describe. I have a application using offix. Instead of pushing changes when coming online the user can manually push changes. The user can also view the changes they have made locally. When viewing changes, I would like a user to be able to delete a local change.

I have attempted to use offlineStore.removeEntry and queue.dequeueOperation. This seemed to modify the indexedDB but did not modify the in memory state. The state was not properly reverted until I refreshed the page. Is there a provided way to do this? Is this something that should be added? How would I create a temporary solution for this problem?

Describe the solution you'd like I would like a single function, that I could pass the changeset/operation/qid and both the appropriate indexedDB changes are made and the in memory state is recomputed.

Describe alternatives you've considered I have considered making a dummy change, to first commit a change that would be the opposite/revert so I could properly set the in memory state. Then use dequeueOperation to remove the dummy change and the change I was originally trying to revert. I just wanted some guidance on the best way to do this before going down that road.

I don't see any documentation on this and I can't find any api doc's about functions provided by offix scheduler like dequeueOperation or offlineStore's removeEntry. I'm not sure when these should be used or one vs the other.

[wtrocki]

This seems to be a custom case outside offix scope. You might get much better results with the:

• Apollo-Link-Queue
• Apollo-Cache-Persist

Those two + your logic for letting users to review the changes are much better and easier way to get this done.

[MitchellMonaghan]

I took a look at both packages. Just to be clear I already have the manual push working just fine with offix and a custom networkStatus object. I think that was the intention behind Apollo-Link-Queue being suggested?

I'm specifically looking for a way to revert a offline mutation. I still want the features of offix such that remote server data is stored separately from local changes and then are merged into a computed in memory state. I'm under the assumption that if I were to use Apollo-Cache-Persist I would lose this functionality. I think its important to be able to pull down new remote data and be able to blow away the old data with out any worries.

I saw the video here and it also lists the users offline mutations. I didn't think simply deleting a mutation would be out of scope. https://www.youtube.com/watch?v=CrYinCtTHds&ab_channel=WojtekT.

If I use dequeueOperation to delete a operation is there a way to force offix to re-compute the in memory state as it does on page loads without actually doing a page load? Otherwise I will probably go with my suggested work around above.

Maybe I'm dumb and I don't see how the two packages you suggested would be helpful.

Thanks, Mitch

[wtrocki]

Let me think.. queue is managed automatically and it is available to call from client.

https://github.com/aerogear/offix/blob/master/packages/offix/client/src/ApolloOfflineClient.ts#L42

This will allow you to do it in offix. Trick is that generally we do not support this because if there is some other operation happening queue could get into wrong state. Then queue contains raw changes which means that if one item is removed other in queue others will be affected. - removing create wil affect edits.

If you are aware of those challenges and handling this well in your code then operations on queue should be good for you

[wtrocki]

Also you still going to get optimistic responses on Apollo visible. Those are separate to queue..Means that after user reviews it you need to wipe out all optimistic responses that will be now orphaned since queue items for those might have been removed

[MitchellMonaghan]

Yea for something like create, with other changes on top of that same entity I was thinking that a user could only revert the last change for a given entity so order is preserved and I was going to handle that complexity in my application. So you could not revert a create with out first reverting the other changes on that object.

I wasn't aware apollo stores optimistic responses in a queue I thought it just mutated the in memory data in place. I guess I will just try my suggested work around above and test if orphaned optimistic responses will cause any issues or find a way to clear them.

Thanks for your help.

[MitchellMonaghan]

I gave this more thought and I may have a better idea. I noticed that the queue also has updateOperation. What if instead of actually deleting anything I just update operations in a way that they are simply flagged. My application would no longer show flagged changes, changes would become flagged when reverted by the user. When the user reverts a new offline mutation would be made to properly set the new in memory state. This would accomplish all the same goal while avoiding any orphan issues, it does keep a lot of useless changes in memory but I think that's fine.

[MitchellMonaghan]

My above solution was sufficient for my use case.