Uh oh!
There was an error while loading. Please reload this page.
Improve error handling when offline - #2128
Conversation
Codecov Report
@@ Coverage Diff @@## master #2128 +/- ##
==========================================
+ Coverage 92.53% 92.68% +0.14%
==========================================
Files 212 213 +1 Lines 12171 12188 +17 Branches 1779 1788 +9 ==========================================
+ Hits 11263 11296 +33 + Misses 908 892 -16
Continue to review full report at Codecov.
|
vanessayuenn
left a comment
There was a problem hiding this comment.
Thanks for tackling this! The new offline view looks good and the message is very clear 👍 . I have got a couple of questions; they're mainly for my own understanding and are not blockers.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
8f1b5f5 to
d29884dCompare
Please be sure to read the contributor's guide to the GitHub package before submitting any pull requests.
Requirements
Description of the Change
When the network is unavailable, the GitHub package behaves poorly:
I'm introducing:
<QueryErrorView>case that recognizes network errors and offers to open the dev tools for more investigation. (Unfortunately, the errors thrown byfetchareTypeErrorinstances with little information and a message of "fetch failed.")<GithubLoginView>when the network is unavailable.Screenshots
When a user attempts to open a new item that uses Relay data (an issueish detail item, the reviews tab) while the network is offline, including items created during window state deserialization (like a reload):
When a user attempts to click a refresh button or perform a mutation while offline:
When the network dies in between the git fetch completing and the Relay refetch triggering somehow:
Alternate Designs
N/A
Benefits
Users on spotty wi-fi or airplanes can have a gracefully degraded Atom experience and informative error states.
Possible Drawbacks
The errors thrown by the
fetchAPI are (deliberately, I believe) very vague. It's possible that we could report that a user is offline when they have misconfigured DNS or proxy settings, for example. The underlying OS network error is shown in the developer tools, but we have no way to read it.Applicable Issues
Fixes#1844.
Metrics
N/A
Tests
I did manual testing both by toggling network connectivity in the dev tools and by actually disabling and enabling wi-fi.
Interestingly, the
'online'event that I'm using to auto-retry from an OfflineView doesn't seem to fire the first time you uncheck the "Offline" button in the dev tools, but it does every subsequent time. The event fired when I expected it to when the wi-fi was actually restored so I didn't investigate further.Documentation
N/A
Release Notes
User Experience Research (Optional)
N/A