API for hooking into useFetcher lifecycle. Ex: useFetcher({onSuccess, onError, ...})

[cliffordfajardo]

What is the Proposal?

It would be helpful to be to hook into the event lifecycle of useFetcher & useSubmit hooks like this:

useFetcher	useSubmit
useFetcher({ onStart() {}, onError() {}, onSuccess() {}, onComplete() {}, }); <fetcher.Form onError onSuccess ... />	useSubmit({ onStart() {}, onError() {}, onSuccess() {}, onComplete() {}, }); <Form onError onSuccess ... />

What is the current challenge?

• If you wanted to do this behavior currently, you would have to write your own custom React.useEffect & clutter your component or write a hook abstraction over useSubmit & useFetcher
• Makes migrations harder, especially if you're using react-query, apollo-client, swr or similar react data fetching libs & relying on these lifecycle hooks for your UI experience

Use Cases

1. Fire off UI events (success/info/error toast notification, exception tracking)

2. Make migration's easier & strengthen incremental migration story
   • if you're using react-query, apollo-client, swr or similar react data fetching libs in a client side react app & you are trying to migrate to remix, you will run into the problem of not having access to lifecycle hooks like onSuccess, onError for your API calls, which are commonly used for showing success & error notifications in the UI.
   • When I was migrating my react SPA to remix, I remember thinking "this is going to be tough to sell to other React Teams that use react-query/swr" . I had remove all success/error notifications from app temporarily until I learned enough about remix to create my own abstraction over useSubmit & useFetcher
   • potentially saves user from needing to use an external data fecthing library early in their application development

What I've Tried:

I've created my own wrapper around useSubmit & useFetcher & currently need to maintain the code below. The code is error prone IMO because if Remix changes its APIs, my wrapper code would likely break.

// https://github.com/remix-run/remix/discussions/4559
const {submit} = useRemixFetcher({ onSuccess, onError, ...})
const {submit} = useRemixSubmit ({ onSuccess, onError, ...})

References

• Add `submitOptions` argument for `useSubmit` and `useFetcher` #9737 (comment)
• How to implement onSuccess, onError message after form submission like react-query? remix#4559
• https://tanstack.com/query/v4/docs/react/reference/useQuery

[brophdawg11]

Thanks for filing @cliffordfajardo! I'm going to transfer this to the react router repo since that's where useFetcher/useSubmit code lives now 👍

[brophdawg11]

Ugh, apparently transferring does not transfer the upvotes. If you had previously upvoted this proposal in the Remix repo, please upvote again in this repo!

[andreafdaf]

Hi! I would like to add a point of discussion to this proposal.

First of all I think it is awesome and sincerely welcome to add those callbacks to fetchers since they would make many situations more straightforward, but callbacks come with their own downsides when they start nesting.

In the current iteration of useFetcher we sometimes end in a useEffect hell, where the code flow completely loses linearity. Callbacks bring some sanity to those use cases but there are more complex use cases where instead of callbacks it would be preferable to have promises. I'm not saying that there should be promises instead of callbacks, but that there should be promises in addition to callbacks. (the old style: if you pass callback handlers there is no promise, if callback handlers are omitted it is promisified)

I understand that promisifying submit could be a breaking change for many since as of now it was never supposed to throw anything even if an error happens, so a promisified behavior might need to be behind a flag/param, only be included in a new major release or that maybe it should belong in some utility package.
However, they could be promises that return both error and data and never throw, so the callback flow provided initially would map to the following when using promises:

const promisifiedSubmission = async () => {
  try {
    onStart()
    const { error, data } = await submit({ param: 'value' }, { action: '/some/action' })
    if (error) {
      onError(error)
    } else {
      onSuccess(data)
    }
    onComplete()
  } catch (e) {
    onNastyUnexpectedError(e)
  } finally {
    onFinallyCompleted()
  }
}

Of course this is just one example of what it can be mapped to, but I think it is already clear that promises bring much more control into the request flow than callbacks.
Supporting promises we would then be able to do more complex submissions, like the following (or whatever else) that would be much less linear using callbacks:

const promisifiedMultiSubmission = async () => {
  try {
    onStart()
    const result1 = await submit({ param: 'value' }, { action: '/some/action' })
    if (result1.error) {
      onFirstError(result1.error)
      return onComplete()
    }
    const result2 = await submit(result1.data, { action: '/some/other/action' })
    if (result2.error) {
      onSecondError(result2.error)
    } else {
      onSuccess(result2.data)
    }
    onComplete()
  } catch (e) {
    onNastyUnexpectedError(e)
  } finally {
    onFinallyCompleted()
  }
}

Anyway I just wanted to add another point of view to a very welcome proposal, IMHO when working with data transfers the more flexibility we have as developers the simpler it is to adopt a new library/framework. (as of now the simplicity of useFetcher is both a blessing and a curse)

[cliffordfajardo]

i haven't experienced a use-case yet for an await API API but,
this is a popular pattern in some react libs

For example, react-query allow you to use the hook version of an API or its async version:

Hook without `async/await

const CreateTodo = () => {
  const [title, setTitle] = useState('')
  const mutation = useMutation({ mutationFn: createTodo })

  const onCreateTodo = (e) => {
    e.preventDefault()
    mutation.mutate({ title })
  }

with `async/await

_Use mutateAsync instead of mutate to get a promise which will resolve on success or throw on an error. This can for example be used to compose side effects. react-query docs

const mutation = useMutation({ mutationFn: addTodo })

try {
  const todo = await mutation.mutateAsync(todo)
  console.log(todo)
} catch (error) {
  console.error(error)
} finally {
  console.log('done')
}

References

• https://tanstack.com/query/v4/docs/react/guides/mutations#promises

[cliffordfajardo]

Related thread in Remix Discussions tab

• Return a promise from submit remix#5023

[ryanflorence]

I've got a half proposal written up for this exact thing that I haven't published. I'm on board. Anything to avoid another useEffect in my code.

[jaschaio]

2 years later did the proposal ever get published?

[irshadahmad21]

It's not possible to use Async react-select in Remix without promisifying submit/load. Loading the options asynchronously in react-select is probably the best use-case for promisified submit/load.

[brophdawg11]

Related proposal over in Remix: remix-run/remix#4645

[brophdawg11]

Also worth noting that when we do this we should likely do the same for useRevalidator which has similar behavior

[abelsj60]

I have no solution to the following.

Sometimes, when you do this:

export function TopComponent() {
  const myDeeplyNestingFetcher = useFetcher();
  ...
    return (
      <C1>
        <C2 fetcher={myDeeplyNestingFetcher} />
        <C3 fetcher={myDeeplyNestingFetcher} />
      </C1>
   );
}

and this:

export function C2 ({ fetcher, ...rest }: { fetcher: FetcherWithComponents<any>; ...rest }) {
  const [state1, setState1] = React.useState('');
  const [state2, setState2] = React.useState(0);

  return (
    <div>
      <...stuffWithState>
      <button onClick={(e) => fetcher.submit({ e.currentTarget.value }, { action: 'x', method: 'post' })}>Submit</button>;
    </div>
  );
}

you could end up in a situation where you sorely wish you could add these callbacks to the fetcher invocation itself, i.e,

fetcher.submit({ e.currentTarget.value }, { action: 'x', method: 'post', onSuccess: () => 'So close to the action!' });
<fetcher.Form ... onSuccess={() => 'Still so close to the action!'}><...stuff></fetcher.Form>;

instead of only being able to do it up top at the level of the hook's invocation, i.e.,

const fetcher = useFetcher({ onSuccess: () => "That's a long way down!" });

I don't know if the other proposal about promises could help here, and I suppose there may be ways to code around this, but I'm not sure that's always realistic.

Sometimes you can't redesign your architecture because it's "done." And no one wants to hear it anyway. And your ticket's gotta get cleared. Well, in that unspoken, but sometimes realistic scenario, I can imagine this level of flexibility could make someone's day.

[eagsalazar]

Revalidator might also benefit from this treatment. The one specific use case is when the network is down temporarily, calling revalidate will result in a hard crash (can't fetch chunk error) that can only be caught at the root route. Pretty intense. Would be great to at least be able to locally handle that category of errors, where revalidate() never even made it back to the loaders at all.

[dctanner]

I want to be able to use the revalidator with an interval to refresh content. But on network error it breaks the whole app and cannot recover. It would be great to be able to hook into the errors and just show an offline indication when the network is down.

[dctanner]

I want to be able to refresh my loader at an interval. I tried using useRevalidator and useFetcher with intervals, but both throw a whole error when the network is down (every time I open my laptop with the app still open).

Here is the somewhat hacky solution I'm using for now. I'd welcome any suggestions for simplifying it: https://gist.github.com/dctanner/882a71fbb6f15153108cdfdf5f33c545

[marwan38]

Hi, this is a direct copy of this since here might be the more appropriate place.

Running useFetcher().load() that fails due to a network connection problem: either net::ERR_CONNECTION_REFUSED or net::ERR_NETWORK_CHANGED throws an error that can't be caught an handled on the spot, it propagates up to the error boundary. The easiest way to reproduce this is to create a poll that runs the load() in an interval, and then closing down the remix server.

function Component() {
  const fetcher = useFetcher();
  useEffect(() => {
    setInterval(() => { fetcher.load('/user/notifications') }, 1000);
  }, []);
}

My work around is

function Component() {
  const fetcher = useFetcher();
  useEffect(() => {
    setInterval(() => {
      // /dev/null is a route that does nothing, it's just there as a "health check"
      fetcher.load("/dev/null").then(() => fetcher.load("/user/notifications"));
    }, 1000);
  }, []);
}

I expect to be able to handle errors gracefully, but, the load() function is handled internally and the error cannot be caught.
What are the work arounds? Is this the intention of load()?

[juniorforlife]

@cliffordfajardo do you know if there's any progress for this proposal?

[eagsalazar]

Will these changes make it into V2? And do we have a rough date for V2's release?

[hanayashiki]

The current remix error handling is totally unacceptable. I guess I'll just integrate with react-query until whatever one of these proposals are implemented.

[SeanRoberts]

Have you found a way to replace useFetcher with react-query while still getting revalidation on actions and loaders?

[hanayashiki]

even if revalidation works, remix does not keep referencial stableness when data are the same after refetching

[Kuboczoch]

@hanayashiki Are you still using react-query, or did you find a way with remix useFetcher to work to have a full lifecycle?

[gustavopch]

In most situations, you can use useEffect to run what you need after a submission (although making the code flow lose its linearity).

But I think there one case where such workaround isn't very useful: tracking an analytics event after a successful submission that redirects to another route.

I mean, redirecting means the useEffect with the tracking snippet won't run, so the only alternative is to not redirect in the action and instead return a response, let the useEffect run and then call navigate to go to the other route. At this point, the code is much more complex and weird than it needed to be.

[p-christ]

This proposal would be very welcome

[nico1510]

In case it helps anyone, you can use a clientLoader to work around this as follows:

export const clientLoader = async ({
  serverLoader,
}: ClientLoaderFunctionArgs) => {
  try {
    return await serverLoader();
  } catch (e) {
    // handle error, return fallback etc. 
  }
};

[candidia]

I really like this way. Now you can write your actions and loaders just like normal, no having to hijack good responses with error bodies, and then when using a fetcher to hit that action/loader you just do this and return the error in your special formatting. It moves that logic to the right place on the client.

[punkpeye]

This is the solution I ended up for https://glama.ai

import { usePrevious } from './usePrevious';
import { useEffect, useRef } from 'react';

const usePrevious = (value: unknown) => {
  const ref = useRef<unknown>();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
};

const useOnSubmit = ({
  state,
  onSubmit,
}: {
  onSubmit: () => void;
  state: 'submitting' | 'idle' | 'loading';
}) => {
  const submitting = state === 'submitting';

  const previousSubmitting = usePrevious(submitting);

  useEffect(() => {
    if (previousSubmitting && !submitting) {
      onSubmit();
    }
  }, [previousSubmitting, submitting]);
};

Then just use it like this:

const fetcher = useFetcher<typeof action>();

useOnSubmit({
  onSubmit: () => {
    // your logic
  },
  state: fetcher.state,
});

[bryantbrock]

For anyone interested, I created a useAsyncFetcherSubmit but you can call it whatever you want / create on for the .load method. Here is how I implemented it.

Usage

const { submit, isLoading } = useAsyncFetcherSubmit()
...
await submit({ data: 'yep' }, { method: 'POST', action: '/api/path' })
...
<button disabled={isLoading} />

Implementation

import { useFetcher } from '@remix-run/react'
import { useState, useCallback, useEffect } from 'react'

export const useAsyncFetcherSubmit = () => {
	const fetcher = useFetcher()
	const [isLoading, setIsLoading] = useState(false)
	const [pendingPromise, setPendingPromise] = useState<{
		resolve: () => void
		reject: (error: any) => void
	} | null>(null)

	const submit = useCallback(
		(
			submitData: Parameters<typeof fetcher.submit>[0],
			options?: Parameters<typeof fetcher.submit>[1],
		) => {
			return new Promise<void>((resolve, reject) => {
				fetcher.submit(submitData, options)
				setIsLoading(true)
				setPendingPromise({ resolve, reject })
			})
		},
		[fetcher],
	)

	useEffect(() => {
		if (fetcher.state === 'idle' && pendingPromise) {
			setIsLoading(false)
			pendingPromise.resolve()
			setPendingPromise(null)
		}
	}, [fetcher.state, pendingPromise])

	return { submit, isLoading, fetcher }
}

[peter-skillmasters]

As mentioned above...a major problem with the current error handling situation is when the user loses an internet connection, there's no way to gracefully handle that without the entire route's state being lost. If the raw fetch() call throws an error (like "Failed to Fetch"), then the ErrorBoundary is immediately displayed, and I cannot find a reasonable way to circumvent that.

In my particular case I have a form that needs to be updated repeatedly in a physical place without a guaranteed internet connection. If the user loses the connection, showing a simple error message/toast on the same route without losing any state would be ideal. But as it stands now, the error boundary is shown, state is lost, and the user is stuck until they reconnect.

I understand the flaws of making load() & submit() async with data/errors. An alternative approach:

• an option to disable the default error boundary behavior i.e. preventErrorBoundary or something like that
• when disabled, error responses and raw fetch errors like "Failed to Fetch" are caught and the error is set on the fetcher or can be returned from a special hook for actions (useActionError)

function ActionForm() {
  // A hook to get the latest error from the submitted action
  const actionError = useActionError()
  return (
    <Form preventErrorBoundary>
      {actionError && <ErrorMessage error={actionError} />}
      {/* ...rest of the form */}
    </Form>
  )
}

function FetcherForm() {
  const fetcher = useFetcher()
  return (
    <fetcher.Form preventErrorBoundary>
      {/* new fetcher.error property */}
      {fetcher.error && <ErrorMessage error={fetcher.error} />}
      {/* ...rest of the form */}
    </fetcher.Form>
  )
}

// and when called imperatively:
const submit = useSubmit();
submit({}, { preventErrorBoundary: true })
const fetcher = useFetcher();
fetcher.load("/some/route", { preventErrorBoundary: true })
fetcher.submit({}, { preventErrorBoundary: true })

As a bonus, this would make it easier to handle "known" error responses - like 422s with validation errors - with toast messages. What do you think?

[brophdawg11]

FWIW you can do this today with a clientLoader

[peter-skillmasters]

Thanks! This is a good solution for one-off cases that I'll start using

But If you want to make an error handling pattern throughout the app, you have to add one for every single loader/action, which is obviously tedious and easy to get wrong.

Network errors are common enough that I would love for react-router to have a good DX for dealing with them that doesn't require a ton of boilerplate. clientMiddleware would be a nice alternative, but I don't think it's possible to modify the response

[punkpeye]

As mentioned above...a major problem with the current error handling situation is when the user loses an internet connection, there's no way to gracefully handle that without the entire route's state being lost.

Having a lot of problems with this.

In the context of a chat app, the consequences are pretty disastrous because it means that the message that the user was composing is lost.

[brophdawg11]

FWIW you can do this today with a clientLoader

[azuisleet]

After spending time with the framework, I think the expectation is that if you want to avoid error propagation to the nearest boundary, you are meant to use any fetch-based escape hatch.

The trouble with many of the proposals here is that it's a modification of the request/response/revalidation process for a specific request that can involve many other routes (or mounted fetchers). The story might be somewhat different with singleFetch.

[brophdawg11]

FWIW you can do this today with a clientLoader

[brophdawg11]

Hey folks! It sounds like most of this discussion boils down to 2 things:

1. How do I do stuff when my fetcher completes?

Obviously you can use an effect here but we all know useEffect can be a footgun so having to write less of them is a welcome choice.

Since this proposal was opened, we have started returning promises from fetcher.load/submit, so I'm curious if this is a viable solution to onSuccess and potentially onError (see bullet 2)? We do not currently return the data through the fetcher promise (for architectural reasons) so I think we would need to also implement that for this to be realistic.

<button onClick={async () => {
  let data = await fetcher.load(path);
  onSuccess(data)
}})

This approach would also likely play nice with useActionState

2. I don't want fetcher errors to trigger my error boundary

This is currently something you can avoid with a clientLoader but that has other impacts (such as opting that route out of single fetch when used on a navigational route) so I could see the use-case for allowing a fetcher to skip it and let you handle the error in your component.

A few ideas off the top of my head:

// (a) To align with the behavior of the clientLoader approach, we could just 
// let the error return through as "data", but this could open up some weird 
// type issues with  useFetcher<typeof loader>()
let data = fetcher.load(path, { bubbleError: false })

// (b) We could give you a handler to transform the error like you might do 
// in a clientLoader to align to the type.  When used with `useFetcher<typeof loader>`
// the return value from `handleError` would need to satisfy the type the return type 
// of the loader so the shape of the returned data would be accurate in both success 
// and error cases
function loader(): { error?: unknown, data?: Data } {
  return { data: getData() };
}
let data = fetcher.load(path, { 
  handleError(error: unknown) {
    return { error }
  }
})

// (c) We could reject the fetcher.load/submit promise
<button onClick={async () => {
  try {
    let data = await fetcher.load(path);
  } catch (e) {
    handleError(e);
  }
}})

[okalil]

Just out of curiosity, when using server function inside handler, what would be the difference between fetcher.load() and fetcher.submit()? Also, what would be the advantage over using fetcher in that case instead of useActionState?

[sergiodxa]

@okalil when you use fetcher.load this fetcher is not revalidated automatically after an action runs, like route loaders

When you use fetcher.submit with method GET that fetcher is not revalidated automatically after an action runs

[okalil]

@sergiodxa Sure. I asked because in the unstable RSC demo server functions would always cause a revalidation.

[brophdawg11]

Not anymore 😉

[okalil]

So.. I've been thinking.. Remix was always focused on providing the best UX and resilience out of the box. I think we all agree using error boundaries for fetchers (and for actions) leads to bad UX, so I don't think it should be the default behavior. The proposals for customizing the error handling are all interesting, but they are opt-in. In my view, a different behavior for better UX by default would be more aligned with Remix/ReactRouter principles.