Catching errors on useFetcher

[dmarkow]

Prior to using Remix, I had a custom form component that used fetch to submit forms with some error handling, something like:

const onSubmit = async (data) => {
  try {
    const result = await fetch(...);
    // process the result...
  } catch (error) {
    // This would catch "Failed to Fetch" errors for things like network problems,
    // the endpoint being down, etc., and then save it to be displayed to the user.
    setError(error);
  }
}

With Remix, using either useFetcher or useSubmit, is there any way to catch these errors before they bubble up to an error boundary? The boundaries are better than nothing, but it's a pain to have the whole form disappear because of an error with fetch instead of just showing an inline error message similar to how our validation errors appear.

I know we could save a local copy of the form data before submission to try and restore them after a page reload following an error, but we have some pretty complex forms where serializing/restoring would be very cumbersome.

[sergiodxa]

There's no way right now to try/catch fetch errors, I suppose Remix should do it and let you know if something failed with a value returned by useFetcher or useSubmit.

Something you can do right now, is to prevent the submit if the user is not online, you can detect that with the navigator.onLine API.

[dmarkow]

Thanks! I assumed this was the case. Unfortunately it's not just an issue with the user's own connection -- if the user is online but something happens between the user's network and our server, or if our server is offline briefly, it could still trigger that error. Having an onError option for useFetcher or something along those lines would definitely help.

[sergiodxa]

I recommend you to create an idea discussion and propose a possible API for this and explaining more in details the use case and scenarios you want to cover.

[freshollie]

My current workaround is to use the raw fetcher and handle aborting on unmount. I'm using the use-http library to deal with this.

This implementation assumes you are just refetching from the page's loader, but you could pass in params just like the useFetcher implementation.

import { useLocation, useMatches } from "@remix-run/react";
import { useCallback, useEffect, useMemo, useState } from "react";
import useFetch, { CachePolicies } from "use-http";

export const useFetcherRaw = <T>() => {
  const [data, setData] = useState<T>();
  const [error, setError] = useState<Error>();
  const fetcher = useFetch<T>({
    cachePolicy: CachePolicies.NO_CACHE,
    onNewData: useCallback((_, newData) => setData(newData), [setData]),
  });
  const location = useLocation();
  const matches = useMatches();
  const get = useCallback(() => {
    const route = matches.find((match) => match.pathname === location.pathname);
    if (route) {
      fetcher.get(
        `${location.pathname}?${new URLSearchParams({
          _data: route.id,
          method: "GET",
        })}`
      );
    }
  }, [fetcher, location, matches]);

  // Ensure errors are not cleared until there is a succesful load
  useEffect(() => {
    if (fetcher.error) {
      setError(fetcher.error);
    }

    if (!fetcher.error && !fetcher.loading) {
      setError(fetcher.error);
    }
  }, [fetcher.error, fetcher.loading]);

  return useMemo(
    () => ({
      get,
      data,
      loading: fetcher.loading,
      error: error,
    }),
    [get, fetcher, data, error]
  );
};

Are there any reasons not to do this?

[tecorraltd]

Does this mean you cant catch errors in components that utilise useFetcher??

[rjdmacedo]

Any news on this 🧵?

[alexander-entin]

I'm now playing with the following workaround (or solution?):

// ErrorBoundary equals to your main component
export let ErrorBoundary = Chat

// in the case of error it will receive 'error' property
export default function Chat({ error }) {
	...
	return <>
		{error &&
			<div className="toast toast-top toast-center">
				<div className="alert alert-error">
				...
		}
		<Form>
			// your stuff here
		</Form>
    </>
}

The component will be re-mounted, so instead of useState you'd want to use global state (ex. Jotai atom).
There are issues with useEffect too.

With a little bit of support from Remix (like don't remount if ErrorBoundary and default component are the same) this could solve the problem

[kiliman]

Instead of exporting the ErrorBoundary to be the same as your default component, let your UI component take children as props.

Remember, Remix will replace your UI component with the ErrorBoundary if there's an error. So make your ErrorBoundary render your UI component along with your error message.

import { useFetcher } from "@remix-run/react";

export function action() {
  throw new Error("Error in chat action");
}

export default function Chat({ children }: { children: React.ReactNode }) {
  const fetcher = useFetcher();

  return (
    <div>
      {/* this will come from the ErrorBoundary */}
      {children}
      <h1>Chat</h1>
      <fetcher.Form method="post">
        <input name="message" />
        <button type="submit">Send</button>
      </fetcher.Form>
    </div>
  );
}

export function ErrorBoundary({ error }: { error: Error }) {
  return (
    <>
      {/* render our chat component with the error message */}
      <Chat>
        <div style={{ color: "red" }}>
          <h1>{error.message}</h1>
        </div>
      </Chat>
    </>
  );
}

[dmarkow]

If your form route has a useLoaderData in it (e.g. an edit route where you want existing data pre-filled), this approach doesn't work since the loader data won't be present. The useLoaderData ends up triggering another error when the ErrorBoundary component loads.

Also, haven't explicitly tested it, but this will unmount/remount the Chat component which will blow away any state right?

I'm handing this right now with a try/catch block in all of my actions that catch errors and return them as an {errors: ...} object. Unfortunately, this still doesn't prevent errors that happen before the server can respond, like the user's internet dropping out right when they submit a form.

I know there has been other discussion about useFetcher having onLoad, onError, etc. callbacks, but they're still working out the API and use cases for it.

[kiliman]

Ah true. Good point. Although generally, it's nice that Remix handles errors for you, sometimes you need more explicit control. Hopefully, they'll expand on this in future updates.

[mdrahiem]

The above thing is perfect. A bit more (code sample) to the above explanation,

export function action() {
  return json({
      errors: {
        message: "Please enter a message",
      },
    },
    { status: 400 }
  );
}

export default function Chat({ children }: { children: React.ReactNode }) {
  const fetcher = useFetcher();

  return (
    <div>
      {/* this will come from the ErrorBoundary */}
      {children}
      <h1>Chat</h1>
      <fetcher.Form method="post">
        <input name="message" />
        {fetcher.data?.errors?.message && <p>Please enter a message</p>}
        <button type="submit">Send</button>
      </fetcher.Form>
    </div>
  );
}

[lukejagodzinski]

Any working solution to that? I'm surprised that there is no way to catch errors... Errors shouldn't propagate to the browser and should be caught by the useFetcher and exposed in the fetcher.error object.

Btw. in my case error boundary doesn't work...

[kiliman]

It should display the nearest ErrorBoundary. Do you have a simple repro?

[lukejagodzinski]

It's a little bit confusing what ErrorBoundary you mean. Do you talk about ErrorBoundary function exported in the same file as loader? Or typical ErrorBoundary wrapping your app? I might prepare repo but I first need to know how those error boundaries work in Remix. I think I tried both and nothing worked but maybe I did something incorrectly. From what I see the only option is to catch all the errors in the loader/action and just return json({ error }) to not cause website to "crash".

[iliapir2]

Any updates here?

[Update] Found relevant thread -> #4645

[zackify]

How’s this still not addressed… I have to find a different way to revalidate my page on interval due to laptops sleep and wake breaking the whole page :(

[notcome]

One workaround is to wrap each route with a client loader/action. There, you can call serverLoader/serverAction inside a try-catch block. If there is an error, you could replay the last loader result and add some error decorations.

Get action to work is relatively easy here. For loaders to work when the network is not ideal, you have to make sure that all parent loaders won't throw an error.

[mcfriend99]

Doesn't look like there is any solution so far?? Did anyone find something that works??