-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Optimizing validation for FastFields #1007
Comments
Big +, because i have same problems, validating causing much performance issues in big forms |
Why don't you set |
@mschipperheyn no, because we dont want to turn of validation, we still wanna validate a given fast field, but not the whole yup schema on each key stroke |
Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal. |
|
+1. I had to do validateOnBlur and validateOnChange={false} to overcome this problem; however, validating only on blur negatively impacts the user experience because the user is required to click off or go to a different field. If there's an issue at that point, the user then needs to come back to the previous field and this is annoying to users. I would prefer for each field to only validate itself as @klis87 suggests so that (1) using Formik/Yup on large forms is performant, and (2) to provide the most real-time validation possible to users. |
🚀 Feature request
Current Behavior
Currently
FastField
does rendering optimization, but still itsonChange
handler triggers validation for the wholevalidationSchema
, which can be costly for really huge forms.Desired Behavior
It would be perfect if
onChange
andonBlur
ofFastField
could validate only slice ofvalidationSchema
Suggested Solution
yup.reach
is the answer - https://github.com/jquense/yup#yupreachschema-schema-path-string-value-object-context-object-schema Fast fields could call a new Formik method, which validates only schema corresponding to a givenFastField
. For instance,<FastField name="someName.nested" />
could doschema.reach('someName.nested')
and use this for validation instead of validating the whole schema. Then, the validation result could be merger with Formik errors.Who does this impact? Who is this for?
All users caring for the best possible form performance, who use Formik together with Yup, especially for big forms.
Describe alternatives you've considered
I have really big dynamic forms, sometimes +100 fields and I tried
FastField
- it is better now but for such a big form it is Yup which becomes a bottleneck - each key stroke validates 100+ fields, which could be especially costly for more expensive validators.Alternatively I could use Field level validation, but I really like to keep validation logic only in yup, it is easy to test then and also it nicely keep good separation between yup and formik. Also, I dont like to repeat myself defining
initialValue
andschema.cast()
does this automatically form me (provided I have all fields defined inside schema, not as field validators)Additional context
N/A
The text was updated successfully, but these errors were encountered: