I worry that optimistic updates is going to become trendy and applied to more software, but without any plan for the "sad path" - failed to sync, sync conflict, etc. Get ready for a whole new era of race conditions and frustration!
based on my experience, this is a great description of the sync implementation in many already widely deployed products (say, off the top of my head, OneNote, OneDrive)
https://zero.rocicorp.dev/docs/connection
Errors and connection are handled in a centralized place so that they automatically get applied to all paths.
Errors immediately disconnect the app and trigger UI. Writes are no longer accepted. After 1 minute of of failed connection attempts, same happens.
This formalizes and enforces the common pattern in popular sync-based apps of detecting disconnects fairly aggressively and warning the user.
In the local first world you might have navigated away already and created 3 more issues of which 2 more failed because of schema drift or other conflicts. And you might have edited one that was deleted. And now you need to figure out what exactly to tell the user - or what not to tell them.
Warn the user that if they leave the website their changes won't be saved remotely.
Our application uses classical "foreground update" paradigm, but each API call automatically shows an error to the user and returns him/her to the same place where error originated to fix the input and/or retry. As a bonus, we also automatically show progress indicator for any HTTP request that takes more than 1s (which is rare).
This is as simple as:
await context.api.explorer.rename(
{
objectKey,
name
}
);
// objectKey: ApiTypes.ObjectKey
// name: string
- If that request succeeds, you know that the new name has been durably committed to the database.
- If it fails because the new name is not unique, the user sees the error, and can then enter a different name before retrying. The key is that the UI context is preserved during API failure, so everything the user had entered is still on the screen.
- If it takes more than 1s, the user sees a progress indicator which he/she can click to cancel the operation. This also returns him/her to the original UI.
The magic is in the `rename` itself - it was auto-generated from our back-end API such that it wires into our error reporting and progress UI.
Exhaust all other optimizations before lying to your users about what just happened.
I would not implement optimistic resolution in key information, prices, for example. They live in the server and backend should keep the total control in the client side, even feedback response time.