Is there a way to detect when URQL determines it is offline?

[JohnAtFenestra]

I'm working on a part of my code dealing with offline detection. Since URQL (rightly) uses the ability to reach the server as it's detector for going offline, I wondered if there was a way to detect/listen to when URQL thinks it is offline?

[kitten]

There are multiple indicators, but basically we're currently working with the assumption that knowing when urql thinks it's online again is more important. The main indicator that @urql/exchange-graphcache contains to check whether it's offline is passive. It looks at results and if it sees that a network error of a particular shape and message has occurred it assumes it's been offline: https://github.com/FormidableLabs/urql/blob/f3cf0c9685f41257b86b6b3a88512ccfc7883b02/exchanges/graphcache/src/offlineExchange.ts#L58-L65

It then uses what you pass for storage.onOnline to determine when to assume it's back online. So you can in theory piggy back on that and make storage.onOnline more complex to take more state into account or let other parts of your application change accordingly.

[JohnAtFenestra]

Yea, I think the major set of use cases for an application knowing it is "offline" is to be able to display the information for the user and to keep track of transitional stages - e.g. offline -> online vs logged in online to logged in offline.

The difficultly lies in where I said "rightly". By using server connectivity as its gauge, URQL allows for extensive offline mode development simply by stopping the server (works great with a local dev Apollo Server). Also supports a use case we have for a training version which will be installed on Surface Pros for use disconnected from the internet where using navigator.online actually gave false information when we used AppSync client.

But, here lies the rub, we have to reliably know when URQL transitions to offline mode. Hence my question.

[kitten]

Hm, I suppose that brings us to the problem that there isn't a reliable source for that. I also found that some events and navigator.onLine are inaccurate in reflecting what's going on with the current network status.

If we assume however that you may already be using the retryExchange to quickly retry a request multiple times, then you could also use the errorExchange with a similar detection to see whether a result has errored with an offline-like network error. (both after Graphcache of course)

Another alternative would be to add both online/offline events compeltely separately from urql, to debounce them, to add some guards around them and then display that to the UI as a heuristically updating indicator. This is actually similar to what some apps like Slack do.

The reason why I'm proposing this is rather simple: detecting whether you're offline is "lazy" in Graphcache. But you can tell the user whether you expect them to be offline already, either early or late, since the network status is always expectably unstable and perceived as such.

Slack for instance may error on sending messages already and only shortly after display it's "connectivity issue" popup. Or it may do so intermittently before an action is even performed. Although it probably admittedly uses its sockets for that detection that's similarly unrealiable (due to keepalive mechanics) as the offline browser events.

So I'd give that a genuine try to decouple the user-hints from what Graphcache is doing, add some retrying, and make it more solid by making the UI more heuristic. That's because worst case the popup will be early/late but correct, and best case, it still works but the user knows to be "careful" if it's due to spotty Wi-Fi or it's a fluke. (again, debouncing here could help)

[JohnAtFenestra]

Sound advice. For the most part, the thing we're writing will either be offline (because they are in a restricted area where they are not allowed to connect) or will be online (which is when the work they queued up in the restricted area will be sent to the server).

Because of using a piggyback authentication method, I have a (fairly) reliable way of detecting if the system is producing a Network Error before I attempt to execute the URQL mutations. I'll probably attempt to trap it there for the time being.

I do like your idea of tapping the exchanges. I've thought about trying to write a custom exchange to tap into the flow for some other purposes (including a long term replacement for my current piggyback system) but I'm not comfortable enough yet in understanding the Wonka interface to attempt it.

I'm curious, is there a specific reason for using Wonka vs RxJs? Not a criticism because I fully understand how designing a system can have context specific advantages, however, it seems like RxJs might (and I use that term with care) have done the job while bringing a significant ecosystem along with it.

[kitten]

Originally the decision of using Wonka was specifically because I and my colleagues worked on it and it was directly catered towards the problems we were solving. That generally being that if you check its test suite its compliance with predictable synchronous behaviour was key.

Basically, I personally am a big fan of the callbag spec and how it simplifies the idea of observable/iterable sources. And what really sells this is predictability. One could argue that Rx and zen-observable are predictable as well, and that generally Rx can even have scheduling that's similar, but a lot of these guarantees do break down if we differentiate between synchronous tasks that become increasingly complex.

At the end of the day, Wonka's API however is extremely similar to Rx, to the point where you can likely cross-compare docs and won't have to relearn anything (mainly because I'm came to writing Wonka from knowing RxJS)

More recently however some other benefits have also shined through: bundle size and performance. And I won't go too much into detail with that, but even taking treeshaking into account we still get some nice size guarantees from using Wonka.

Also on another note, I did experiment with just using callbacks for Exchanges. The resulting API however became even more complex to reason about and "just adding buffer or switchMap or things like that when it's appropriate is not a thing when you approach every exchange from scratch without a streams library.