Skip to content

Conversation

Balastrong
Copy link
Member

At the current state the types of form.setErrorMap are wrong (asking for a validator function) and field.setErrorMap allows everything.

With this PR the allowed types are now exactly the ones coming from the defined validators to ensure type safety is correct when reading the values (e.g. from field.getMeta().errors)

Copy link

nx-cloud bot commented May 6, 2025

View your CI Pipeline Execution ↗ for commit 9810565.

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

☁️ Nx Cloud last updated this comment at 2025-05-06 20:46:19 UTC

Copy link

pkg-pr-new bot commented May 6, 2025

More templates

@tanstack/angular-form

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

@tanstack/form-core

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

@tanstack/react-form

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

@tanstack/lit-form

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

@tanstack/solid-form

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

@tanstack/svelte-form

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

@tanstack/vue-form

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

commit: 9810565

Copy link

codecov bot commented May 6, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.96%. Comparing base (1920ade) to head (9810565).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1482      +/-   ##
==========================================
- Coverage   88.98%   88.96%   -0.02%     
==========================================
  Files          31       31              
  Lines        1398     1396       -2     
  Branches      353      353              
==========================================
- Hits         1244     1242       -2     
  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.

@Balastrong Balastrong merged commit 9a86503 into TanStack:main May 6, 2025
6 checks passed
@Balastrong Balastrong deleted the fix/match-types-in-set-error branch May 6, 2025 20:50
@frenzzy
Copy link

frenzzy commented May 7, 2025

How should server errors be set now?
Especially for server errors that are not tied to a specific field:

form.setErrorMap({ onServer: 'login or password is incorrect' });
// onServer: Type 'string' is not assignable to type 'undefined'.

@Balastrong
Copy link
Member Author

You shouldn't need to manually set server errors as they're automatically set from your server validator or in general by returning something from any other validator.

This also gives lets form.errors & co infer the correct error type

@MGRatEJOT
Copy link

How would I set an error that comes from a react-query mutation that was fired off on submit and failed? Previously this was no problem.

@Balastrong
Copy link
Member Author

The problem is also that since you have no validators set, when you read that error you have form.errors that is typed as undefined.

The only difference now is that setErrorMap prevents you from manually setting an error that is a different type than your validators.

For now you can setErrorMap({ onChange: yourError as never }) but I'm thinking we should replace undefined with unknown when no validator is set, so you won't need this cast.

@Balastrong
Copy link
Member Author

Also please @MGRatEJOT can you share your scenario in a separate issue? I'd like to have a better look. It would be great if you can include a stackblitz link

@MGRatEJOT
Copy link

MGRatEJOT commented May 7, 2025

Thanks for the quick info.

What is the best practice for my use case? The example with React Query lacks a validator and error handling. My setup is similar, but my query might return an error that I need to display on the form.

Edit: Sorry, I was already replying when your second post came in.

@vojtech-dobes
Copy link

I apologize upfront if this question is just wasting everybody's time. But could someone confirm, whether return field errors from onSubmitAsync is similarly type-checked (TS would complain about returning error for non-existent field)?

@Balastrong
Copy link
Member Author

I don't think I'm understanding the question, onSubmitAsync follows the same rules of the other validators and types are fully inferred.
If you think there's something not working right please create an issue with all the details so we can have a look :)

@vojtech-dobes
Copy link

@Balastrong Apologies, here is proper issue: #1537. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants