Why doesn't formState.isSubmitting reset to false if onSubmit throws?

[Mudbill]

Maybe there's an obvious reason I'm not considering, but I had a situation like the following:

const someApiCallThatFails = () => new Promise((resolve, reject) => setTimeout(reject, 1000));

const { handleSubmit, formState: { isSubmitting } } = useForm();

const onSubmit = handleSubmit(async (values) => {
  await someApiCallThatFailed(values);
});

return (
  <form onSubmit={onSubmit}>
    <button type="submit" disabled={isSubmitting}>Submit</button>
  </form>
)

The promise ends up rejecting, but isSubmitting remains true. Shouldn't it reset to false?

It works as expected by wrapping the await in a try-catch or appending .catch(() => {})

[Moshyfawn]

RHF doesn't support throwing errors in the submit handler with the current API design.

We used to "swallow" the error, which is wrong.

When you throw inside the submit handler, some part of RHF state handling code is not run, hence your use-case.

Please, handle rejected promises in your code instead.

[Mudbill]

I suppose that is fair enough. The reason I came upon this situation is because I'm using React Query, which requires promises to throw on failure. With RQ I can do something like this:

const request = useMutation(someApiCall);

const onSubmit = handleSubmit(async (values) => {
  await request.mutateAsync(values, {
    onSuccess: (data) => { /**/ },
    onError: (error) => { /**/ }
  });
})

This has been my preferred method of error handling rather than try-catch. But obviously this method doesn't seem to be supported by RHF. Perhaps the issue is that RQ still rejects the promise (seemingly) despite defining onError.

But oh well, I suppose there's not much to be done about that here, unless you happen to know some cool trick for these situations :)

[npearson72]

@Mudbill, I ran into the same thing. Agree, the callback syntax is cleaner looking. Odd that RQ doesn't wrap the mutationFn in a try/catch. Have you looked into why that is?

[Mudbill]

@npearson72 I have not, but I think they do wrap it since they require the mutationFn to throw on error (which consequently triggers onError). It just looks like they re-throw the error afterwards, or rather reject the promise, since this only really happens with the awaited async version, which must be awaited for RHF's isSubmitting to be usable. Bit annoying but I guess that's just how it is.

[echo-999]

Hello, I know it's been a while, but you can check this out: TanStack/query#121 (comment)

Basically, if you use the asynchronous version of the useMutation, you have to handle the rejection yourself (or else it will be Uncaught).

[TadejPolajnar]

I have the same issue with hook form(v7.43.0) and wrapping the function inside try&catch block didn't work, isSubmitting was still set to true after request failure. As a temporary fix I removed isSubmitting from hook form and replaced it with react-query's isLoading.

const { isLoading, mutateAsync } = useMutation({
  mutationFn: asyncFunc
  //...config
});

const { handleSubmit } = useForm({
//...config
});

return (
  <form onSubmit={handleSubmit(mutateAsync)}>
    <button type='submit' disabled={isLoading}>Submit</button>
  </form>
);