Some questions to make sure I understand the solution proposed here. Let’s work on the counter example to have something concrete.
We have two DOM elements: the button that emits click event and the counter.
Where do I use the this.syncPushEvent? Do I attach it to onClick of that button inside mounted section of that hook? Will that prevent sending regular event?
Where do I put the code that updates the counter? in the updated section of the button hook? How do we know we should not update the counter in the meantime?
I think that the solution LiveView currently uses for buttons can work only because the event and state update are for the same DOM element. In case of optimistic UI, we should be able to change multiple parts of the page with a single event.
I was thinking about a different solution using client and server clocks.
- JS part has the vector clock
client.clock. The server has its own, let’s call itserver.clock - Server increments its own clock every time it sends new state (e.g. an event may originate in the server from PubSub). That part is really important and AFAIU is not part of the current solution with
view.ref. - I am marking UI elements that I think should be lazily updated e.g:
<p phx-update="optimistic"><%= @counter %></p>. - I am attaching hook to emitted LiveView event. E.g.
<button phx-click="inc" phx-hook="Button">+</button> - In the hook, there needs to be a section for running this custom code right after event gets sent to the server:
Hooks.Button = {
onEvent("inc") { //should be called right after "inc" event is sent
counter = getElementById("counter")
mark_updated(counter) //add something like `phx-clock="#{client.clock}"` to the counter
... //increment the counter to achieve instant update
}
}
- When state update comes from the server, it has the server.clock.
if server.clock > client.clock, do: client.clock = server.clock
// when updating elements
if element.phx-update=="lazy" && server.clock >= element.phx-clock do
normally_patch_the_DOM()
else
ignore()
end
I believe that solution is much more general because it takes into consideration both events started by the browser and server.
It can’t replace the current solution for buttons with view.ref because you need to precisely know which client event that button is handling.
Also without separate clocks, you can’t handle optimistic updates originating on the server.
Does that make sense?
The machinery might seem complicated but I wanted it to work on examples like this:
- User quickly increments counter twice. JS optimistically sets it two. Counter = 2 Client clock = 2.
- Server processes first event. Sends Counter = 1, Server clock = 1. Since Server clock is lower than client clock, it doesn’t do the update (so the counter doesn’t go back)
- Server processes the second event. Sends Counter = 2 Server clock = 2. Now the counters are the same so we replace the number 2 with number 2 (everything is fine)
This works even if server-side increments the counter a bunch of times.
