Pessimistic scenarios in optimistic updates with LiveView

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.

I’d add a piece of presentation-related metadata to each item. For example a deleting? field. This way when you decide to delete a row, you do the following in your LiveView code and use the deleting? field in your template to determine what styling and logic to apply:

def handle_event("delete", %{"id" => "my_stream_" <> id}, socket) do
  item = MyApp.get_item!(id)

  socket = 
    socket
    |> stream_insert(:items, %{item | deleting?: true})
    |> start_async({:delete_item, item}, fn -> MyApp.delete_item!(item) end)

  {:noreply, socket}
end

def handle_async({:delete_item, item}, {:ok, _}, socket) do
  {:noreply, stream_delete(socket, :items, item)}
end

def handle_async({:delete_item, item}, {:exit, %Ecto.NoResultsError{}}, socket) do
  {:noreply, stream_delete(socket, :items, item)}
end

def handle_async({:delete_item, item}, {:exit, _reason}, socket) do
  {:noreply, stream_insert(socket, :items, %{item | deleting?: false})}
end

I haven’t tested the above code but it should be more or less what you need. This “pattern” is generally useful but it’s not the first thing people reach for because they’re taught that data should go straight from the database to the view which is inflexible and most of the times leads to awful code.

Isn’t that pessimistic though?

Nope. You update the UI before the actual deletion takes place. Look the stream_insert again.

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.

Depends how you define optimistic. You have a trip to the server, which can be pretty slow for some people, before you update the UI. One would assume the delete is going to be a lot quicker than a server round trip.

Thank you all for your replies!

I am dealing with a situation where the failure is not that unlikely so I would like to avoid crashing the LiveView.

@rhcarvalho and @josevalim, you both have mentioned sending a JS command from the server. What do you mean by that? Sending an event (using push_event) and executing a JS command on some element (using execJS) in a hook that listens for the event?

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)

That’s a good point. In case of an error, I would like to show an error flash for sure. However, I think that during the action, lowering the opacity of the row may be a good way to give the user some immediate feedback that something is happening, even if the action might eventually fail (reverting the opacity and showing the flash in that case). What do you think?

If it’s likely to fail, keeping it there but doing that, adding a “deleting…” or something or rather to indicate what is going on is worth it.