Replies: 1 comment 1 reply
-
|
After more consideration, I believe network errors need to be their own class. Here's why:
There should at least be some way to handle case 3 gracefully, as say CloudFlare returns a 502 from their edge, and the error boundary can only see a generic error with the message It's obviously not possible to gracefully fall back to browser error pages in an SPA, but at a minimum I'd like to be able to:
For the first case, some users are asking for promise-based handlers for form actions, #3955 but it's not clear how that would work if a subsequent loader failed for example. Instead, I'm considering an API that would let routes opt-in to receive the error that would have been thrown to an error boundary via useActionData. For example: https://gist.github.com/azuisleet/f96da706ab741c669fdfc720e8999e3f For the second, I currently check for TypeErrors at the error boundary and try to render a "No Connection" message. It's not perfect, but I don't have any better ideas. |
Beta Was this translation helpful? Give feedback.
-
|
I found that some browsers also have different values for network errors. I agree it would helpful could if remix could catch these and treat them as a separate class of error in the boundary altogether. |
Beta Was this translation helpful? Give feedback.
-
If a user is offline and they attempt change routes, it's very possible that the fetcher will return a
TypeError: Failed to fetchAlthough not addressing this scenario, Remix does attempt to reload the page if the route module isn't found:
remix/packages/remix-react/routeModules.ts
Line 202 in fbc6e23
But does not attempt the same if the route module was already cached but the loader failed.
This is similar to other issues like #4242, but I believe next.js handles this specific type of navigation better, by reloading the page (so that the UA can show a "No Internet" page), rather than pushing it to an error boundary.
The justification here is that it's fine if useFetcher throws to an error boundary since it's a progressive enhancement, but navigation should be more of a framework concern.
I suppose a very crude workaround would be to handle it post
ErrorBoundarywith something like:Beta Was this translation helpful? Give feedback.
All reactions