After re-reading the Angular $watch docs a few more times, I think I understand what's happening.
The listener is called only when the value from the current watchExpression and the previous call to watchExpression are not equal
Angular tracks the value of the watchExpression foo > 4
with each digest()
loop. Because this evaluated to false until foo
was greater than 4, the listener didn't fire. Likewise, after foo
was greater than 4, the values Angular was comparing were both true. The only time it detected a change was when the evaluated expression crossed over.
Two values are passed to the $watch
listener function, the new value and the old one. Logging these values shows that the watchExpression is being evaluated, and Angular is looking for a change in those values.
$scope.$watch('foo > 4', function(newVal, oldVal) {
console.log("foo is greater than 4: ", $scope.foo, oldVal, newVal);
});
// foo is greater than 4: 5 true false
The reason the listener was called on page load is also documented:
After a watcher is registered with the scope, the listener
fn is called asynchronously (via $evalAsync
) to initialize the watcher. In rare cases, this is undesirable because the listener is called when the result of watchExpression
didn't change. To detect this scenario within the listener
fn, you can compare the newVal
and oldVal
. If these two values are identical (===
) then the listener was called due to initialization.
I updated the plunkr with a second $watch
that evaluates the value of foo
internally:
$scope.$watch('foo', function(newVal, oldVal) {
if ($scope.foo > 4) {
console.log("foo is greater than 4: ", $scope.foo, newVal, oldVal);
}
});
// foo is greater than 4: 5 5 4
// foo is greater than 4: 6 6 5
// foo is greater than 4: 7 7 6
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…