Why do we need to reconcile the two different types returned by .validate() ?

[lafsar]

Versions:

• VueJs: 2.1.10
• Vee-Validate:2.0.0.23-beta

Description:

I have a custom validation rule that returns a resolved promise. However, when I combine this custom validation with a native validation rule (like required) - In some cases, $validator.validate() returns a Boolean, but other times it returns a Promise.

This results in console errors because you cannot call .then() on a Boolean, which means I have to do a typecheck on $validator.validate() everytime I need to access the errors in the .then() callback.

Returning two different types from one function call seems like a bad design pattern.

Steps To Reproduce:

Create a custom validation rule that returns a Promise.
Extend the validator to use the custom rule.
use validator.attach() to bind the custom rule, along with the native "required" rule.

Attempt to call .then() on $validator.validate('customRule');

[logaretm]

The behavior was changed in beta23 to early exit with the result whenever a validation fails, which improves performance and avoids redundant ajax calls. I'm considering making validate() to always return a promise so that the API is consistent, and to avoid the issue you've just mentioned.

[jasonlewis]

I know this is closed but can jump in on this @logaretm and ask about consistency.

Currently validateAll will resolve or reject the promise depending on whether or not the validation passed/failed.

The validate method always resolves the promise and simply passes in a boolean result. Wouldn't it make more sense for validate to reject the promise is this case?

I don't know the insides of this package so not sure if you're limited in some way but it just feels odd having to check the result in the validate promise when I don't have to worry about it in validateAll.

[logaretm]

@jasonlewis Actually I fixed this in a recent commit, Like you said, you want it to throw if you are calling it from outside the validator inner workings, but you don't want it to throw in validateAll since the typical behavior is to collect all errors for all fields, not stop on first.

be9e548