The state of the initial mount is lost after the render completes, this is the same as a request to a controller. The js then initiates the new request which will become the websocket connection managed by the liveview process on the server. For recovery after a disconnect it will first build the initial state again in mount, then there is code that will resent the form content if any to update the state on the server.
1 Like
Yes, that state is lost today, but does it have to stay that way?
After dispatching the rendered HTML the code could tuck away the state somwhere the second call may retrieve and resurrect instead of rebuilding it from scratch. How the second request is handled proves that it is possible to do do extra things after dispatching the rendered HTM including staying alive for a while longer. I can think of several mechanisms by which to get the state transferred from the process for the first to the process for the second request, including ones that will cross machine boundaries if required.
Iām happy to skin this cat another way if my use-case is that unique. I simply thought some might find it useful if instead of assuming mount/3 will be cheap enough to repeat the platform did what it could to retain the state built to service the first request as initial state for the second request and subsequent stateful web-socket processing.
Youāre correct that there could be means to retain data, but it comes with all the complexities of caching, where store it, how long store it, ā¦. Itās also slightly problematic to talk about first and second render, because itās not two connections, itās n connection. A single static render might connect over websocket multiple times in case of a connection drop. So do you retain the state of the static render up until a potential connection dropout, which could be any time later not just close in time.
You can also read more on the complexities here:
Thank you!
Iāve come from such a different angle I didnāt expect āAllow LiveViews to be adoptedā to be related, yet itās the exact same topic Iāve been pondering. The issue appears to remain open but with little activity after the initial discussion the interest in addressing it may no longer be present or pressing enough.
Shall I jump on there with how I though it could be done to be critiqued and maybe probe current interest levels?
Just because thereās no activity doesnāt mean thereās no interest ā itās rather priorities Iād imagine. If you think you have something to contribute thatās probably the best place to do so.
Unless Iām gravely mistaken, I donāt see what Iāve proposed to suffer from the uncertainties and complications youāve mentioned.
It remains to be seen if itās worth anything but I went ahead and described my Proposed Session Handovers for LiveView on the issue
Sorry to say, @LostKobrakai, but that devolved into an outright disaster. I bowed out. That issue and the problem I discovered and solved for myself must have none of the overlap we both assumed there to be.
I donāt think thereās no overlap. Youāre just fine with making tradeoffs the LV team is not fine with making ā at least thatās my pov from following this from the sidelines 
Could be that, could be we havenāt had enough shared experiences for them to assign any weight to what I reported as actually happening in production clusters right now while they worry about what could happen in clusters when programmers donāt think. Been interesting though.
Thanks for engaging and encouraging me. Next time donāt just lurk on the sidelines, yank me out of the fire earlier, OK? 
