LiveView fallback when websockets are blocked?

We are currenlty leveraging Phoenix LiveViews in our app, but not all our clients support websockets. In some cases the websocket connection is being blocked by a corporate firewall.

Now when this happens, the websocket tries to reconnect for up to 10x times and when it can’t establish a connection it will refresh the page. Which I can understand from a recovery after a new release/deploy perspective or any other accidental failure.

However, when the websockets are blocked anyhow this will render the app virtually useless as it will refresh the page every so many seconds.

Is there a way to sidestep this default behaviour? I pinpointed it back to this javascript function that does the failure handling and reconnecting: https://github.com/phoenixframework/phoenix_live_view/pull/506/files#diff-aadf53ece23601dca3bf8482086a1b2f650c04a65130f3d8405f1a817e7ef422R284-R295

Any help is greatly appreciated!

Channels do support LongPoll as transport. So you can implement an fallback to that if a connection cannot be established. This fallback is automatic if a client doesn’t support websockets at all, but you need to do it manually for issues on the network level.

2 Likes