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

Run low-pri validation at a given field / path in schema #1578

Merged
merged 3 commits into from
Jun 27, 2019

Conversation

jaredpalmer
Copy link
Owner

@jaredpalmer jaredpalmer commented Jun 2, 2019

This PR tweaks validation so that Formik runs low-priority validation at the field level. That means that only the slice of the Yup schema and/or a single <Field validate> will be executed for a given change/blur. During pre-submit (i.e. high-priority validation), the entire schema is validated against values and all field-level validate fns are run (this is the current behavior). (I think) Yup is smart enough now that to deal with dependent schema paths (when and refs) so this should be non-breaking.

Continues v1 work by @jquense in #780

Details

  • Use Yup's validateAt to validate the schema at a given path (instead of the entire schema) during run low-priority validation.
  • Only execute a field's registered <Field validate>fn during low-priority validation (instead of running all registered field-level validation fns)

Next Steps

I rushed through this initially to get an MVP going. We may want to refactor some stuff to make things easier.

@jaredpalmer jaredpalmer changed the title [v2] Use validateAt for change/blur validation [v2] WIP Run low-pri validation at a given field / path in schema Jun 2, 2019
@jaredpalmer jaredpalmer changed the title [v2] WIP Run low-pri validation at a given field / path in schema [v2] Run low-pri validation at a given field / path in schema Jun 6, 2019
@jaredpalmer
Copy link
Owner Author

@jquense does validate at properly degrade with .when?

@jquense
Copy link
Contributor

jquense commented Jun 10, 2019

If you are using validateAt it will do the correct thing with whens e.g. it resolve the dependent values and then only run validation for the specific field.

The only edge case is when field a change to field foo would invalidate field bar, but there isn't really anything yup can do in those cases, same as with plain validate functions for fields. Theoretically yup could do better than individual validate()s since it knows which fields may be invalidated, but I'm not sure what that api would look like. Happy to brainstorm tho, if you want that added benefit, otherwise the yup case here is the same as the non-yup case for that gotcha

@jaredpalmer
Copy link
Owner Author

@jquense my solution to that is to use the function form of validationSchema anyways.

@jquense
Copy link
Contributor

jquense commented Jun 10, 2019

nice yeah, I'd say that covers workarounds then? It's not a super common thing to deal with anyway, idk that there is a lot of value in yup trying to be smarter to handle it?

@jaredpalmer
Copy link
Owner Author

Probably not. We should document this situation and make an example of the solution.

@jaredpalmer jaredpalmer changed the base branch from next to master June 27, 2019 15:02
@jaredpalmer jaredpalmer changed the title [v2] Run low-pri validation at a given field / path in schema Run low-pri validation at a given field / path in schema Jun 27, 2019
@jaredpalmer jaredpalmer merged commit 7ba657c into master Jun 27, 2019
@Smau5
Copy link

Smau5 commented Jul 1, 2019

i would love to have some examples for this.

jaredpalmer added a commit that referenced this pull request Jul 9, 2019
jaredpalmer added a commit that referenced this pull request Jul 9, 2019
* Revert "Run low-pri validation at a given field / path in schema (#1578)"

This reverts commit 7ba657c.

* Bump Yup
@gauravkhuranacopart
Copy link

Can we have some example of it ?

@estshy
Copy link

estshy commented Nov 20, 2019

@jaredpalmer Could you share an example of how to use it? For me it seems both input and form level validations are executed together.

@jaredpalmer jaredpalmer deleted the feat/validateAt branch December 12, 2019 19:28
@ersinakinci
Copy link

For anyone coming in from Google, it appears that this PR was reverted by 377c36e.

@jaredpalmer, what was the reason for the revert?

@thexpand
Copy link

@jaredpalmer Any info on this?

@rbong
Copy link

rbong commented Nov 18, 2020

@earksiinni looks like the related MR references #1654 as the reason it was reverted

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

Successfully merging this pull request may close these issues.

None yet

8 participants