Reverting a offline mutation about offix HOT 7 CLOSED

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.

from offix.

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

from offix.

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

from offix.

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

from offix.

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.

from offix.

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.

from offix.

My above solution was sufficient for my use case.

from offix.