I take a more classic web approach to LiveView which is to say I persist any important state right away. Like any multiple-step forms I would never store in server state, I'd persist each step. Of course that doesn't help if someone is halfway through filling out a form. If the socket disconnects then re-connects then you don't lose your work but not if you do a restart. I do wish there was a built-in way to store state on the client until it's submitted, we may get there, though!
The true value of LiveView for me is the simplicity of not having to write yourself a web API to interact with your own backend as well as the dead simple real-time features. If you don't need the latter, that's fine, but having worked on collaborative apps that was a giant pain is what led me to LiveView.
In practice, if you care about this aspect of user experience you may have to take some reasonably small steps to preserve state information in the client. Form state gets preserved automatically for most purposes, though there may be some forms that need to implement a call-back to preserve state, as explained in the docs: https://hexdocs.pm/phoenix_live_view/form-bindings.html#reco...
https://www.erlang.org/doc/design_principles/release_handlin...
Liveview makes no assumptions about the client connection or even stickiness of client to nodes in a cluster. If you store critical data in the liveview you could be in for some trouble. Always store important stuff into a recoverable, network aware datastore. The nice thing is that liveview is designed to be tolerant to client or client connection failures, you should design to be able to repopulate state sanely in the on_mount call.
While this sounds bad, think of it as isolating the client connection failure domain from the data failure domain, so you should organize your code in those domains respectively
If you want some sort of ephermal network state that lives on one node and not the database only (e.g. a game), the liveview should connect into that. If you want to store that in a genserver, a strategy like this is doable:
Besides scheduled maintenance, there’s all sorts of reasons why this might be needed: The user’s log-in expires, network issues, browser crashes, server hardware issues, deployment of a new version of your app…
“Hot upgrades” can be implemented if you wish to, but often this is just handled by asking the client to reload the page, establishing a new connection, because any data or preferences have been persisted.
Can't remember if/how that routing was accomplished in the BEAM (Erlang/Elixir VM). It's definitely possible but you might have to implement it yourself.
https://youtu.be/pQ0CvjAJXz4?t=1992
Bryan Hunter explains how they do it at HCA healthcare (not specifically LiveView process, but processes in general).