<title>Vee-validate V4 - lazy validation not working - rule is being called on each keystroke

[davidkjackson54]

What happened?

I have a rule that I want to execute only after the user has entered all the information into the text field and tabbed away. I execute an async call in that rule.
I cannot get this to work as the rule is being called on each key stroke.
My Field definition looks like this:

div>
        <Field name="PackageModel" type="text" as="vscode-text-field" v-model = packageCreateParms.PackageModel 
              :rules="asyncCall" :title=constants.copyForwardText> Package Model
        </Field>
        <ErrorMessage name="PackageModel" class="error"></ErrorMessage> 
</div>

I have tried inserting
:validateOnBlur="true" :validateOnChange="true" :validateOnInput="false" :validateOnModelUpdate="false" into the Field definition and various combinations of those 4 parameters but it doesn't make any difference as the rule continues to be called on each keystroke.
Would appreciate any advice as to why I am doing wrong here.

Reproduction steps

See above code fragment

Version

Vue.js 3.x and vee-validate 4.x

What browsers are you seeing the problem on?

• Firefox
• Chrome
• Safari
• Microsoft Edge

Relevant log output

None

Demo link

None

Code of Conduct

• I agree to follow this project's Code of Conduct

[logaretm]

This was reported a lot of times and is intended.

Validation being lazy means the errors are generated lazily, but the validation still occurs. This is because the meta.valid flag must be correct, there is no way around it in terms of whate vee-validate can do. Either we make the valid flag incorrect till a validation is executed or we run rules implicitly like we do now.

This behavior existed in v2, v3 where the valid flag could've a value of null to indicate that it never ran any validations yet, but people confused it with false and rightfully so, it is a falsy value. And it caused a lot of issues to be reported. So it's either I satisfy this camp or that camp. No in between.

This means there is no solution for it, but there might be workarounds you can employ:

• Caching the input value within the validator so if the user types it again for the same input, it won't execute the expensive request.
• Empty values usually are falsy for this kind of validation, right? you can skip running it all together if the value is empty within the validator logic.
• You can debounce the network requests ensure only one validation is run every 300 ms or so, you can further chain the validation results promises to return the value of the last validation run. Many techniques exist for async debouncing.

Unfortunately its all user-land, any changes here means a breaking change and that's reserved for v5.

[davidkjackson54]

Ok thanks. At least I know now that it is working without any means to stop it from within vee-validate itself and me driving myself mad trying to see what was wrong. My problem is that if the user types in ABCD123456 , my rules routine is going to get called with A and I would issue the rest call passing A , then the user adds the B and I do it all again and pass AB So I will have to try to come up with a hack. Thanks David

…

On Sun, Apr 28, 2024 at 11:18 AM Abdelrahman Awad ***@***.***> wrote: This was reported a lot of times and is intended. Validation being lazy means the errors are generated lazily, but the validation still occurs. This is because the meta.valid flag must be correct, there is no way around it in terms of whate vee-validate can do. Either we make the valid flag incorrect till a validation is executed or we run rules implicitly like we do now. This behavior existed in v2, v3 where the valid flag could've a value of null to indicate that it never ran any validations yet, but people confused it with false and rightfully so, it is a falsy value. And it caused a lot of issues to be reported. So it's either I satisfy this camp or that camp. No in between. This means there is no solution for it, but there might be workarounds you can employ: - Caching the input value within the validator so if the user types it again for the same input, it won't execute the expensive request. - Empty values usually are falsy for this kind of validation, right? you can skip running it all together if the value is empty within the validator logic. - You can debounce the network requests ensure only one validation is run every 300 ms or so, you can further chain the validation results promises to return the value of the last validation run. Many techniques exist for async debouncing. Unfortunately its all user-land, any changes here means a breaking change and that's reserved for v5. — Reply to this email directly, view it on GitHub <#4737 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALAIHNEH2QBCKE2GFGMIY5DY7U4OBAVCNFSM6AAAAABG4EOC22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU4DKMZRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[davidkjackson54]

Just a thought- it might be worth emphasizing in the doc that “lazy” validation does not explicitly stop the rule from being called but simply suppresses the error from being displayed. I know you say it has been reported before but maybe it needs to be specifically called out and made more clear. Anything that can be done in the future release to address this such that the rule is only called on the field losing focus would be greatly beneficial.. Thanks David

…

On Sun, Apr 28, 2024 at 11:18 AM Abdelrahman Awad ***@***.***> wrote: This was reported a lot of times and is intended. Validation being lazy means the errors are generated lazily, but the validation still occurs. This is because the meta.valid flag must be correct, there is no way around it in terms of whate vee-validate can do. Either we make the valid flag incorrect till a validation is executed or we run rules implicitly like we do now. This behavior existed in v2, v3 where the valid flag could've a value of null to indicate that it never ran any validations yet, but people confused it with false and rightfully so, it is a falsy value. And it caused a lot of issues to be reported. So it's either I satisfy this camp or that camp. No in between. This means there is no solution for it, but there might be workarounds you can employ: - Caching the input value within the validator so if the user types it again for the same input, it won't execute the expensive request. - Empty values usually are falsy for this kind of validation, right? you can skip running it all together if the value is empty within the validator logic. - You can debounce the network requests ensure only one validation is run every 300 ms or so, you can further chain the validation results promises to return the value of the last validation run. Many techniques exist for async debouncing. Unfortunately its all user-land, any changes here means a breaking change and that's reserved for v5. — Reply to this email directly, view it on GitHub <#4737 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALAIHNEH2QBCKE2GFGMIY5DY7U4OBAVCNFSM6AAAAABG4EOC22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU4DKMZRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[davidkjackson54]

Hi, I think I have a workaround to help me limit the possibility of making a REST api call when it isn't required. I hope to try that out tomorrow. I now have a TypeScript problem in trying to make use of your sample minMax defineRule example; Global Validators (logaretm.com) <https://vee-validate.logaretm.com/v4/guide/global-validators> In your code you specify this: defineRule('minMax', (value, [min, max]) => { and that is perfectly fine for JS I am trying to make this work for TS and not having much success: I have tried this but the min and max values are not being passed. defineRule("minMax", (value: string, { min, max }: { min: number; max: number }): boolean | string => { Oddly, I cannot find a single example on the web of how to specify defineRule in TS. Can you possibly see what is wrong with that line? If I put {...] around min, max it errors Thanks David

…

On Sun, Apr 28, 2024 at 11:18 AM Abdelrahman Awad ***@***.***> wrote: This was reported a lot of times and is intended. Validation being lazy means the errors are generated lazily, but the validation still occurs. This is because the meta.valid flag must be correct, there is no way around it in terms of whate vee-validate can do. Either we make the valid flag incorrect till a validation is executed or we run rules implicitly like we do now. This behavior existed in v2, v3 where the valid flag could've a value of null to indicate that it never ran any validations yet, but people confused it with false and rightfully so, it is a falsy value. And it caused a lot of issues to be reported. So it's either I satisfy this camp or that camp. No in between. This means there is no solution for it, but there might be workarounds you can employ: - Caching the input value within the validator so if the user types it again for the same input, it won't execute the expensive request. - Empty values usually are falsy for this kind of validation, right? you can skip running it all together if the value is empty within the validator logic. - You can debounce the network requests ensure only one validation is run every 300 ms or so, you can further chain the validation results promises to return the value of the last validation run. Many techniques exist for async debouncing. Unfortunately its all user-land, any changes here means a breaking change and that's reserved for v5. — Reply to this email directly, view it on GitHub <#4737 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALAIHNEH2QBCKE2GFGMIY5DY7U4OBAVCNFSM6AAAAABG4EOC22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU4DKMZRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>