Closed AdiRishi closed 2 months ago
@AdiRishi So the reason your form does not work as you'd expect it is because the handleSubmit that is passed to the Form component actually uses useSubmit
under the hood and submits to the current location, the extra submitConfig
is basically used to override this behavior for the useSubmit. The method and action should be there as well in case JS isn't loaded but otherwise it would work as expected if you add the config.
The isSubmitSuccessful
mimics the behavior from react-hook-form where it is set as soon as the data is SENT to the server. isSubmitting
is used to determine if the submission is still going on.
So these are not bugs per say, but could be potentially improved upon. It's very hard to determine on the hooks end if the submission was successful. What if you return 200 with errors, or redirect to somewhere. Although I think it would maybe be possible to access the form event and get the method and action instead of having to define it via config though.
@AlemTuzlak thanks for looking into this. Do you think it's reasonable for the library to try and extract the method + action from the form directly? I'm fairly certain you would be able to reach it via event.target
?
Just a little more clarification. As you said, when we add the submitConfig
option to SubscribeFormThatDoesNotWork
it does indeed post to the correct location. But it also does a page reload and moves to that action route.
Is that expected default behavior? It seems like we need to specify a fetcher and use fetcher.Form
in order to get it to submit the form via ajax requests
Re your point on determining success vs failure. Yeah it makes sense, there are many scenarios that could mean success or failure. Generally speaking however I think it seems reasonable to assume a non-2xx response is a failure.
I can always get around this by try/catch on the action and make sure there is no uncaught error. What is the canonical way to return a "route failure" to the form with this library?
Thanks! I've learned a bit more since I made this issue, seems fetcher doesn't really return error states since it propagates that up to the error boundary. Maybe it makes sense for us to provide a helper error boundary that understands form errors or "top level" errors that can be thrown from the API.
Leaving the issue open since I plan to revisit this and maybe make a PR if I find a reasonable solution to these issues.
@AdiRishi I implemented this behavior in v5.0.0
I've encountered a problem with remix-hook-form where form submissions are not behaving as expected or as I believe is documented. My apologies in advance if this issue stems from a misunderstanding on my part. However, after several attempts and reviews of my code, I'm inclined to believe there might be an underlying issue with how remix-hook-form handles form submissions, specifically when trying to use the method="post" and action attributes without explicitly using a useFetcher.
Overview
method="post"
and an action pointing to a route, I expected the form submission to be directed to the specified route without causing a full page reload.action
prop. This behavior suggests that the form props are not being read and submission is not using the underlying fetcher as the docs state.useFetcher
and specifying asubmitConfig
in the form setup. This approach seems counterintuitive if the library is supposed to handle submissions more seamlessly by default.Issue reproduction
I've made a repository that demonstrates the problem. You can find it here - https://stackblitz.com/edit/remix-run-remix-xr6vlj?file=app%2Froutes%2F_index.tsx
Key Points:
SubscribeFormThatDoesNotWork
) doesn't use useFetcher and fails to submit properly, causing a page reload. The other (SubscribeFormThatDoesWork
) uses useFetcher and works fine, submitting without reloading the page.form.formState.isSubmitSuccessful
value that comes back from remix-hook-form is completely wrong. I've setup the API endpoint to respond with a 400, and yet it doesn't reflect that at all. Also the value is set as soon as the request initiates, it doesn't wait for successConclusion
Again, I'm very sorry if I'm being dumb and missing something obvious, but I can't for the life of me figure out what is going wrong. Looking forward to finding out more 🙏