Every app goes offline

added by Jonathan George
10/13/2014 1:37:56 PM


A small, but perfectly formed library for detecting when a SPA loses it's internet connectivity and dealing with that appropriately.


Drew Peterson
10/14/2014 2:14:13 AM
I took a quick look at the code; the cache-busting seems to be accomplished with a simple Math.Random tacked on to the query string. That seems like a reasonable enough solution. What would be really awesome would be to add proxying for websocket calls as well, and websockets could then be used as the primary test for connectivity (which isn't vulnerable to caching related issues), with a possible xhr fallback. All that aside, what I think people really need is a nice starter example showing best practices for using the library. You still need to design your user interaction in such a way that the application maintains local state while offline, and allows the user to continue working, rather than locking down the UI while the application is disconnected. Do you have any experience using this library @jon_george1?

Jonathan George
10/14/2014 8:45:22 AM
Agreed on the idea of using more modern methods of detecting offline status, but on the flip side you could argue against making the library larger when it still needs to use the fallback method for older browsers - sadly my app needs to support IE+, so I couldn't rely on a websockets based solution. With regards to best practices for building offline apps - this would be a nice to have, but it does feel like at the moment, there are many roads you could go down when building an offline-enabled app. My only experience using the library is simply to do what you mentioned - alert the user to the fact that the app has gone offline, and prevent them from doing any more work until reconnected - although longer term we intend to do more work on the app to make it functional when disconnected (probably only on more modern browsers so I can use something like IndexedDB) The thing I really like about this library (and others from the same author) is that they are very tightly focussed on doing one thing and doing it well - it really was one of those libraries you can just drop into your solution and see it working straight away, which is always nice.

Drew Peterson
10/14/2014 6:45:14 PM
Perhaps a good middle-of-the-road solution would be to create an extension to the library for websocket support, that combined with a simple fallback if the WS namespace is not found would be awesome. Maybe I'll hack up a gist if I find some free time :-)