isFieldValid not working as expected if prevalidate is false about aspnet-client-validation HOT 10 CLOSED

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.

from aspnet-client-validation.

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.

from aspnet-client-validation.

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?

from aspnet-client-validation.

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?

from aspnet-client-validation.

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.

from aspnet-client-validation.

@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.

from aspnet-client-validation.

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!

from aspnet-client-validation.

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?

from aspnet-client-validation.

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.

from aspnet-client-validation.

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

from aspnet-client-validation.