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.

[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

[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