I know that both Watchers and Observers are computed as soon as something in $scope changes in AngularJS. But couldn't understand what exactly is the difference between the two.
My initial understanding is that Observers are computed for angular expressions which are conditions on the HTML side where as Watchers executed when $scope.$watch() function is executed. Am I thinking properly?
$observe() is a method on the Attributes object, and as such, it can only be used to observe/watch the value change of a DOM attribute. It is only used/called inside directives. Use $observe when you need to observe/watch a DOM attribute that contains interpolation (i.e., {{}}'s).
E.g., attr1="Name: {{name}}", then in a directive: attrs.$observe('attr1', ...).
(If you try scope.$watch(attrs.attr1, ...) it won't work because of the {{}}s -- you'll get undefined.) Use $watch for everything else.
$watch() is more complicated. It can observe/watch an "expression", where the expression can be either a function or a string. If the expression is a string, it is $parse'd (i.e., evaluated as an Angular expression) into a function. (It is this function that is called every digest cycle.) The string expression can not contain {{}}'s. $watch is a method on the Scope object, so it can be used/called wherever you have access to a scope object, hence in
a controller -- any controller -- one created via ng-view, ng-controller, or a directive controller
a linking function in a directive, since this has access to a scope as well
Because strings are evaluated as Angular expressions, $watch is often used when you want to observe/watch a model/scope property. E.g., attr1="myModel.some_prop", then in a controller or link function: scope.$watch('myModel.some_prop', ...) or scope.$watch(attrs.attr1, ...) (or scope.$watch(attrs['attr1'], ...)).
(If you try attrs.$observe('attr1') you'll get the string myModel.some_prop, which is probably not what you want.)
As discussed in comments on #PrimosK's answer, all $observes and $watches are checked every digest cycle.
Directives with isolate scopes are more complicated. If the '#' syntax is used, you can $observe or $watch a DOM attribute that contains interpolation (i.e., {{}}'s). (The reason it works with $watch is because the '#' syntax does the interpolation for us, hence $watch sees a string without {{}}'s.) To make it easier to remember which to use when, I suggest using $observe for this case also.
To help test all of this, I wrote a Plunker that defines two directives. One (d1) does not create a new scope, the other (d2) creates an isolate scope. Each directive has the same six attributes. Each attribute is both $observe'd and $watch'ed.
<div d1 attr1="{{prop1}}-test" attr2="prop2" attr3="33" attr4="'a_string'"
attr5="a_string" attr6="{{1+aNumber}}"></div>
Look at the console log to see the differences between $observe and $watch in the linking function. Then click the link and see which $observes and $watches are triggered by the property changes made by the click handler.
Notice that when the link function runs, any attributes that contain {{}}'s are not evaluated yet (so if you try to examine the attributes, you'll get undefined). The only way to see the interpolated values is to use $observe (or $watch if using an isolate scope with '#'). Therefore, getting the values of these attributes is an asynchronous operation. (And this is why we need the $observe and $watch functions.)
Sometimes you don't need $observe or $watch. E.g., if your attribute contains a number or a boolean (not a string), just evaluate it once: attr1="22", then in, say, your linking function: var count = scope.$eval(attrs.attr1). If it is just a constant string – attr1="my string" – then just use attrs.attr1 in your directive (no need for $eval()).
See also Vojta's google group post about $watch expressions.
If I understand your question right you are asking what is difference if you register listener callback with $watch or if you do it with $observe.
Callback registerd with $watch is fired when $digest is executed.
Callback registered with $observe are called when value changes of attributes that contain interpolation (e.g. attr="{{notJetInterpolated}}").
Inside directive you can use both of them on very similar way:
attrs.$observe('attrYouWatch', function() {
// body
});
or
scope.$watch(attrs['attrYouWatch'], function() {
// body
});
I think this is pretty obvious :
$observe is used in linking function of directives.
$watch is used on scope to watch any changing in its values.
Keep in mind : both the function has two arguments,
$observe/$watch(value : string, callback : function);
value : is always a string reference to the watched element (the name of a scope's variable or the name of the directive's attribute to be watched)
callback : the function to be executed of the form function (oldValue, newValue)
I have made a plunker, so you can actually get a grasp on both their utilization. I have used the Chameleon analogy as to make it easier to picture.
Why is $observe different than $watch?
The watchExpression is evaluated and compared to the previous value each digest() cycle, if there's a change in the watchExpression value, the watch function is called.
$observe is specific to watching for interpolated values. If a directive's attribute value is interpolated, eg dir-attr="{{ scopeVar }}", the observe function will only be called when the interpolated value is set (and therefore when $digest has already determined updates need to be made). Basically there's already a watcher for the interpolation, and the $observe function piggybacks off that.
See $observe & $set in compile.js
Related
I'm making a dinamic list of dates. The user can adds all datepickers he wants, but I have to validate that there are not matching dates, all of them have to be different, that's the only requisite.
I've made a custom directive validation and it's triggered correctly, but when I try to use its isolate scope, I just get that error (Multiple directives). Other questions/solutions that I've seen here, propose to delete the isolate scope, but I need it to pass to the directive the array of dates and to be able to compare them with the current selected.
Here is a codepen that reproduces the problem. If you remove the noMatchingDates directive's scope, the error just disappears and you can see and add datepickers properly. I mean this scope:
scope: {
getAllDates: "&allDates"
}
I think that it has to do with this line in docs:
Multiple directives requesting isolated scope.
And it probably also has to do with the md-datepicker which would have more directives using the isolate scope. So, how can I solve this error (and still being able to send the dates list)?
If it can't be solved (keeping the scope) given the nature of the md-datepicker, how can I reach this dynamyc validation? I think it could be done using a controller and the ng-change, but I'm not sure if it would be a proper solution.
Indeed there is no reason for your directive to require an isolated scope. Use isolated scope when your directive is like a reusable "visual component". Your directive is about logic validation and shouldn't prevent another such component.
To fix your problem, you can remove the isolated scope and use your directive in the HTML this way:
<div ... no-matching-dates="overtimeList">
Then in your link function, you can retrieve the value of that attribute this way:
var dates = scope.$parse(attr.noMatchingDates);
This will give you the content of what is bound to no-matching-dates, so in this case it will return overtimeList.
I have never used the ctrl.$parsers.unshift syntax, but it seems that you can also use it to retrieve that value. Simply remove the scope.$parse line that I just gave you and write:
ctrl.$parsers.unshift(function(arrayOfDates) { ... })
This should work as well. Note that in the first approach you need to $watch for changes if you want to run the validation every time.
I just want to know how to use $digest. Inside a controller the following code works fine and it updates the DOM after 3 seconds:
setTimeout(function(){
$scope.$apply(function(){
$scope.name = 'Alice';
});
}, 3000);
However by using
setTimeout(function(){
$scope.$digest(function(){
$scope.name = 'Alice';
});
}, 3000);
nothing happens...
I thought that they do the same thing. Am I wrong?
$apply() and $digest() have some similarities and differences. They are similar in that they both check what's changed and update the UI and fire any watchers.
One difference between the two is how they are called. $digest() gets called without any arguments. $apply() takes a function that it will execute before doing any updates.
The other difference is what they affect. $digest() will update the current scope and any child scopes. $apply() will update every scope. So most of the time $digest() will be what you want and more efficient.
The final difference which explains why $apply() takes a function is how they handle exceptions in watchers. $apply() will pass the exceptions to $exceptionHandler (uses try-catch block internally), while $digest() will require you handle the exceptions yourself.
I think you must go through documents $apply
$apply() is used to execute an expression in angular from outside of
the angular framework
Usually, you don't call $digest() directly in controllers or in
directives. Instead, you should call $apply() (typically from within a
directive), which will force a $digest().
Also as suggest by Jorg, use $timeout
In angularjs $scope object is having different functions like $watch(), $digest() and $apply() and we will call these functions as central functions.
The angularjs central functions $watch(), $digest() and $apply are used to bind data to variables in view and observe changes happening in variables.
Generally in angularjs we use $scope object to bind data to variables and use that variables values wherever we required in application. In angularjs whatever the variables we assigned with $scope object will be added to watch list by using $scope.$watch() function.
In angularjs once variables added to watch list $scope.digest() function will iterates through the watch list variables and check if any changes made for that variables or not. In case if any changes found for that watch list variables immediately corresponding event listener function will call and update respective variable values with new value in view of application.
The $scope.$apply() function in angularjs is used whenever we want to integrate any other code with angularjs. Generally the $scope.$apply() function will execute custom code and then it will call $scope.$digest() function forcefully to check all watch list variables and update variable values in view if any changes found for watch list variables.
In most of the time angularjs will use $scope.watch() and $scope.digest() functions to check and update values based on the changes in variable values.
A better understanding of $watch, $apply, and $digest is provided in this article.
Simply,
$watch that is used to detect changes in the UI
$apply would tell the $digest loop what changes should be applied
$digest loop would run and will ask every $watch for changes, the DOMs would change accordingly for what has what has been applied
You should call $apply only.
I am trying to use the interpolation expression with the ng-model directive but it doesn't work. On the contrary, when I use interpolation with ng-src, it works perfectly fine. What is this difference due to?
It all depends upon how the directive has been setup.
Some directives like ng-model, ng-show and ng-click do not use interpolation symbols whereas directives ng-src take interpolation.
Interpolation are supported on directives that work only with strings. If we look at ng-src implementation you will find
attr.$observe(normalized, function(value) {
if (!value)
return;
attr.$set(attrName, value);
if (msie) element.prop(attrName, attr[attrName]);
});
attr.$observe watches for change in attribute not model. Model changes cause attribute changes (due to interpolation), hence causing the trigger to fire.
For all other directives like ng-model, the attribute value is an expression which is evaluated in current scope and is not limited to string value.
If you are developing your own directives, isolated scope properties = and # help you achieve something similar.
It's to do with when the code in the directive looks at the attribute: before or after interpolation.
I suspect ngModel uses the attribute, and by that I mean passing it to $parse or $eval, as it is before interpolation.
However, the directive ngSrc uses the attribute, and by that I mean setting the src attribute or not to the attribute value, after interpolation.
The reason as to why ngModel uses the value before interpolation, but ngSrc uses it after, I suspect is to do with how they're coded up. Consider the directive
<my-directive my-attr="{{ 'name' }}"></my-directive>
coded up as:
app.directive('myDirective', function() {
return {
restrict: 'E',
link: function($scope, $element, $attrs) {
console.log('Link:', $attrs.myAttr); // Outputs "name"
},
controller: function($scope, $element, $attrs) {
console.log('Controller:', $attrs.myAttr); // Outputs "{{ 'name' }}"
}
};
});
The un-interpolated value is seen in the controller, but the post-interpolated value is seen in the linking function. So the order of the (relevant) events is
controller,
then interpolation,
then linking function.
You can see this example in a Plunker. I suspect ngModel uses the value from the controller, and therefore sees the pre-interpolated value, but ngSrc uses the linking function, and so sees the post-interpolated value.
One reason as to why ngModel uses the controller rather than the linking function, I suspect is so that it can expose the controller to other directives, which can use it via their require option.
A slightly confounding complication is that ngSrc doesn't expect the attribute to be a valid Angular expression. Rather than passing it through $parse or $eval, it just uses the post-interpolated value of the attribute directly. (i.e. it doesn't need the URL to be wrapped in quotes).
If you wanted to, you could write a directive that combines interpolation with Angular expressions. From the linking function you can pass the attribute to $parse or $eval. If the post-interpolated value is a valid Angular expression, this would work. You could do the same thing from the controller, but you would have to pass the value through $interpolate first.
As you have discovered, ngModel does't support this. However, I don't see why you couldn't write some basic version of ngModel that supports both, and so could be used as
my-model="myScope{{ 'VariableName' }}"
that accesses the scope variable myScopeVariableName.
To bring it back tot the question again, why ngModel itself doesn't support this, I suspect is because use cases are limited (the OP didn't mention one in the question), and so would add complexity to the directive without good reason.
It has to do with one way vs two way data binding provided by directives isolated scope. Check out "Isolated Scope Explained" section in the follwoing post:
http://www.undefinednull.com/2014/02/11/mastering-the-scope-of-a-directive-in-angularjs/
I'm reading Build Your Own AngularJS and have a decent understanding of how $scopes, $watch and $digest work. I understand how it works when you add your own $watches and and call your own $digests. However, I'm confused about what exactly is happening by default.
What gets added to $scope.$$watchers by default? Everything you put on $scope? Everything you assign an ng-model to? Both? Something else?
And when exactly do $digests get triggered by default? Input field changes? Input fields with ng-models? Other?
Some of the common directives that use $watch / $watchCollection / $watchGroup internally:
ng-model
ng-bind / {{ }}
ng-show & ng-hide
ng-class
ng-repeat
ng-if
ng-switch
ng-include
Note that the only one that sets up a two-way binding is ng-model (scope -> view & view -> scope).
The others set up a one-way binding (scope -> view).
Simply exposing something on for example a controller´s $scope will not add a watcher.
For example, the following will not result in a watcher being added:
angular.module('myApp', []).controller('Controller', function MyCtrl($scope) {
$scope.value = 1;
});
Together with:
<body ng-app="myApp" ng-controller="Controller">
</body>
But if you replace the HTML with the following one watcher will be added:
<body ng-app="myApp" ng-controller="Controller">
<div>{{value}}</div>
</body>
Some common scenarios when the digest cycle is triggered:
When ng-click is evaluated
When ng-model changes (for example when typing in an input)
By the $http service
In $timeout and $interval
Note that there is one big difference between $apply and $digest:
Calling scope.$digest() will execute the watchers only on that scope and its children.
Calling scope.$apply() will trigger $digest on the $rootScope, which means all the scopes will be traversed and all watchers executed.
$apply also accepts an expression as an argument. This expression will be evaluated inside a try-catch statement and any exception will be passed on to the $exceptionHandler service.
$digest does not accept any arguments.
Usually you only call $digest instead of $apply when you are chasing micro optimizations and really know what you are doing.
It's my understanding that any two-way bindings get a $watch in their scope, however, if it is added by angular internals, you don't get that hook, because, for example, ngModelController has the callback, so you can't use that callback, I think what is on scope does not get a watch unless it is bound to the view.
$digest is not used on model binding from what I found in the source code - but I found plenty of uses of $apply. In fact I found very few uses of $digest in the angular code at all. I didn't look in every file, but I did find it used in the expression parser here. Which I find interesting, but to answer your question, $digest in not called often, and $apply is called on only a few occasions with model binding, most notably on $commitViewValue() in the ngModelController. It also calls apply when an input is "touched"(ng-touched). I also found that $evalAsync calls $digest as well.
What I found for certain on apply/digest:
//apply method in rootScope
$apply: function(expr) {
try {
beginPhase('$apply');
return this.$eval(expr);
} catch (e) {
$exceptionHandler(e);
} finally {
clearPhase();
try {
$rootScope.$digest();
} catch (e) {
$exceptionHandler(e);
throw e;
}
}
}
As you can see, apply is really just a safe wrap around $digest, so one might argue to use $apply over digest. According to the source $digest does some crazy while-loop $scope traversal.
TLDR;
The notes from the angular team on digest:
Processes all of the {#link ng.$rootScope.Scope#$watch watchers} of
the current scope and
its children. Because a {#link ng.$rootScope.Scope#$watch watcher}'s listener can change
the model, the $digest() keeps calling the {#link ng.$rootScope.Scope#$watch watchers}
until no more listeners are firing. This means that it is possible to get into an infinite
loop. This function will throw 'Maximum iteration limit exceeded.' if the number of
iterations exceeds 10.
Usually, you don't call $digest() directly in
{#link ng.directive:ngController controllers} or in
{#link ng.$compileProvider#directive directives}.
Instead, you should call {#link ng.$rootScope.Scope#$apply $apply()} (typically from within
a {#link ng.$compileProvider#directive directive}), which will force a $digest().
If you want to be notified whenever $digest() is called,
you can register a watchExpression function with
{#link ng.$rootScope.Scope#$watch $watch()} with no listener.
I have a controller that has an object on its scope: $scope.objToTrack.
I have a directive that is inside a nested view that $watches for changes to that object.
It has isolate scope, but objToTrack is set as = so that it can be watched.
When I click the directive, it calls an expression that is a method on the controller which changes objToTrack.
Here's a plunker to illustrate my setup.
The problem is that objToTrack $watch callback isn't fired, although the object is changed.
If you switch between Test1 and Test2 states, changes made to objToTrack are visible. It's just that I don't understand why it doesn't work right away on click.
Thanks.
To answer question...if you bind your own event handlers to an element, and change angular scope within that event handler you need to call $apply so angular is made aware of the change and can run a digest
Example You have:
element.on('click',function(){
scope.onClick({number:RNG.int(200,300)});
});
Would need to be changed to:
element.on('click',function(){
scope.$apply(function(){
scope.onClick({number:RNG.int(200,300)});
});
});
It is a lot simpler if you use event directives already provided by angular. In this case you are writing considerable amount of extra code vs using ng-click. It also makes testing a lot easier when you stay within angular as much as possible
Also, if you want to pass an object into your directive you should not use curly braces.
In html, use obj-to-track="objToTrack", instead of obj-to-track="{{objToTrack}}".
Like this:
<div simple-directive obj-to-track="objToTrack" class="directive"></div>
And in directive.js: use '=' for bi-directional binding of the objToTrack.
Like this:
scope:{
objToTrack:'='
}
In your "test*.html" files, replace "on-click" by "ng-click".
"on-click" doesn't look in your current controller, "ng-click" does.