4 ms·

> 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

by WA 13y ago

> 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?

afschwartz 13y ago
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.
TobbenTM 13y ago
Usability depends on app. Take Trello for example, super useful when working with teams and on boards with a lot of activity.
rmrfrmrf 13y ago
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.
nathankleyn 13y ago
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.
zackbloom 13y ago
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.

by WA 13y ago

afschwartz 13y ago

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.

TobbenTM 13y ago

Usability depends on app. Take Trello for example, super useful when working with teams and on boards with a lot of activity.

rmrfrmrf 13y ago

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.

nathankleyn 13y ago

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.

zackbloom 13y ago

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.