Is Optimistic UI now possible with Phoenix LiveView?

[pillaiindu]

A post from Dev Talk directed me to this todo demo at SvelteKit. I was surprised how slow the response of creating and deleting a todo was, considering the performance of Svelte. Then I opened the network tab and I realized it was sending requests to the server on my slow connection.

I realized it needed Optimistic UI updates / Latency compensation to be instant. Then I remebered that I had asked about the possibility of Optimistic UI in LiveView in Feb 2019.


How do you achieve Optimistic UI in Phoenix with LiveView?

Elixir is fast, but not everyone on the planet is having a fast internet connection. Optimistic UI (previously called Latency Compensation) is a concept first introduced by Meteor framework. Let me explain what Optimistic UI / Latency Compensation is: For example you’re sending a message through a chatbox. In traditional way: You typed the message pressed enter or clicked send button the browser sent an ajax request the data was stored in the database at server the server sent an OK respons…


I asked that question when LiveView was new. Now LiveView has matured and there are a couple of books on LiveView (one from Pragmatic Bookshelf and another one from Groxio), and a detailed video course from Pragmatic Studio.
What is the scenario now? Can LiveView make Optimistic UI updates, or we still need to use GraphQL, Apollo, etc to have Optimistic UI updates?

@chrismccord


[BartOtten]

You should be able to use phx-disable-with for optimistic UI on the client. However, that seems to be only applicable to the element you are interacting with. Maybe it’s a start though…Can’t check it myself as I am on mobile.

[pillaiindu]

I think “phx-disable-with” has a good use case. When you want to prevent user from performing an action which is already performed but the feedback is not yet arrived from the server.
You can use it for enhancing the user experience and preventing user from making a mistake (performing the action twice which s/he intended to perform once), but I don’t think it’s an alternative to a full blown Optimistic UI.

[al2o3cr]

@pillaiindu

Can LiveView make Optimistic UI updates, or we still need to use GraphQL, Apollo, etc to have Optimistic UI updates?

IMO LiveView makes a totally different set of tradeoffs to run most/all of the logic on the server-side: GraphQL + Apollo is designed to run much of that logic on the client side.

Translating to physical objects, this question is like asking “can Airplane now dive to the bottom of the ocean, or do we still need to use Oxygen Tanks and Submarines?” Both things are designed for their particular use-case, and while similar they aren’t interchangeable.

[pillaiindu]

@al2o3cr

can Airplane now dive to the bottom of the ocean, or do we still need to use Oxygen Tanks and Submarines?

Thank you for your answer! I loved the anology.

But maybe people like @josevalim and @chrismccord are able to create an airplane which can submerge in the ocean, at least in the BEAM world.

[andreaseriksson]

On the other hand, optimistic ui:s comes with some drawbacks. Just because you add/or delete an element in the interface and it instantly appears/disappears, you cant be 100% sure the server made the change (hence optimistic).
Besides that, you can sprinkle in some js to make the client side snappier when removing resources and other cases like that.

[kelvinst]

@andreaseriksson

Just because you add/or delete an element in the interface and it instantly appears/disappears, you cant be 100% sure the server made the change (hence optimistic).

Plus the fact that it requires you to implement a lot of duplicated logic on server and client. With LiveView you can be productive because you are not reimplementing a lot of stuff over and over. With SPAs you implement a lot of validations on the server for data consistency reasons and you implement the same validations on the client to be able to actually be optimistic without giving the user a lot of false positives.