Handle bad network better

[david-crespo]

A while ago a customer was having issues with their network and it was not obvious enough in the console that these errors were not coming from our API. In traditional multi-page apps, this is not an issue because when you navigate or post a form, if the request doesn't go through, the browser will blow up and show you a "server could not be found" pageor whatever. In an SPA, we're catching errors ourselves and showing generic error page (on navigation) or displaying the error in a box (on form submit), so they're showing up "inside" the app, so unless you say otherwise, it feels like the error is coming from the app.

• Navigation: change loaders to use fetchQuery instead of prefetchQuery so it can blow up while loading rather than after, and then we have a choice about how to blow up. If we show some kind of modal without going to a full error screen, it can be less jarring and maybe give the user a chance to try again.
• Form submits: we already show errors inline in the form, but we need to detect network errors and make clear that it's not an API error.

Unfortunately I think different browsers represent network errors differently, and it's hard to reproduce bad network conditions locally — for example, the browser treats turning off wi-fi quite differently from real traffic that's messed up.

[david-crespo]

We saw this again as a "failed to fetch". Hard to repro, but we should give it a try.

[david-crespo]

Well... maybe not that hard to repro. This is good news.

Firefox

Chrome

In Chrome, using the throttling tool to go fully offline just makes it spin forever, but blocking the specific URL works.