fix(form-core): touch all fields regardless of canSubmit in <form>.handleSubmit()

[LeCarbonator]

The early return on this line prevents fields from being marked as touched.

Test cases have been added to address this inconsistency. It's assumed that the following statements must be true:

• handleSubmit() touches all fields, even if it canSubmit === false
• handleSubmit() does not call form validators if field validators errored
• handleSubmit() calls form validators if field validators succeeded

Reasoning for the first assumption

validateAllFields is called during handleSubmit, which touches all fields. However, that code is not reached if validation errored beforehand.

This can lead to results where an optional field is edited, causing an onChange error in a required field that is not yet touched (a form-level validation schema, for example).

The form is now invalid and will not validate all fields, despite no obvious error appearing as no required fields were touched.

This PR closes #1360 if merged.

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 5ee9576.

Command	Status	Duration	Result
nx affected --targets=test:sherif,test:knip,tes...	✅ Succeeded	1m 56s	View ↗
nx run-many --target=build --exclude=examples/**	✅ Succeeded	19s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-04-17 20:27:42 UTC

[pkg-pr-new]

More templates

• @tanstack/form-example-angular-array
• @tanstack/form-example-angular-simple
• @tanstack/form-example-lit-simple
• @tanstack/form-example-lit-ui-libraries
• @tanstack/form-example-react-array
• @tanstack/form-example-react-compiler
• @tanstack/field-errors-from-form-validators
• @tanstack/form-example-react-large-form
• @tanstack/form-example-react-next-server-actions
• @tanstack/form-example-react-query-integration
• @tanstack/form-example-remix
• @tanstack/form-example-react-simple
• @tanstack/form-example-react-standard-schema
• @tanstack/form-example-react-tanstack-start
• @tanstack/form-example-react-ui-libraries
• @tanstack/form-example-solid-array
• @tanstack/form-example-solid-simple
• @tanstack/form-example-vue-array
• @tanstack/form-example-vue-simple

@tanstack/angular-form

npm i https://pkg.pr.new/@tanstack/angular-form@1367

@tanstack/form-core

npm i https://pkg.pr.new/@tanstack/form-core@1367

@tanstack/lit-form

npm i https://pkg.pr.new/@tanstack/lit-form@1367

@tanstack/react-form

npm i https://pkg.pr.new/@tanstack/react-form@1367

@tanstack/solid-form

npm i https://pkg.pr.new/@tanstack/solid-form@1367

@tanstack/vue-form

npm i https://pkg.pr.new/@tanstack/vue-form@1367

commit: 5ee9576

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.57%. Comparing base (ba66490) to head (5ee9576).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1367      +/-   ##
==========================================
+ Coverage   88.52%   88.57%   +0.05%     
==========================================
  Files          28       28              
  Lines        1316     1322       +6     
  Branches      343      345       +2     
==========================================
+ Hits         1165     1171       +6     
  Misses        134      134              
  Partials       17       17              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[juanvilladev]

Looks like you're completely removing the canSubmit check. Instead I think something safer would be to move the validateAllFields line above canSubmit. If we simply remove the canSubmit flag, I don't see the point in having it?

validateAllFields is what marks them all as touched.

Even then I'm not sure if maintainers would be okay with always allowing validateAllFields to run despite canSubmit being false?

[LeCarbonator]

Looks like you're completely removing the canSubmit check. Instead I think something safer would be to move the validateAllFields line above canSubmit. If we simply remove the canSubmit flag, I don't see the point in having it?

validateAllFields is what marks them all as touched.

Even then I'm not sure if maintainers would be okay with always allowing validateAllFields to run despite canSubmit being false?

Indeed. It's the main reason I marked it as draft, as the implemented solution isn't a solution at all. However, some of the test cases are set up, and there's still some questions left up for discussion about how the behaviour should work.

I think the main point of the canSubmit flag is that the user can access it in the frontend and, say, disable the submit button. Once handleSubmit is called, the question is what should always happen and what should be conditional.

[juanvilladev]

Looks like you're completely removing the canSubmit check. Instead I think something safer would be to move the validateAllFields line above canSubmit. If we simply remove the canSubmit flag, I don't see the point in having it?

validateAllFields is what marks them all as touched.

Even then I'm not sure if maintainers would be okay with always allowing validateAllFields to run despite canSubmit being false?

Indeed. It's the main reason I marked it as draft, as the implemented solution isn't a solution at all. However, some of the test cases are set up, and there's still some questions left up for discussion about how the behaviour should work.

I think the main point of the canSubmit flag is that the user can access it in the frontend and, say, disable the submit button. Once handleSubmit is called, the question is what should always happen and what should be conditional.

Oh! Completely missed this was a draft. My bad! Nice, I understand what you mean. Perhaps some might find it weird if canSubmit is false, yet user CAN technically submit without users of the library explicitly disabling the button.

[LeCarbonator]

Looks like you're completely removing the canSubmit check. Instead I think something safer would be to move the validateAllFields line above canSubmit. If we simply remove the canSubmit flag, I don't see the point in having it?
validateAllFields is what marks them all as touched.
Even then I'm not sure if maintainers would be okay with always allowing validateAllFields to run despite canSubmit being false?

Indeed. It's the main reason I marked it as draft, as the implemented solution isn't a solution at all. However, some of the test cases are set up, and there's still some questions left up for discussion about how the behaviour should work.
I think the main point of the canSubmit flag is that the user can access it in the frontend and, say, disable the submit button. Once handleSubmit is called, the question is what should always happen and what should be conditional.

Oh! Completely missed this was a draft. My bad! Nice, I understand what you mean. Perhaps some might find it weird if canSubmit is false, yet user CAN technically submit without users of the library explicitly disabling the button.

Along with the test cases, the canSubmit check should now be restored. It simply marks all fields as touched before doing so.

That leaves the other questions up for debate, but this is a start.

[danharper]

Would love to see a fix landed for this - first time using tanstack form and hit this exact issue! Landed on the same solution myself - either removing the "canSubmit" early return, or explicitly touching all fields :)

---

The "standard schema" example shows this bug pretty well, plus oddities with "canSubmit".

Type into first name, and you won't see any errors for last name until you focus & blur that field - "Submit" is disabled so you'll only know why it can't be submitted until you click in & out of each field.

riewj.mov

Along with removing the disabled={!canSubmit} logic on the button in the example, this PR fixes everything -- the other field errors are shown after clicking the button.

[LeCarbonator]

Would love to see a fix landed for this - first time using tanstack form and hit this exact issue! Landed on the same solution myself - either removing the "canSubmit" early return, or explicitly touching all fields :)

The "standard schema" example shows this bug pretty well, plus oddities with "canSubmit".

Type into first name, and you won't see any errors for last name until you focus & blur that field - "Submit" is disabled so you'll only know why it can't be submitted until you click in & out of each field.
riewj.mov

Along with removing the disabled={!canSubmit} logic on the button in the example, this PR fixes everything -- the other field errors are shown after clicking the button.

I initially waited because of the quick and dirty fix I implemented and to hear more of the contributors, but since properly implementing it and genuine issues coming up with this bug, I'll mark the PR ready for review. I can always make a future PR if needed :)

[ibnumusyaffa]

i think its solved with the new canSubmitWhenInvalid form option in this PR

#1234

[LeCarbonator]

i think its solved with the new canSubmitWhenInvalid form option in this PR

#1234

Not quite. The linked PR addresses validation to still run even if canSubmit is false (using the provided option). This PR addresses that it should always touch all fields, regardless of canSubmit.

[Balastrong]

We're saying that clicking the submit button should always touch all fields?

To be honest I don't like it. To me a field is touched only if the user has actually interacted with it, which is not what is happening here.
However, validateAllFields is already touching everything anyway.

I believe checking on validationAttempts > 0 || isTouched should be the right condition to show errors without having to touch everything but until we change the isTouched behaviour (I'm not saying it's gonna happen) I believe this PR goes into the right direction making for consistency.

Thank you, great work!

[LeCarbonator]

We're saying that clicking the submit button should always touch all fields?

To be honest I don't like it. To me a field is touched only if the user has actually interacted with it, which is not what is happening here.

However, validateAllFields is already touching everything anyway.

I believe checking on validationAttempts > 0 || isTouched should be the right condition to show errors without having to touch everything but until we change the isTouched behaviour (I'm not saying it's gonna happen) I believe this PR goes into the right direction making for consistency.

Thank you, great work!

True! However, I see the submit button as "I am sending what I have seen and written your way". If a field is untouched, submitting would therefore imply that the user saw no reason to touch it and is okay with the given default.