> It captures AJAX requests which were made while the connection was down, and remakes them when it's back up, so your app reacts perfectly.
Is this something I want as a user? If an app seems to be offline, I tend to do various things just to check or re-establish connectivity. Say, hit the Send button a few times, order columns, filter, search, whatever. Stuff, I wouldn't do if I had connection.
Once the app reconnects, all this nonsense would be executed. I'm not so sure if I'd really want this as a user.
This leads to the question: How fast does it notice that the app went offline? Do I get the chance to do stupid things as a user or will I be shown the "you're offline" message soon enough?
After the first request fails it will confirm it's the connection at fault, and immediately show the message. Depending on the nature of the connection problem this can be immediate, but there is a small possibility that it can be delayed if the nature of the problem causes connections to timeout. If we get reports of that happening in the wild, there are things we might be able to do.
You'd need to take care of this anyway, since almost any asynchronous action otherwise carries the danger of being dispatched twice if the UI is left active.
Most frequently, this is done by disabling submit buttons or debouncing asynchronous function calls that happen as a result of a UI action.
If either the native offline event fires (where supported) or a single XHR request has a timeout or error, we fire our offline event, which triggers the UI to update.
So in your example, you'd know almost immediately after you clicked the "Send" button.
Anyone who is coding for cases like this will likely need to handle those kind of user errors. Not a big deal, though, considering a lot of apps do this already anyway.
You guys have put out some great pieces of JS in the last year and the quality is getting better. I'm a big fan of how this is not jQuery dependent and the code is simple. I've been watching the HubSpot repos since globalMessenger and the code and presentation are far above par.
Why are you critiquing this script like it's a consumer product? Obviously any developer who wishes to use this will have do some extra work to make sure things run smoothly.
Maybe because I've already implemented something like this in the past and I faced a lot of issues with synchronizing multiple states on multiple devices?
And I didn't say the library was bad, quite the contrary.
I wrote the js in Offline. I agree completely, this is definitely not an attempt to resurrect Google Gears. I would love to see how more people use it, and what sorts of problems they run into before deciding what the solution might be.
Two thoughts right now (make a gh issue if either is something you need):
- Make an option to only enable request remaking for GET requests
- Make an option to throw out POST/PUT/DELETE data if it's more than X minutes old
Listing the requests is interesting, but would obviously require the programmer to associate the request with the user-facing feature it enables. Something like messenger might be better for that: http://github.hubspot.com/messenger/
Thanks for the library and I'm glad you understand what I tried to say. The warning I was giving was not meant as criticizing your library. It was meant as a general warning when dealing with queueing ajax request when offline.
This comes at the perfect moment for me: I'm building an inventory web app used in warehouses on tablets and I'm faced with connectivity issues (incomplete or fluctuating WiFi coverage for instance).
Making the app less prone to these issues is certainly going to help build something more robust, so thanks a lot!
We built Couchbase Lite as a serious embedded database for use cases like this. Our PhoneGap connector might be right up your alley. http://mobile.couchbase.com
The more I look into HubSpot libraries, the more I am amazed by their approach. To the point, small and flexible. And if the only annoyance people can bring up is a snake game, then you should be proud :)
Regarding this particular module: is there any chance of combining this with a websocket connection (particularly socket.io)? I don't really care much for off-site requests, but notifiying the user of a disconnected socket would play well into this.
Thanks! Do you mind opening an issue for the websocket support in GitHub Issues? I'm not sure if there's anything we can do there, but I'm happy to talk about it.
This is just what i need!! For my html5,json,localstorage app.
But what if the user press Reload ?
But what if the browser crasher or closed normally, does the buffer stay ? if not then it's useless!
Is this something I want as a user? If an app seems to be offline, I tend to do various things just to check or re-establish connectivity. Say, hit the Send button a few times, order columns, filter, search, whatever. Stuff, I wouldn't do if I had connection.
Once the app reconnects, all this nonsense would be executed. I'm not so sure if I'd really want this as a user.
This leads to the question: How fast does it notice that the app went offline? Do I get the chance to do stupid things as a user or will I be shown the "you're offline" message soon enough?