StoDevX
Alert the user when a network request fails due to network error
- The user's app makes a network request
- It fails
- If the retries parameter is true || a positive non-zero integer, retry with exponential back off that many times (defaults to 5? 3?)
- If retries is false|0, proceed
- The app shows an alert saying "Cannot get X", "No internet connection available", "OK"
- The caching layer returns cached data
That's my proposal (spawned from something @rye mentioned, combined with more thought about what Apple's Mail.app does and a realization that I'm OK with the alert.)
@hawkrives Is this where you are imagining putting this? Or at a lower level?
https://github.com/StoDevX/AAO-React-Native/blob/bf8655d56c0d5213fe78d2c8b97bf941dde818ef/modules/fetch/index.js#L95-L110
Yeah, somewhere around there.
It's going to take some tweaks to fetch/cachable, too, since that hides network errors.
First off, I'd look at sindresorhus/ky for reference, since they have a retry handler.
I'm thinking something like, change Cachable to throw a NetworkError (where class NetworkError extends Error), and then we catch NetworkError and only NetworkError in fetch/index.js, and only if we're retrying.
If we are retrying, and there are no retries left, it should call alert.alert I think.
In addition to this, now that we are caching data I think we should always let the user know if the data that they are seeing is out-of-date...this could take shape as a small banner at the top or bottom of the screen that is red when the network connection is disconnected and becomes green and disappears when it reconnects (like Spotify's). Thoughts? @hawkrives @drewvolz @rye
I like the idea of presenting a small alert that disappears automatically? Red is a good color.
Network connectivity only matters when a request is being made.
When you're just looking at building hours, there's no reason to say "oh you're offline, oh you're back online, oh you're offline"
Messenger / Telegram / Spotify are less "transactional" and/or have a concept of presence, so it's valuable for them.
I do not like such an indicator for us, where we pretty much make one network request per view.
I would prefer that we take Apple's approach and show an alert when you attempt a network request that errors due to network problems.
The only problem that I have with just showing a dismissible alert is that the user will still see data when they dismiss it, so they might think that the alert was a bug and the data actually updated when in fact the data is out-of-date. Adding a banner of some type that disappears when the connection is online and the data has been updated would remind them that the data they’re looking at might be in inaccurate. In the mail app, a dismissible alert makes more sense because the lack of network connectivity is just preventing you from receiving new emails...it doesn’t mean that the emails that have been cached could be invalid now...
I would argue that the same is true for cached data; just because your request failed doesn't mean the data is useless now.
It's like if you archived a bunch of emails on your desktop and then looked at your phone offline - they're still there because the network failed.
I just don't like UIs that randomly slide new colored bars in and out while I'm using them.
I'd be more OK with something like this:
| - |
|---|
 |
IE, a permanent toolbar that just happens to show the last updated time.
I just really don't like interfaces that start moving things around on me.
@hawkrives Any ideas for where such a notice would go on the menu view, for example? At the bottom or top?
A bottom toolbar is probably a more powerful design pattern. While I do like the look of the menu example, it may be of more help if we collocated this info in a single part of the view.
