LiveView adds a `phx-disconnected` class, which is what I assumed you mean by beachball, and interactions are paused while the user awaits the UI to tell them they are good. This is all driven by your CSS and you can also hook into the connection life-cycle with a few lines of JS, so the app should be telling the user "Reconnecting..." vs it appearing broken, so this is really up to your UX folks. By default new phx apps make use of the topbar library so any page loading event or dropped connection will show the loading bar/spinner up top.
As far as spotty connections go, when I try simulating 30% packet loss, my LiveView WebSocket connections have no perceptible degradation, so it's hard to say where the cut off is. You can also fall back to long-polling which may benefit very edge users, but I would only do so if absolutely necessary.
Having said all that, one thing we are upfront about in general is LiveView is obviously not a good fit applications that require offline support :)
In principle, your Twitter client could remember the state locally, let you keep working, and just keep trying to sync.
In practice... most apps are really bad at working offline, so just handling the disconnection and reconnection in a robust and consistent way is already much better than average!
I think that 'read-only mode' and 'can't interact at all' mode are not the same.
I often have google news open when the train vanishes down a tunnel and keep scrolling down reading headlines until we're out the other side.
If a website freezes on me, I close it.
> Having said all that, one thing we are upfront about in general is LiveView is obviously not a good fit applications that require offline support :)
Not a good fit is rather charitable...
It becomes totally unresponsive and totally unusable in any offline or high latency situation (trains, stadiums, remote areas) right?
I know, and I've read your responses that 'well, all websites have to interact with a server eventually, so it's pretty much the same as that only better...' but, well... when you build websites like this, that's why product managers say "no, we don't want a website, we want an app".
s/obviously not a good fit/non-starter :)
> I think that 'read-only mode' and 'can't interact at all' mode are not the same.
I agree, but it depends on the application. LiveView doesn't "freeze", but the content on the page is not going to continue updating or be interactive. This indeed limits some applications that want to allow the user to continue editing a document, but your example of a news site absolutely still functions fine for read-only offline.
> It becomes totally unresponsive and totally unusable in any offline or high latency situation (trains, stadiums, remote areas) right?
Yes, just like the vast vast majority of web applications today, including the vast vast majority of SPAs that could, in theory, work offline, but don't because of the added complexity on the client and server, state syncing, conflict resolution, etc. If working under the offline condition is a hard requirement, LiveView is out full stop. But even for SPAs, this is an opt-in feature today that few choose.
If an app can be reduced to just CRUD, I think it works very well.
We've been using LiveView to build a new app at Precision Nutrition and are largely quite happy with it so far.
One concern we keep coming back to is that of the need for constant connectivity in order for the app to work. I'll throw up the disclaimer here that I've not spike on how to handle network disconnects. That said, we've had a few of our internal users lose their connection to the web socket, and the app just beach balls. You can't do anything. Another example we keep coming back to is a user going onto a subway.
How do you envision spotty connections being handled long term?