Restoring optimistic response after application restarts?

[wtrocki]

@wora/offline-first support restoring optimitisic responses into cache?
Do you see persisting optimistic response layer in the future or library will apply this some different way?

[morrys]

@wora/offline-first is not in charge of managing the status of the application that uses it, but makes it easier to manage requests that are sent to the server when you are not online.

This through a utility function to know the connection status addNetInfoListener and a function to insert the request in the queue of offline publish requests.

Finally, when the status returns online, the queue execution workflow is executed and the library allows simple options to extend the default behavior of the extension.
https://github.com/morrys/wora/tree/master/packages/offline-first#options

This workflow will soon be well documented.

[sibelius]

I think this should be in userland

this is too specific to be in a package

we can have another package that provide common offline behaviors

import { restoreOptimisticResponse } from 'common-offline-patterns'

that would handle this for apps that needs this

[morrys]

maybe you wanted to refer this question to @wora/apollo-offline. Optimistic response layer is the way optimistic responses are handled by the apollo inmemory cache.

[wtrocki]

For exmaple:

1. I'm creating new item when offline
2. I'm editing the same item

With wora the second edit is sending an invalid id - it will send an optimistic response id.

[wtrocki]

Reason, why I'm asking, is that there are couple things that can be provided to enable wora to be the really comprehensive library. I was always dreamed of having a fully offline workflow. I really like @sibelius suggestion!

I have couple ideas to help here to make this better, but I will love to first know the motivation. Any reason why developers need to handle those cases in execute?

[sibelius]

I have more knowledge on relay

I think all mutations called when offline ("optmistic updates") are already persisted to relay store, so we don't need to restore them when application restarts, they are already there

what happens if that we rollback optimistic updates that fails to complete on server

More on this here https://dev.to/mattkrick/distributed-state-101-why-i-forked-facebook-s-relay-1p7d

for me offline events are much like optimistic events where the server event is very delayed

[morrys]

@wtrocki this is my lack of documentation that I will update.

What I recommend to those who intend to handling offline is:
When a new item is created by request the id must be generated in the browser to use it in the optimistic response

with this simple requirement we obtain a remarkable resolution of problems and an efficiency in the processing of responses and data stores.

https://github.com/morrys/react-relay-offline#requirement

[wtrocki]

WOW, it is nice to see that relay actually gives such a feature. In Apollo, things look differently. Optimistic responses are not kept/persisted but I'm hoping to fix that so the behavior will be the same for Apollo/Relay! Thanks.

[morrys]

on this subject I would like to talk to those who deal with apollo cache inmemory.

In a first version I also persisted the optimistic layer but the problem is another.

My approach to both relay and apollo is the same:

• simulate optimistic insertion and recover changes to the backup store
• I persistently enter the information in the store and save my sink changes

In relay it is possible, after restarting the application, to use the backup information to roll back the store (not in all use cases). In apollo it is not possible using native functions.

[morrys]

on the right is what you can do with the only information contained by offline mutations

for the moment it is present only in the example of relay project but I hope soon to include it also in the apollo one.