(bug): 3rd party promises on $asyncValidators inconsistently applies ng-invalid class or stuck with ng-pending

[pocesar]

It seems that using Bluebird makes the ng-invalid / ng-pending classes to be intermittent, even if the model is valid.

Notice the flicker on the first input http://plnkr.co/edit/y5OEDwK45P1OAplCigQi?p=preview typing at a fast speed. sometimes it works, sometimes it flickers.

The second input is using $q, and it's flawless, remains invalid, since it's always immediately resolving.

If you watch with developers tools, you can see the class is added / removed intermittently. When using $q, it doesn't happen.

Is it a problem with bluebird or with the promise resolution in Angular? (or I need to throw a $scope.$applyAsync in the bunch).

the effect becomes pronounced when using sibling validator CSS rules with icons, they blink like mad.

I'm also getting random "stuck on pending" with 3rd lib promise, where it never sets the class to "ng-valid" but keeps the "ng-pending". the problem is even more pronounced when there's more than one then chain

[petebacondarwin]

AngularJS 1.x doesn't support using a 3rd party promise library. See #6697

I think the problem you have is that $q promises are tightly bound with Angular's digest triggering mechanism, which Bluebird knows nothing about.

[Narretz]

Closing because we do not support 3rd party promise libs.

[pocesar]

@Narretz @petebacondarwin the docs says otherwise https://docs.angularjs.org/api/ng/service/$q#when

[petebacondarwin]

Actually, this is working as expected. The async validators are not guaranteed to run synchronously, even if they are resolved immediately. So while we are waiting for the validation result to be resolved, the value of the error is set to undefined, which indicates "pending", rather than null, which indicates no error.

It just happens that in the case of $q, if the value is resolved immediately, the async validator processing completes within a single $apply cycle and so there is no digest between the validation value being set to undefined and then set to the error.

You can see this more clearly, even in the case of a $q promise, if you delay resolution a bit using a timeout: http://plnkr.co/edit/mVhbR1XO5FQxN1rKcL4g?p=preview