Dirty Checking (脏值检查)
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(并不是所有添加到$scope上面的东西都会被watch). 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).
$watch helps to listen for $scope changes
There are two ways of declaring a $scope
variable as being watched(两种方法去告诉Angular某变量是否被标记需要被检测).
- By using it in your template via the expression
<span>{{myVar}}</span>
- 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 $scope
s 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
.
controllers.js
1 |
|
index.html
1 |
|
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 |
|
index.html
1 |
|
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(在link阶段,compiler会注册register) 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
- It is
- 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
.
- It is
- Has it changed?
- Yes, it was
Bar
.
- Yes, it was
- (good, we have a DOM to be updated)
- This continues until every
$watch
has been checked(继续下一步,直到所有watch都被检查过).
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(直到所有的$watch表示已经没有变化,停止脏值检查). 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(脏值检查循环结束之后,dom就会变化), the DOM makes the changes.
Example:
controllers.js
1 |
|
index.html
1 |
|
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
$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(对于内置的指令,angular会为你调用$apply). 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 |
|
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 loop
to 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 |
|
index.html
1 |
|
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 |
|
index.html
1 |
|
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 |
|
index.html
1 |
|
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 |
|
index.html
1 |
|
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 aModel
changes. 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 $digest
cycle 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.