issue: isSubmitting does not recover when the submit handler throws

[karthikeyan-arumugam-1558]

Version Number

7.43.5

Codesandbox/Expo snack

https://codesandbox.io/s/axios-interceptor-react18-forked-89i3nq?file=/src/App.js

Steps to reproduce

1. Visit https://codesandbox.io/s/axios-interceptor-react18-forked-89i3nq?file=/src/App.js
2. Input something in the form and hit Enter
3. After 5 seconds (after the promise in the submit handler rejects), the button is still disabled

Expected behaviour

When the submit handler throws, isSubmitting should be reset to false

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bluebill1049]

We wouldn't be able to reset it if throw an error, you can consider resetting on your own usage.

[karthikeyan-arumugam-1558]

Thanks for the response @bluebill1049

const onSubmit: SubmitHandler<FormValues> = async (submissionData) => {
  try {
    await userService.forgotPassword(submissionData.email);
    toast.success("You'll receive the password reset link to your email if you have a valid account.");
    props.onClose();
  } catch (error) {
    genericToasts.error();
    /* Reset code here */
    throw error;
  }
};

This is my handler. I can reset, but I don't want to clear the data entered by the user; want to preserve submissionData which the user can edit again and re-submit. Could you kindly provide sample code?

[lucasrosa90]

Exactly. Using your case as example, what I'm doing here temporarily to solve it is:

const onSubmit: SubmitHandler<FormValues> = async (submissionData) => {
  try {
    await userService.forgotPassword(submissionData.email);
    toast.success("You'll receive the password reset link to your email if you have a valid account.");
    props.onClose();
  } catch (error) {
    genericToasts.error();
    reset(submissionData); // Adding reset with submitted data to reset the formState and keep the entered data.
    throw error;
  }
};

But I think the library should support it correctly.

[ShuttleSantalex]

or provide the documentation :)

[leapful]

@karthikeyan-arumugam-1558

Could you please explain why you need to throw error inside onValid callback of method handleSubmit from useForm hook ?

Usually if there is any back-end error in onValid callback, it should be handled with try catch statement and show error message on UI then flag isSubmitting will be reset to false as normal, no need to do anything more.

[karthikeyan-arumugam-1558]

@leapful, I want to throw so that global error handlers if any (eg., Sentry) will handle/report it

[leapful]

@karthikeyan-arumugam-1558

Keep throwing a catch error into global error handler is not a proper way to handle error, especially it's just for any background logic handling like logging in Sentry.

Usually, if an error is catch, it should be shown in UI to notify end-user or in case you, the developer, already knows there is an error via try catch statement and decides to silent log it by calling directly logging API like Sentry.captureException(e).

Error that can be reached to global error handler should be only unexpected error or runtime error which is missed to be handle or cannot be handled.

If you still want to achieve this behavior without following the best practice of error handler, just use Promise.reject(error) instead of throw error to avoid breaking onValid callback and then reject error in another promise.

[absreim]

Keep throwing a catch error into global error handler is not a proper way to handle error, especially it's just for any background logic handling like logging in Sentry.

Both Sentry and Datadog RUM expect to handle errors this way, and both products have fairly large user bases.

[karthikeyan-arumugam-1558]

Actually, I don't even have to throw. Even something like the below will cause this issue.

const onSubmit = async () => Promise.reject()

So simply put, if the API call fails, isSubmitting is stuck

[leapful]

@karthikeyan-arumugam-1558

It works for me in this example: https://codesandbox.io/s/pedantic-mcnulty-lt7imr?file=/src/App.tsx

Also works with your codesandbox example: https://codesandbox.io/s/axios-interceptor-react18-forked-pw6wtt?file=/src/App.js

[karthikeyan-arumugam-1558]

return Promise.reject, my friend. Doing just Promise.reject is of no use.

[leapful]

@karthikeyan-arumugam-1558

Yes, that's the idea for this workaround, to ensure no breaking on onValid callback and produce an unhandled rejection and leave it to global handler.

For example, it can be handled manually like:

Promise.reject(new Error('Failed to submit form !'));

window.addEventListener("unhandledrejection", (event) => {
  console.warn(`UNHANDLED PROMISE REJECTION: ${event.reason}`);
});

If you are using Sentry, it already setup the error handler for unhandled rejection to send to Sentry automatically

[ThomasWFord]

I'm having the same issue. I have a button which spins/disables while isSubmitting is true to prevent double clicks, but with the new versions (7.42 onwards) it doesn't get set back to false if an error is raised in the submit handler so the button never enables again.

Like @leapful I handle the exceptions elsewhere in a generic way. To me it makes sense for it to get reset back to isSubmitting: false as the form is no longer submitting even if there was an error.

I will probably need to downgrade for the moment.

[baba43]

I have the same problem, and I remember that it worked in the past. From my point of view, the current behavior is definitely a bug, because why does the logic handle only one of two possible cases?

The idea of being able to return a Promise in the first place is to automatically update the formstate. It is absolutely normal that a form update is accompanied by a fetch, and with it the possibility that it throws an error. Why do I need to catch this case separately?

[harish-prakash]

Agreed with @baba43, if the formState cannot be trusted, then it loses its purpose. Besides, its not a tech limitation just a missing feature, the handleSubmit could and must listen to this (perhaps optionally re-throw).

Looks like this was introduced with 7.42.0. I applaud the intent to avoid swalloing errors, but they must be gracefully re-thrown instead of messing with the form state.

• PR: https://github.com/react-hook-form/react-hook-form/pull/9688/files#diff-5a85c1643c71f45e050ce584d7c0db2bdf2e56f8a7dae86d74fedf01be2d2cab
• Release-PR https://github.com/react-hook-form/react-hook-form/pull/9603/files#diff-5a85c1643c71f45e050ce584d7c0db2bdf2e56f8a7dae86d74fedf01be2d2cab
• Changelog: https://github.com/react-hook-form/react-hook-form/blob/master/CHANGELOG.md#7420---2023-01-13

I've seen issue reports and attempted PR fixes both turned down because "the user must take responsibility of handling promise rejections/errors". 👈 again, a statement I agree..

Say my onSubmit (i.e. user callback) is passed down from another component, unless the onSubmit has a way to communicate success/failure to handleSubmit, I need to create a wrapper to update formStates manually which is ugly!

If you do not want to handle errors/rejections (which you are correct, you must not) then allow the user to return a false/true (or even a onComplete but that is too bulky) within the call back to inform the handleSubmit whether the submission succeeded of failed.

[seitbekir]

The huge problem here is that developers does not understand different patterns of usage. My OnSubmit function is in VM, unlike form definitions, which is in View controller. So I just add a try { ... } catch (e) { ... }. Why can't I just catch and handle it here?

[absreim]

So I just add a try { ... } catch (e) { ... }. Why can't I just catch and handle it here?

There is nothing wrong with using a try/catch block in the submit handler, but at the same time I don't see for the behavior of isSubmitting to fail if there is an unhandled error.

[ShuttleSantalex]

Encountered the same issue. An API call returns an error, button remains disabled. If this behavior is expected (which feels non-intuitive) then the documentation should at the very least reflect it explicitly.

[Moshyfawn]

#11084 (comment)

You can set a server (root) error using the setError form method when handling your submission exceptions to "tell" RHF what state your submission is in.

function Form() {
  const { handleSubmit, setError, formState } = useForm()

  const onSubmit = () => {
    try {
      throw new Error("internal server error")
    } catch (error) {
      setError("root.server", {
        type: "server",
        message: error.message,
      })
    }
  }

  const { isSubmitSuccessful } = formState // <== the isSubmitSuccessful state stays false on submit failure

  return <form onSubmit={handleSubmit(onSubmit, onInvalid)}>...</form>
}

[harish-prakash]

Discussion continues in https://github.com/orgs/react-hook-form/discussions/11088, to summarize.. the suggested option is not practical and it is most often an anti-pattern.

Comment link: https://github.com/orgs/react-hook-form/discussions/11088#discussioncomment-7383449

[martian17]

+1 for being able to return true/false from onSubmit
When undefined is returned, it should preserve the previous behavior.

[JeroenSchrader]

This has been fixed in react-hook-form version 7.50.0

See v7.50.0 release notes, or specifically this PR