Angular DirtyChecking(脏值检查) $watch, $apply, $digest

Dirty Checking (脏值检查)

Digest cycle and $scope

Digest cycle and $scope

First and foremost, AngularJS defines a concept of a so-called digest cycle. This cycle can be considered as a loop, during which AngularJS checks if there are any changes to all the variables watched(被检测的变量) by all the $scopes. So if you have $scope.myVar defined in your controller and this variable was marked for being watched(被表明此变量需要被检测), then you are implicitly(隐式的表明需要被检测) telling AngularJS to monitor the changes on myVar in each iteration of the loop.

A natural follow-up question would be: Is everything attached to $scope being watched? Fortunately, no. If you would watch for changes to every object in your $scope, then quickly a digest loop would take ages to evaluate and you would quickly run into performance issues.

That is why the AngularJS team gave us two ways of declaring some $scope variable as being watched (read below).(两种方法去告诉Angular某变量是否被标记需要被检测)

$watch helps to listen for $scope changes

There are two ways of declaring a $scope variable as being watched.

1. By using it in your template via the expression <span>{{myVar}}</span>
2. By adding it manually via the $watch service(手动的通过$watch服务)

Ad 1) This is the most common scenario and I‘m sure you‘ve seen it before, but you didn‘t know that this has created a watch in the background(在watch list 中添加了一个watch). Yes, it had! Using AngularJS directives (such as ng-repeat) can also create implicit watches.

Ad 2) This is how you create your own watches. $watch service helps you to run some code when some value attached to the $scope has changed. It is rarely used, but sometimes is helpful. For instance, if you want to run some code each time ‘myVar‘ changes, you could do the following:

function MyController($scope) {

    $scope.myVar = 1;

    $scope.$watch(‘myVar‘, function() {
        alert(‘hey, myVar has changed!‘);
    });

    $scope.buttonClicked = function() {
        $scope.myVar = 2; // This will trigger $watch expression to kick in
    };
}

$apply enables to integrate changes with the digest cycle

You can think of the $apply function as of an integration mechanism. You see, each time you change some watched variable attached to the $scope object directly, AngularJS will know that the change has happened. This is because AngularJS already knew to monitor those changes. So if it happens in code managed by the framework, the digest cycle will carry on.

However, sometimes you want to change some value outside of the AngularJS world and see the changes propagate normally. Consider this - you have a $scope.myVar value which will be modified within a jQuery‘s $.ajax() handler. This will happen at some point in future. AngularJS can‘t wait for this to happen, since it hasn‘t been instructed to wait on jQuery.

To tackle this, $apply has been introduced. It lets you to start the digestion cycle explicitly(显式地). However, you should only use this to migrate some data to AngularJS (integration with other frameworks(和其他的框架中的数据进行整合)), but never use this method combined with regular AngularJS code, as AngularJS will throw an error then.

How is all of this related to the DOM?

Well, you should really follow the tutorial again, now that you know all this. The digest cycle will make sure that the UI and the JavaScript code stays synchronised(视图和数据模型保持同步), by evaluating every watcher attached to the all $scopes as long as nothing changes. If no more changes happen in the digest loop, then it‘s considered to be finished.

You can attach objects to the $scope object either explicitly in the Controller, or by declaring them in {{expression}} form directly in the view.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

$watch How the $apply Runs a $digest

$watch How the $apply Runs a $digest  理解$watch ，$apply 和 $digest --- 理解数据绑定过程(译文)

The browser events-loop and the Angular.js extension

Our browser is waiting for events, for example the user interactions. If you click on a button or write into an input, the event’s callback will run inside Javascript and there you can do any DOM manipulation, so when the callback is done, the browser will make the appropiate changes in the DOM.

Angular extends this events-loop creating something called angular context(Angular上下文？？) (remember this, it is an important concept). To explain what this context is and how it works we will need to explain more concepts.

The $watch list

Every time you bind something in the UI you insert a $watch in a $watch list. Imagine the $watch as something that is able to detect changes in the model it is watching (bear with me, this will be clear soon). Imagine you have this:

index.html

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

1
2
3
4

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

1
2
3

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

index.html

1
2
3
4
5

<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

1
2
3
4
5
6
7

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

  $scope.changeFoo = function() {
      $scope.name = "Bar";
  }
});

index.html

1
2

{{ 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

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

1
2
3
4
5
6
7
8
9

app.controller(‘MainCtrl‘, function($scope) {
  $scope.name = "Angular";

  $scope.updated = -1;

  $scope.$watch(‘name‘, function() {
    $scope.updated++;
  });
});

index.html

1
2
3
4

<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

1
2
3
4
5
6
7
8
9
10

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

1
2
3
4

<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

1
2
3
4
5
6
7
8
9
10

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

1
2
3
4

<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

1
2
3
4
5
6
7
8
9
10

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

1
2
3
4

<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() are two core, and sometimes confusing, aspects of AngularJS. To understand how AngularJS works one needs to fully understand how $apply() and $digest() work. This article aims to explain what $apply()and $digest() really are, and how they can be useful in your day-to-day AngularJS programming.

$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.