3 ms·

Improving UX is important here, but keep in mind `navigator.onLine` is prone to false positives when it returns true in Chrome and Safari. https://developer.mo

Improving UX is important here, but keep in mind `navigator.onLine` is prone to false positives when it returns true in Chrome and Safari. https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOn... If you need to support more browsers it isn't difficult. Just make a request to a small static asset or a health route and keep track of the online status yourself. You could even combine this with `navigator.onLine` for the best of both worlds.

ishitatsuyuki 9y ago
I would just submit the form and check if it had a successful response. It can still be unreliable on a flaky network (the exactly once issue), but anyway it's cheaper on resources.
- vinnymac 9y ago
  Yea, I would do the same. I was just speaking in terms of online awareness.
- gramstrong 9y ago
  Is listening for the event really expensive? Honest question. We update the UI when it happens, so I don't think relying on the success/failure of network requests is reasonable for us anyways.
Brakenshire 9y ago
It's a shame the API's aren't better for this situation, pinging a static asset to determine network status is not good for battery life on smartphones if it's going to occur for any length of time.
- devdad 9y ago
  Do you have any information to support this claim about battery drain? Genuinely interested, not trying to negate what you're saying.
  - Brakenshire 9y ago
    I don't have any citations, it's just my understanding that switching on the mobile radio is a major battery drain, and should be avoided as much as possible.
- ivan_gammel 9y ago
  It also badly impacts UX, because on slow networks the request-response roundtrip even for small static asset may be very long, so that the time needed for the feedback in the form will be in fact doubled.
- devrandomguy 9y ago
  The real problem is that there is no way to reliably know just how far your connection goes, without pinging. You might be able to connect to URLs on a university WAN, but not to the rest of the internet, for example. In this situation, as far as uni websites are concerned, you are online, but for Youtube, you are effectively offline. The concept of "online" does not have a trivial boolean definition.

ishitatsuyuki 9y ago

I would just submit the form and check if it had a successful response. It can still be unreliable on a flaky network (the exactly once issue), but anyway it's cheaper on resources.

vinnymac 9y ago
Yea, I would do the same. I was just speaking in terms of online awareness.
gramstrong 9y ago
Is listening for the event really expensive? Honest question. We update the UI when it happens, so I don't think relying on the success/failure of network requests is reasonable for us anyways.

Brakenshire 9y ago

It's a shame the API's aren't better for this situation, pinging a static asset to determine network status is not good for battery life on smartphones if it's going to occur for any length of time.

devdad 9y ago
Do you have any information to support this claim about battery drain? Genuinely interested, not trying to negate what you're saying.
- Brakenshire 9y ago
  I don't have any citations, it's just my understanding that switching on the mobile radio is a major battery drain, and should be avoided as much as possible.
ivan_gammel 9y ago
It also badly impacts UX, because on slow networks the request-response roundtrip even for small static asset may be very long, so that the time needed for the feedback in the form will be in fact doubled.
devrandomguy 9y ago
The real problem is that there is no way to reliably know just how far your connection goes, without pinging. You might be able to connect to URLs on a university WAN, but not to the rest of the internet, for example. In this situation, as far as uni websites are concerned, you are online, but for Youtube, you are effectively offline. The concept of "online" does not have a trivial boolean definition.