xxdavid
Pessimistic scenarios in optimistic updates with LiveView
Hi!
I’ve watched Jose’s video about optimistic updates in LiveView and read the relevant docs, and it all sounds great. However, I still don’t get how are we supposed to handle situations that end with a failure.
For example, suppose I have a list of rows (similarly as in the video), and each row has a delete button. If a user presses the delete button, I would like to immediately show some feedback. To do that, I can either optimistically hide the row (JS.push("delete") |> JS.hide(to: "the-row-selector")) or change its appearance (e.g., JS.push("delete") |> JS.add_class("opacity-50", to: "the-row-selector")). This works well. If the server then deletes the row successfully, the deletion of the DOM node is sent to the client and the client removes it from the DOM which nicely agrees with the optimistic update.
But if the deletion on the server fails (for whatever reason), I think we should revert the optimistic update (i.e., show the element again or remove the opacity-50 class). But LiveView does seem to work that way. In case the handle_event corresponding to the deletion event does not alter assigns in a way that deletes the row, the optimistic update on the client side is kept unchanged.
I’ve read the docs multiple times and I still don’t understand what is the recommended solution to this problem. I think that reverts in case of failure are inseparable from optimistic updates so I am probably missing something… How do you handle these situations?
Most Liked
rhcarvalho
You have a few options, one of them sending a JS command from the server to remove the class.
If you want to pull the add/remove class commands together in the source code you could write two defp, one for the delete and another for the “undelete” action.
Another option is assume failure to delete is unlikely and “let it crash” and let LiveView restore the state from the database.
tfwright
If you are pessimistic about the update shouldn’t the UX reflect that? IMO the whole point of optimistic updates is that since failure is so unlikely, it can be treated as exceptional. If it’s not unlikely, I would argue a better design would not hide that from your users but make it clear/graceful (nice, unobtrusive loading/error states)
josevalim
Exactly. Because the server is the source of truth, you can always “undo” the client. The default approach is that a crash will force the whole view to be reloaded, but outside of that, you could send a JS command that undoes it (as @rhcarvalho mentioned), resend the whole stream, etc.








