I was delighted to read yesterday that the 1.0 version of liveview has gone live!
so I tried it out straight away and… 
i have an app that is very msg-heavy and quickly changes things on the client side, and after the switch to the 1.0.0 liveview everything just stutters.
apparently the frontend dropped a lot of messages if they come in quick succession. kind of like debounce does.
does the 1.0.0 version have this enabled by default?
or is there still debug code in there?
i’ve tried a few things now, and all 1.0.0-x’er versions have this too. 0.20.17 doesn’t show this behavior. it felt like the fastest version was 0.17.14 
We don’t debounce/throttle, but what we do lock interacted elements with loading states (ie phx-click-loading) and prevent updates/interactions to them until the acknowledgement for that interaction comes back from the server. Are you doing blocking work your LV handlers that could otherwise be async? If you truly want the events to be send unbounded (and thus would start queuing on the server) you could make a hook with a click listener that does pushEvent. It’s not clear what kind of things you LV handlers are doing so it’s hard to say what you really want in this case, but the default behavior is definitely how LV should be behaving.
1 Like
for example, i have hooked mouse events in a small game that moves very simple objects. (div: left, top)
the movement messages also all arrive at the client from the server, but they are only displayed again if you stop the mouse movements briefly or only move very slowly. with continuous movement, nothing moves.
that’s why i thought that if the same actions occur on the same element within a certain period of time, like every <20ms, they would be dropped. which looks very silly in an animation.
as i said, up to 0.20.17 this was no problem at all…
1 Like
very strange!
after two days of trying and very strange effects, i have now found a solution that works for me, although i don’t think it’s meant to.
since the mouse hook is bound to the document to control various things, it also hung on the first div after the body starts. since a mouse movement with the button pressed changes some things, the behavior described above resulted in a mouse movement. the mouse events also all arrive, as can be seen from the fact that the temporary “data-phx-ref-loading” and “data-phx-ref-lock” were permanently incremented when the mouse was moved, but the graphics stood still until the mouse movement slowed down. in this constellation, however, the changed parameters did not change anywhere.
when creating a testapp to recreate this behavior, i noticed that the placement of the hook is important, i.e. how deep or how far at the end the hook is placed. if the hook is placed in the middle of the hierarchy, all those above it are adjusted, and all those below it are not. looked very funny 
also, and this is my solution now, if i place the hook at the end everything is fine, very strange. i have now added a div with the hook at the end right before body is closed and everything is fast again like with 0.20.17 …
