Here we have $scope.user, which is bound to the first input, and we have $scope.pass, which is bound to the second one. Doing this we add two $watch to the $watch list.

index.html 

1234

app.controller(‘MainCtrl‘, function($scope) {  $scope.foo = "Foo";  $scope.world = "World";});

 controllers.js

1

Hello, {{ World }}

Here, even though we have two things attached to the $scope, only one is bound. So in this case we only created one $watch.

controllers.js

123

app.controller(‘MainCtrl‘, function($scope) {  $scope.people = [...];});

index.html

12345

<ul>  <li ng-repeat="person in people">      {{person.name}} - {{person.age}}  </li></ul>

How many $watch are created here? Two for each person (for name and age) in people plus one for the ng-repeat. If we have 10 people in the list it will be (2 * 10) + 1, AKA 21 $watch.

So, everything that is bound in our UI using directives creates a $watch.(数据模型和视图绑定在一起才会产生一个$watch) Right, but when are those $watch created?

When our template is loaded, AKA in the linking phase, the compiler will look for every directive and creates all the $watch that are needed. This sounds good, but… now what?

$digest-----------------$digest loop

Remember the extended event-loop I talked about? When the browser receives an event that can be managed by the angular context the $digest loop will be fired.

This loop is made from two smaller loops. One processes the $evalAsync queue and the other one processes the $watch list, which is the subject of this article.

What is that process about? The $digest will loop through the list of $watch that we have, asking this:

• Hey $watch, what is your value?
  • It is 9
• Alright, has it changed?
  • No, sir.
• (nothing happens with this one, so it moves to the next)
• You, what is your value?
  • It is Foo.
• Has it changed?
  • Yes, it was Bar.
• (good, we have a DOM to be updated)
• This continues until every $watch has been checked.

This is the dirty-checking. Now that all the $watch have been checked there is something else to ask: Is there any $watch that has been updated? If there is at least one of them that has changed, the loop will fire again until all of the $watch report no changes. This is to ensure that every model is clean. Have in mind that if the loop runs more than 10 times, it will throw an exception to prevent infinite loops.

When the $digest loop finishes, the DOM makes the changes.

Example:

controllers.js

1234567

app.controller(‘MainCtrl‘, function() {  $scope.name = "Foo";  $scope.changeFoo = function() {      $scope.name = "Bar";  }});

index.html

12

{{ name }}<button ng-click="changeFoo()">Change the name</button>

Here we have only one $watch because ng-click doesn’t create any watches (the function is not going to change(函数本身不会变) :P).

• We press the button.
• The browser receives an event which will enter the angular context (I will explain why, later in this article).
• The $digest loop will run and will ask every $watch for changes.
• Since the $watch which was watching for changes in $scope.name reports a change, if will force another $digest loop.
• The new loop reports nothing.
• The browser gets the control back and it will update the DOM reflecting the new value of $scope.name

The important thing here (which is seen as a pain-point by many people) is that EVERY event that enters the angular context will run a $digest loop. That means that every time we write a letter in an input, the loop will run checking every $watch in this page.

 $apply-----------------Entering the angular context with $apply

angularJS之$apply()方法

$apply() 做的一件事，就是调用根作用域 $rootScope 的$digest() 

$apply() is used to execute an expression in angular from outside of the angular framework(Angular框架外的Js代码). (For example from browser DOM events, setTimeout, XHR or third party libraries). Because we are calling into the angular framework we need to perform proper scope life cycle of exception handling, executing watches.

What says which events enter the angular context and which ones do not? $apply

If you call $apply when an event is fired, it will go through the angular-context, but if you don’t call it, it will run outside it. It is as easy as that. So you may now ask… That last example does work and I haven’t called $apply, why? Angular will do it for you. So if you click on an element with ng-click, the event will be wrapped inside an $apply call. If you have an input with ng-model="foo" and you write an f, the event will be called like this: $apply("foo = ‘f‘;"), in other words, wrapped in an $apply call.

When angular doesn’t use $apply for us

This is the common pain-point for newcomers to Angular. Why is my jQuery not updating my bindings? Because jQuery doesn’t call $apply and then the events never enter the angular context and then the $digest loop is never fired.

Let’s see an interesting example:

Imagine we have the following directive and controller:

app.js

1234567891011121314151617181920212223

app.directive(‘clickable‘, function() {return {  restrict: "E",  scope: {    foo: ‘=‘,    bar: ‘=‘  },  template: ‘<ul style="<li>{{foo}}</li><li>{{bar}}</li></ul>‘,  link: function(scope, element, attrs) {    element.bind(‘click‘, function() {      scope.foo++;      scope.bar++;    });  }}});app.controller(‘MainCtrl‘, function($scope) {  $scope.foo = 0;  $scope.bar = 0;});

It binds foo and bar from the controller to show them in a list, then every time we click on the element, both foo and bar values are incremented by one.

What will happen if we click on the element? Are we going to see the updates? The answer is no. No, because the click event is a common event that is not wrapped into an $apply call. So that means that we are going to lose our count? No.

What is happening is that the $scope is indeed changing but since that is not forcing a $digest loop, the $watch for foo and the one for bar are not running, so they are not aware of the changes. This also means that if we do something else that does run an $apply, then all the $watch we have will see that they have changed and then update the DOM as needed.

没有进入Angular Context，因此，count会累加，但是在页面上没有反映出来，毕竟还是JS，对变量的操作还是会生效

So if you want to use a jQuery plugin, be sure you call $apply if you need to run a $digest loopto update your DOM.

Something I want to add is that some people “feel bad” having to call $apply because they think that they are doing something wrong. That is not true. It is just Angular that is not a magician and it doesn’t know when a 3rd party library wants to update the bindings(第三方的库对数据模型的草错，Angular.js不会知道).

$watch -----------------------Using $watch for our own stuff

$watch

You already know that every binding we set has its own $watch to update the DOM when is needed, but what if we want our own watches for our purposes? Easy.

Let’s see some examples:

Example 1

app.js

123456789

app.controller(‘MainCtrl‘, function($scope) {  $scope.name = "Angular";  $scope.updated = -1;  $scope.$watch(‘name‘, function() {    $scope.updated++;  });});

index.html

1234

<body ng-controller="MainCtrl">  <input ng-model="name" />  Name updated: {{updated}} times.</body>

That is how we create a new $watch. The first parameter can be a string or a function. In this case it is just a string with the name of what we want to $watch, in this case, $scope.name (notice how we just need to use name). The second parameter is what is going to happen when $watch says that our watched expression has changed. The first thing we have to know is that when the controller is executed and finds the $watch, it will immediately fire.

Example 2:

app.js

12345678910

app.controller(‘MainCtrl‘, function($scope) {  $scope.name = "Angular";  $scope.updated = 0;  $scope.$watch(‘name‘, function(newValue, oldValue) {    if (newValue === oldValue) { return; } // AKA first run    $scope.updated++;  });});

index.html

1234

<body ng-controller="MainCtrl">  <input ng-model="name" />  Name updated: {{updated}} times.</body>

The second parameter of $watch receives two parameters. The new value and the old value. We can use them to skip the first run that every $watch does. Normally you don’t need to skip the first run, but in the rare cases where you need it (like this one), this trick comes in handy.

Example 3:

app.js

12345678910

app.controller(‘MainCtrl‘, function($scope) {  $scope.user = { name: "Fox" };  $scope.updated = 0;  $scope.$watch(‘user‘, function(newValue, oldValue) {    if (newValue === oldValue) { return; }    $scope.updated++;  });});

index.html

1234

<body ng-controller="MainCtrl">  <input ng-model="user.name" />  Name updated: {{updated}} times.</body>

We want to $watch any changes in our $scope.user object. Same as before but using an object instead of a primitive.

Uhm? It doesn’t work. Why? Because the $watch by default compares the reference of the objects(按引用). In example 1 and 2, every time we modify $scope.name it will create a new primitive, so the $watch will fire because the reference of the object is new and that is our change. In this new case, since we are watching $scope.user and then we are changing $scope.user.name, the reference of $scope.user is never changing because we are creating a new $scope.user.name every time we change the input, but the $scope.user will be always the same.

That is obviously not the desired case in this example.

Example 4:

app.js

12345678910

app.controller(‘MainCtrl‘, function($scope) {  $scope.user = { name: "Fox" };  $scope.updated = 0;  $scope.$watch(‘user‘, function(newValue, oldValue) {    if (newValue === oldValue) { return; }    $scope.updated++;  }, true);});

index.html

1234

<body ng-controller="MainCtrl">  <input ng-model="user.name" />  Name updated: {{updated}} times.</body>

Now it is working! How? We added a third parameter to the $watch which is a bool to indicate that we want to compare the value of the objects instead of the reference. And since the value of $scope.user is changing when we update the $scope.user.name the $watch will fire appropriately.

There are more tips & tricks with $watch but these are the basics.

Understanding Angular’s $apply() and $digest()

Understanding Angular’s $apply() and $digest()

$apply and $digest Explored

AngularJS offers an incredibly awesome feature known as two way data binding which greatly simplifies our lives. Data binding means that when you change something in the view, the scope model automagically updates. Similarly, whenever the scope model changes, the view updates itself with the new value. How does does AngularJS do that? When you write an expression ({{aModel}}), behind the scenes Angular sets up a watcher on the scope model, which in turn updates the view whenever the model changes. This watcher is just like any watcher you set up in AngularJS:

$scope.$watch(‘aModel‘, function(newValue, oldValue) {  //update the DOM with newValue});

The second argument passed to $watch() is known as a listener function, and is called whenever the value of aModelchanges. It is easy for us to grasp that when the value of aModel changes this listener is called, updating the expression in HTML. But, there is still one big question! How does Angular figure out when to call this listener function? In other words, how does AngularJS know when aModel changes so it can call the corresponding listener? Does it run a function periodically to check whether the value of the scope model has changed? Well, this is where the $digest cycle steps in.

It’s the $digest cycle where the watchers are fired. When a watcher is fired, AngularJS evaluates the scope model, and if it has changed then the corresponding listener function is called. So, our next question is when and how this $digestcycle starts.

The $digest cycle starts as a result of a call to $scope.$digest(). Assume that you change a scope model in a handler function through the ng-click directive. In that case AngularJS automatically triggers a $digest cycle by calling$digest(). When the $digest cycle starts, it fires each of the watchers. These watchers check if the current value of thescope model is different from last calculated value. If yes, then the corresponding listener function executes. As a result if you have any expressions in the view they will be updated. In addition to ng-click, there are several other built-in directives/services that let you change models (e.g. ng-model, $timeout, etc) and automatically trigger a $digest cycle.

So far, so good! But, there is a small gotcha. In the above cases, Angular doesn’t directly call $digest(). Instead, it calls $scope.$apply(), which in turn calls $rootScope.$digest(). As a result of this, a digest cycle starts at the $rootScope, and subsequently visits all the child scopes calling the watchers along the way.

Now, let’s assume you attach an ng-click directive to a button and pass a function name to it. When the button is clicked, AngularJS wraps the function call within $scope.$apply(). So, your function executes as usual, change models (if any), and a $digest cycle starts to ensure your changes are reflected in the view.

Note: $scope.$apply() automatically calls $rootScope.$digest().(自动触发) The $apply() function comes in two flavors(两种形式). The first one takes a function as an argument, evaluates it, and triggers a $digest cycle. The second version does not take any arguments and just starts a $digest cycle when called. We will see why the former one is the preferred approach shortly.