Custom useFetcher error handling

[dmarkow]

When using fetcher.load or fetcher.submit, Remix handles any uncaught errors and renders an error boundary. It would be nice to override this error handling when needed. The useFetcher documentation says "Handles uncaught errors by rendering the nearest", but as far as I can tell, all errors are uncaught since there is no way currently to catch useFetcher errors.

In my use case, we have some fetchers that run in the background to automatically submit some application state to the server a couple times per minute. If anything happens between the client and server to throw an error (most common seems to be a Failed to Fetch error due to be their wifi dropping out momentarily during a fetcher.submit call), the whole page falls back to an error boundary. For now we're just using a plain fetch(...) instead of useFetcher to work around this, but then we lose the data reloading capabilities of Remix. It would be great to have access to the error when needed and decide if I want to handle it myself or let Remix render the error boundary.

The options below would generally be opt-in, so it shouldn't break any existing apps. Option 1 would change the return type of load and submit, but you would still be able to use them the same way as before. Leaving out the error handling in each portion would just have Remix render the error boundary like does now.

Option 1: Promises

Have load and submit return promises that can be caught. The added benefit would be the ability to add .then(() => { ... }) handlers when the request is complete (there are several discussion threads about that already). I'm not sure how well this would work with Remix's current fetcher implementation though.

fetcher
  .submit(data, {method: "post"})
  .catch({ error } => {
  // do something with the error

  // if you want to see the error, but still have Remix handle it and show an error boundary,
  // you could re-throw the error
  });

Option 2: Callbacks

Add an optional onError callback to SubmitOptions for error handling. If this option is present, Remix would call that method instead of the internal maybeBailOnError, and then set the fetcher state to something like {state: "idle", type: "error", error: error} (or setting data to the error)

fetcher.submit(data, {method: "post", onError: (error) => {
  // ...
});

Option 3: Adding flag to options

Similar to Option 2, add showErrorBoundary?: boolean to SubmitOptions for error handling. If this option is present, Remix will skip calling the internal maybeBailOnError, and then set the fetcher state to something like {state: "idle", type: "error", error: error} (or setting data to the error)

fetcher.submit(data, {method: "post", showErrorBoundary: false});

useEffect(() => {
  if (fetcher.type == "error") {
    // Do something with fetcher.error
  }
}, [fetcher.type]);

[lili21]

all errors are uncaught since there is no way currently to catch useFetcher errors

I guess you can catch it inside the loader or action.

export const loader = () => {
  try {
      ...
  } catch (e) {
    return json({ error: e })
  }
}

But I agree with you, it shouldn't break any existing apps. and the submission feedback could be more easier.

[dmarkow]

That's exactly what I do in my loaders, catching errors and returning nicely formatted errors. The issue that prompted this discussion is errors that happen client side before the server (and loaders/actions) are even involved, e.g. when the client's internet is disconnected and a loader tries to run.

[SeanRoberts]

This is what I do currently but I don't love returning a 200 response from a loader/action and an error in the body.

[brophdawg11]

You can add a 4xx/5xx status to that returned json response if the HTTP status is important - you just won't have direct access to it in the component via useLoaderData if you don't also put it tin the response body.

[SeanRoberts]

Oh for some reason I had it in my head that the fetcher wouldn't set data for non 200..299 responses. Thanks!

[nicholaschiang]

possible (hacky) solution: add a service worker that intercepts all your traffic and then returns an error object so you can have:

const fetcher = useFetcher()

fetcher.data.response // your actual response (could be null)
fetcher.data.error // the error object returned by the service worker (when response is null)

[brophdawg11]

Related React Router proposal: remix-run/react-router#10013. We should probably prefer that one since that's where the fetcher code lives nowadays.