Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stricter typing for validationSchema #4928

Open
shunjilin opened this issue Nov 6, 2024 · 2 comments
Open

Stricter typing for validationSchema #4928

shunjilin opened this issue Nov 6, 2024 · 2 comments
Labels
✨ enhancement a "nice to have" feature 👕 TypeScript TypeScript typings issue

Comments

@shunjilin
Copy link

Description:

I’m not sure if this issue has already been addressed or if it’s a limitation, so I apologize if this is redundant.

Currently, the validationSchema accepts any as its type, which allows any value to be assigned. In the example below:

type Form = {
  a: string;
};

useForm<{ a: string }>({
  validationSchema: "", // accepts any type
});

Solution

Would it be possible to narrow down the type of validationSchema to at least one of the following:

  • A Yup object with optional keys from Form that can be assigned to any, or
  • A record with optional keys from Form that can be assigned to any (since they accept validation rules or functions).

For reference, see docs.

Context:

I’m raising this because we had a case where we changed the Form type, but forgot to update the validationSchema. This led to an invalid property being set as required, causing the form to fail submission. Having stronger type safety for validationSchema would help prevent such issues.

Alternatives

A straightforward solution to this would be to use the typedSchema from yup or zod, but since we are already using another validation library effect-ts, we would like to avoid introducing an additional dependency.

I’d be happy to contribute if this approach seems suitable. Thanks!

@logaretm
Copy link
Owner

logaretm commented Nov 7, 2024

You raise a very good issue here. The problem I think was that we supported Yup by default, which caused the typed schema type inference to short circuit most of the time or resolve to incorrect types all together. So I handicapped the resolution.

if you want to try to give it another go by limiting the types go a head, But it would be a matter of seeing if this qualifies as a breaking change or not. If it is then maybe we should consider this for v5 with more aggressive changes like dropping yup built-in support.

@logaretm logaretm added ✨ enhancement a "nice to have" feature 👕 TypeScript TypeScript typings issue labels Nov 7, 2024
@shunjilin
Copy link
Author

shunjilin commented Nov 13, 2024

Thank you for the explanation! Understand the concern about this being a breaking change, will take a quick look to see if this can be mitigated, e.g. with an explicit typed flag

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement a "nice to have" feature 👕 TypeScript TypeScript typings issue
Projects
None yet
Development

No branches or pull requests

2 participants