>> LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored.
What the parent means is that, because state is kept on the server with LiveView, and events that change that state are processed by the server, if your connection is lost, then you may find that even basic things, such as having a dialog open when you click a button, stop working. This means that unstable connections result in very poor UX.
This is in direct contrast to a typical SPA for example, where the browser keeps and handles most front-end state, and talks to the server only when it needs to (e.g. form submission).
With pure LiveView, I would agree, but you can easily supplement with a JS framework. As I mentioned above:
> You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot.
If you have a very complex client-side need, it's also pretty easy to use React.js for that.
While you could, I never use LiveView to open dialogs (unless the dialog state needs to be distributed across multiple clients, but I haven't had that use case come up yet). As you mention, that would lead to a poor UX.
The best is the best of both worlds. LiveView for data/state changes that need to go to the database, client-side script for state changes that are UI related and don't get persisted.
What the parent means is that, because state is kept on the server with LiveView, and events that change that state are processed by the server, if your connection is lost, then you may find that even basic things, such as having a dialog open when you click a button, stop working. This means that unstable connections result in very poor UX.
This is in direct contrast to a typical SPA for example, where the browser keeps and handles most front-end state, and talks to the server only when it needs to (e.g. form submission).