First time submitting an issue on Github. Please let me know if I'm doing it wrong!
I've noticed that
validateOnBlur now defaults to false
& validateOnChange now defaults to true
but documentation states the opposite for both of them.
https://github.com/jaredpalmer/formik/blob/master/src/formik.tsx
Hi Lee. Congratulations on your first issue! I haven’t looked at the code
yet but if you’re right, how do you feel about making your first PR? Happy
to guide you along the way
Adam
On Wed, 20 Sep 2017 at 07:24 Lee Shue Ze notifications@github.com wrote:
First time submitting an issue on Github. Please let me know if I'm doing
it wrong!I've noticed that
validateOnBlur now defaults to false
& validateOnChange now defaults to truebut documentation states the opposite for both of them.
https://github.com/jaredpalmer/formik/blob/master/src/formik.tsx
http://url—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jaredpalmer/formik/issues/162, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFj6zl9z4Th4gFAPFlL5rjCrJgPuZ9Tks5skKFxgaJpZM4PdW7z
.
This is the thing I mentioned twice in PR.
I'm not sure, why it's now false onBlur by default, I actually thought it was a typо in code, not in the docs. According to the changelog, it's a breaking change. Maybe @jaredpalmer could explain, why it was changed.
@VladShcherbin @skattyadz
@eonwhite and I discussed this at length. Formik was messed up before. Thus we decided to fix that... https://github.com/jaredpalmer/formik/issues/114#issuecomment-323134473
@jaredpalmer in my projects I set validateOnChange and validateOnBlur validation to true so I can understand the validateOnChange changes.
But why is validateOnBlur turned off by default now? If you use for example tab button or just click a field and have it as a required one - there won't be an error because no validation will be triggered since the value is not changed. Don't you have such cases?
@VladShcherbin you raise a good point about tabbing through.
@eonwhite thoughts?
@VladShcherbin @dorkblue @skattyadz
ICYMI, Twitter also doesn't know wtf to do...
@jaredpalmer for a common use case, I'd expect it to validate onBlur and also validate onChange after onBlur validation already triggered.
So:
Okay, I think the move is to change validateOnChange and validateOnBlur to true by default. You can use touched and errors in tandem then to display the errors and the correct time.
I think you are right @VladShcherbin that we should be validating onBlur by default. I think we screwed this one up by disabling it -- we were debating between "should we validate on change or blur" when the right answer is actually "both".
For onChange, I think it's more consistent behavior to always validate, rather than to conditionally validate based on touched. You can control whether or not you want the error message to appear on initial input by checking against touched (that's pretty much what the touched field is intended for), and that still leaves you the flexibility to show the error on initial input if you want.
So I think the proper defaults are validateOnChange: true, validateOnBlur: true.
@jaredpalmer @eonwhite
Yeah, it's a common pattern to display errors with something like this one:
{touched && error && (
<p>{error}</p>
)}
@skattyadz hey adam! sorry for the late reply. I was at the Google Cloud Summit Singapore. (and also time differences)
I would love it if you could guide me on how to do a proper PR so that I can contribute back.
But this issue is closed and solved tho.
Most helpful comment
Hi Lee. Congratulations on your first issue! I haven’t looked at the code
yet but if you’re right, how do you feel about making your first PR? Happy
to guide you along the way
Adam
On Wed, 20 Sep 2017 at 07:24 Lee Shue Ze notifications@github.com wrote: