issue: isSubmitting does not recover when the submit handler throws #10103
Replies: 15 comments 7 replies
-
We wouldn't be able to reset it if throw an error, you can consider resetting on your own usage. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the response @bluebill1049
This is my handler. I can reset, but I don't want to clear the data entered by the user; want to preserve |
Beta Was this translation helpful? Give feedback.
-
Could you please explain why you need to throw error inside Usually if there is any back-end error in |
Beta Was this translation helpful? Give feedback.
-
@leapful, I want to throw so that global error handlers if any (eg., Sentry) will handle/report it |
Beta Was this translation helpful? Give feedback.
-
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 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 |
Beta Was this translation helpful? Give feedback.
-
Actually, I don't even have to throw. Even something like the below will cause this issue.
So simply put, if the API call fails, isSubmitting is stuck |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 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.
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 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 |
Beta Was this translation helpful? Give feedback.
-
The huge problem here is that developers does not understand different patterns of usage. My |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
+1 for being able to return true/false from onSubmit |
Beta Was this translation helpful? Give feedback.
-
This has been fixed in See v7.50.0 release notes, or specifically this PR |
Beta Was this translation helpful? Give feedback.
-
Version Number
7.43.5
Codesandbox/Expo snack
https://codesandbox.io/s/axios-interceptor-react18-forked-89i3nq?file=/src/App.js
Steps to reproduce
Expected behaviour
When the submit handler throws,
isSubmitting
should be reset to falseWhat browsers are you seeing the problem on?
No response
Relevant log output
No response
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions