$asyncValidators run multiple times per element on load (given ng-repeat || ng-(min/max)length))

[changhaitravis]

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

If you have a model defined already and it's put into an input text element with a custom validator defined and this input field is in an ng-repeat, then, on the page load, the $ayncValidator will be run once, and then run in quick succession run again for every validator directive such as "minlength, maxlength, ng-maxlength, ng-minlength, required".

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).

1. define a model in the controller
2. define a custom directive that has an $asyncValidator linked (put in a console.log before returning the promise)
3. create a div with ng-repeat (if this step is omitted, then the problem is only exhibited with ng-maxlength and ng-minlength)
4. Inside of the ng-repeat clause create an input type="text" element, and load it up with maxlength, minlength, and required
5. take note of how many times the console.log() that was set up in $asyncValidator is tripped when you hit "Run".
6. when you go and interact with the element, then it behaves normally and as expected.

http://jsfiddle.net/yofk7u0L/5/

What is the expected behavior?

$asyncValidators only fire once upon directive initialization with a non-empty model, regardless of how many other attribute directives that are validators exist in the element, also regardless of whether they're in ng-repeat or not.

What is the motivation / use case for changing the behavior?

In the application I'm currently working on, a user can have up to 10 of these $asyncValidator input fields loaded up at the same time. With minlength, maxlength, and required enabled on each, this makes 30 EXTRA requests to my API, on top of the 10 that were welcome. If I use ng-minlength and ng-maxlength, it could bump it up an extra twenty (two per input element)

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.

Firefox and Chrome on Angular 1.5.3, 1.5.5, 1.5.6 and v1.5.7-build.4838+sha.cfc8b41 exhibit this behavior.
I'm seeing this happen on both Windows 7 (1.5.3 & 1.5.5) and Linux Fedora 23 KDE (All the above)

Other information (e.g. stacktraces, related issues, suggestions how to fix)
Not sure how to fix this, but I guess:

• Order directives are placed have no bearing
• Synchronous $validators within the same directive as the $asyncValidators behave normally.
• The entire list of $asyncValidators seems to be looped through each time
• I have not tried adding custom directives to the input element, but I suspect that they might behave similarly and contribute to the amount of times
• If you use a combination of ng-repeat and ng-minlength and ng-maxlength that seems to maximize the total number of requests.
• Have not tested to see if other input types are affected

[pocesar]

that's expected, I'm pretty sure. that's how the digest cycle works. it needs to make sure that the value hasn't changed and is 'stable'. you could make your async validator check for a presence of a viewValue on the model, so it would return only when it's present, and reject the validation right away if it doesn't

[changhaitravis]

That would have been an acceptable workaround, but in this scenario, viewValue is already present when the asyncValidator fires its (extra) requests. The only workaround I suspect works is to package $asyncValidator in the same directive along with all of the other directive's functionality (minlength, maxlength, required) that I want to use.

[Narretz]

I wouldn't quite say it's expected behavior, since it works as expected without ngRepeat. There are two issues that play together:

• required, maxlength, minlength call $validate whenever their obsever (for attribute changes) fires. This happens also initially after the element is compiled and a $digest happens. Without ngRepeat, the model hasn't been initialized yet, so no validators actually run
• ngRepeat terminates the compilation and appens the elements with the $transclude function during the first $digest. This causes a difference to the no-repeat scenario: With ngRepeat, the $digest happens before the elements are linked, and the ngModel is initalized. Without ngRepeat, the $digest happens after the elements have been linked and and the observers fire when the ngModel isn't intialized yet.

This is honestly pretty weird, because I would expect ngModel to be validated once after the first $digest without ngRepeat, and it's never validated. With ngRepeat, it's validated once and 1 time per validation directive. Both cases are wrong, imo, but I suspect the first case doesn't appear too often, since on load usually more than one digest happens.

[krutkowski86]

+1

[NaomiN]

I am running into exactly the same problem. In fact, I only want all my validators to only fire when I changed the value and not right away. Is there a way for this? Say, I tried adding ngModel.$touched check in the directive, but then I could not fire it at all. What is the best workaround to only fire validations when the value is changed?

I am using AngularJs 1.6.4 and seeing this behavior in Google Chrome

[hdi-amiri]

I am having the same issue any update on this issue? or any workaround? I am using angular 1.5.11 and I have my async validator with ng-required and two custom validator of my own.

Regards

[NaomiN]

Hi,

I think I was able to prevent running it too many times on load but I'm not 100% certain as I then found that it was not running all the times when I needed, so I made few extra changes lately. I plan to write a TechNet article that explains my solution in all the details, I'll post the link once I do that.

[krutkowski86]

@NaomiN +1
I'm looking forward to hearing from you.