fix(form-core): fix broken sync/async validation logic

[juanvilladev]

Previously we were using a cumulative field errors map maintained at the form api level.
This PR removes that data structure in favor of a errorSourceMap data structure that lives within the FieldMeta for each field. This allows shifting/removing/deleting fields to automatically keep the errorSourceMap in sync.

This will fix #1323 and prevent other bugs from being raised around validation not working after other array actions like removing, shifting, swapping, moving, etc...

Async validation & sync validation now is fully synced and thoroughly tested with the new errorSourceMap. This reduces the complexity of using the cumulative errors map significantly and fixes all the issues with validations running on the wrong fields when removing/inserting/moving/shifting array fields.

Please review when you have time!

Thanks!

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 35d3c97.

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

---

☁️ Nx Cloud last updated this comment at 2025-04-19 23:10:24 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-solid-array
• @tanstack/form-example-solid-simple
• @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-svelte-array
• @tanstack/form-example-svelte-simple
• @tanstack/form-example-vue-array
• @tanstack/form-example-vue-simple

@tanstack/angular-form

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

@tanstack/form-core

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

@tanstack/lit-form

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

@tanstack/react-form

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

@tanstack/solid-form

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

@tanstack/vue-form

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

@tanstack/svelte-form

npm i https://pkg.pr.new/@tanstack/svelte-form@1370

commit: 35d3c97

[codecov]

Codecov Report

Attention: Patch coverage is 98.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.83%. Comparing base (1399731) to head (35d3c97).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/form-core/src/FormApi.ts	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1370      +/-   ##
==========================================
+ Coverage   88.70%   88.83%   +0.12%     
==========================================
  Files          31       31              
  Lines        1364     1379      +15     
  Branches      346      347       +1     
==========================================
+ Hits         1210     1225      +15     
  Misses        137      137              
  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.

[teleskop150750]

It would be great to stop saving the state of fields at the form level. This leads to duplication and divergence of states.

For example, how does it do
modular-forms

[juanvilladev]

It would be great to stop saving the state of fields at the form level. This leads to duplication and divergence of states.

For example, how does it do

modular-forms

Correct, that's why this PR removes the cumulativeErrorsMap which is at the form level and moves the error source to the fieldMeta. This way when the fieldMeta is shifted, moved, deleted, etc... the source remains valid.

[Balastrong]

Good call on moving this to the field meta, I like it!

[juanvilladev]

@Balastrong thanks for the review! I believe I've resolved all of the raised comments. Additionally, I created an equivalent function for determining the new error/error source at the field level validator functions (sync/async). This way its consistent for both form level/field level!

Additionally added tests for the new function and updated existing tests to ensure we cover the missed case you mentioned.

[juanvilladev]

Was manually testing #1336 and realized that for that issue the error comes from no optional chain operator being used when checking for the errorMapKey inside the errorMap dynamically:

 if (field.state.meta.errorMap[errorMapKey] !== newErrorValue)

Updated it to:

 if (field.state.meta.errorMap?.[errorMapKey] !== newErrorValue)

Had to add for both:
// eslint-disable-next-line @typescript-eslint/no-unnecessary-condition

Not sure why TS doesn't infer that the value could be undefined ¯\(ツ)/¯

Edit: Added it to two other spots as well where we access submit error key:

this.state.errorMap?.[submitErrKey]

[Balastrong]

There's just one tiny leftover from your tests probably, everything else looks good! :D

Speaking of the optional errorMap that would be an interesting investigation if you want, to validate if we should fix it on a type level (if we accept it might be undefined) or actually on the code to prevent it being undefined at all times. That's for a new PR anyway :)

[juanvilladev]

There's just one tiny leftover from your tests probably, everything else looks good! :D

Speaking of the optional errorMap that would be an interesting investigation if you want, to validate if we should fix it on a type level (if we accept it might be undefined) or actually on the code to prevent it being undefined at all times. That's for a new PR anyway :)

Updated! Thanks!

[Balastrong]

LGTM, thanks!