isFieldValid not working as expected if prevalidate is false

[Maverik]

Hi there,

First of all, thank you for taking on the maintenance role of the library after Ryan. I've just started using the library so if I'm doing something wrong, please point me in the right direction.

Otherwise I've created a codepen repo with the problem and this is essentially the same problem as #28 I believe.

When I try to validate a specific field with prevalidate set to false in order to trigger an API call, the callback is never triggered and the result of isFieldValid appears to lag behind by one call.

i.e. if the last 7 results were false:

• you'll get true on first call (this is coming from default state of control while its in pristine state)
• you'll get false up-to the 8th call (1+7)
• true on the 9th call (1+8 even though the field was valid on the 8th call).
• lets say now the input was actually invalid on the 9th call, it'll take the 10th call to actually get that result.

I hope you can see now what I mean by "lagging behind by one call".

The behaviour only happens with pre-validate set to false as far as I can tell and behaves as expected when working with the entire form. Of course, that leaves a pretty bad impression when the entire form says its required, even though the user hasn't even gotten to rest of the form yet.

[Keith Dahlby]

Calling isFieldValid() with prevalidate: false always checks the latest cached validation result, instead of validating again before returning. So what you're seeing is what I would expect.

I'm not sure if we have a way to trigger validations only for a specific field.

[Maverik]

Thank you for the clarification there. It would be worth documenting the behaviour in the readme then perhaps as you'll likely get new users asking this same question anyway.

My JS/TS foo is much weaker than my C# but in the event, there was some interest from my side in possibly doing a PR for adding the functionality to bypass cache for validation optionally, would that be something meaningful for the library to have?

[Keith Dahlby]

Honestly the behavior of validating the whole form when asking if a single field is valid feels like a bug to me. We don't currently have a way to run validators for a single field, but that's not hard to add.

That would be a breaking change, though. Method was introduced in #8. Thoughts, @haacked?

[Phil Haack]

I think we should probably add a method to validateFormField(element)

I wonder if it validates the whole form just in case there are dependencies. For example, if an element is only required if another field is valid or something like that. I’m AFK so I can’t look.

[Keith Dahlby]

@Maverik can you give this PR a try? #77

I think we should probably add a method to validateFormField(element)

I like this as a counterpart to validateForm. I called it validateField(), since we don't use FormField anywhere.

I wonder if it validates the whole form just in case there are dependencies. For example, if an element is only required if another field is valid or something like that.

Validators don't have access to the validation state of other inputs, so dependencies would be on values of other inputs.

[Maverik]

Thank you so much for the quick turn around on this @dahlbyk. I've updated the codepen to use the code from this PR commit 7fe1de0.

I can confirm that the new validateField works exactly as how I'd expect it to and solves my immediate use-case. I find the isFieldValid to be still confusing (although I understand its behaviour now and its working as intended). I'm only unsure if isFieldValid should be reflecting the callback changes as reflected in validateField.

I've also updated the primary input field under testing to test for two validations to ensure multiple validators get exercised as expected in many production scenarios

You may use my updated pen as a demo test if you like. You can leave the prevalidate off and just trigger changes in the "Required Field". I've updated the sample to reflect the new callback as well as the old callback. Should you push another commit during your test, you can easily call the new commit from pen by updating the git hash in import url.

I'm happy to update the pen once this PR is final if any changes are needed for future readers.

Again, thank you very much for the quick turn around. It's highly appreciated!

[Keith Dahlby]

I find the isFieldValid to be still confusing (although I understand its behaviour now and its working as intended). I'm only unsure if isFieldValid should be reflecting the callback changes as reflected in validateField.

Sorry, I'm not sure what you mean by this? Are you referring to a mismatch between the return value and the value passed to the callback?

[Maverik]

Indeed. From my testing, isFieldValid still doesn't perform the callback (which validateField does as expected) as I'd expect it to & the result is still coming back as the cached result from last call I think. Here's a screenshot of what I mean (I'm attaching the screenshot for both prevalidate cases):

PS: I noticed you updated to a new commit, I've updated pen to pull in latest commit from branch directly now so it's always reflecting your latest work at the point of testing this issue.

[Keith Dahlby]

A ha! I think you're hitting the debounce. If I comment out the validateField() then I see the isFieldValid callback result.

[Maverik]

Thank you for figuring that out. I guess this sorts my use-case out. I might have to come back later, when I circle back to that story I was working on but for now, I think this covers all the bases and I can configure the debounce if i need to.