This question already has answers here:
What does :: mean in angularJS
(3 answers)
Closed 6 years ago.
Today I was looking at some angular code and was surprised to see this operator. Not sure what this operator does? Could somebody provide more information on the special operator :: ? I have neither encountered this operator before nor seen it in AngularJS docs.
project-id="{{::vm.projectId}}"
Using that syntax will save on resources by not spawning a watcher for the variable.
When you put a variable in a template using the double-curly syntax ({{...}}) Angular will generally spawn a watcher for that variable. This means that whenever changes are made to that variable in your Angular code the front-end will reflect that change.
Sometimes this over-eager watcher syntax isn't what you want, though. For instance, you may have a variable that you know will not change, or a variable that will change, but you don't want that change reflected immediately. This is why you will sometimes see the {{::my-var}} syntax, as it doesn't spawn a watcher.
Related
I'm editing an existing code that has a lot of angular js expressions which are being detected as unsafe by our automated testing system. I was able to see the article below that describes my case, but I was not able to get any specific way to solve it (I'm mostly seeing $watch and $apply). I guess what I need to know here is where do I make changes on the code?
Related links:
http://blog.angularjs.org/2016/09/angular-16-expression-sandbox-removal.html
https://docs.angularjs.org/guide/security#angularjs-templates-and-expressions
Sample snippets on my code:
Your code looks perfectly fine. I think what you're missing is the "passing user provided content" portion of that warning.
In the first example the only thing you are passing to $apply is a function that YOU have defined, same as the second example. In the last example you don't pass anything to $apply.
The reason they have these warnings is because $apply can be passed a string to evaluate an expression on $scope.
In the same way that
{{$scope.hello = 'Hello, World'}}
will set the hello property of $scope
$scope.$apply('hello = "Hello, World"')
Will do exactly the same. now imagine you pass user defined content to this
$scope.$apply(userPassedString)
Now you have given a user the ability to run arbitrary javascript expressions in your apply function.
To see exactly what I mean by this (and how this is exploitable), I have created a codepen demo for you here: https://codepen.io/codymikol/pen/bGbzbvp
(You'll have to scroll down in the HTML to see the script, I was lazy and din't link it as a separate JS file \_('__')_/
Also if you REALLY want to understand how the above snippet is able to function (and where I learned about getting the function constructor in such a way) you should watch this video by liveoverflow: https://www.youtube.com/watch?v=DkL3jaI1cj0
This was made back when the AngularJS team was trying to create a sandbox around scope expressions to prevent XSS. There are a bunch of videos detailing different exploits people used to get around the sandbox. Because of how complicated creating a sandbox is and how often it was being exploited they decided to remove it entirely and just warn developers about passing user content in such a way.
I am going to improve the perfomance of my angular app. So I decided to use {{::variable}} more often (>angular 1.3). For translations I used the writting {{'key.header'|translate}}.
Is a performance improvement possible if i use {{:'key.header'|translate}} or does angular know that these strings won't change?
Thank you
The only way to indicate to angular that your string would not change is using {{::variable}}. And yes, it's a performance improvement because you are telling to angular to evaluate that expression once and then ignore it (avoiding two-way binding) and never watch it again. So,
less watchers = better performance
NOTE:
You can set an angular expression using ::, only if your expression wouldn't be changed over the time. In your case(about your comment), if you want to use that expression to get a translated version on a string, you should not use it then, because the user may changes the language any time and it needs got changed.
Conclusion
You should use :: over angular expressions that wouldn't be changed over the time. :: is a way to declare a constant and reduce your watchers, getting a better performance.
From this question and this answer, it seems that using expressions will cause the value to be evaluated from scratch every time. But I've searched the documentation and tutorials, and I haven't found a reference for this statement.
In my mind, both are wrapped in a $watch() and so when the $digest() cycle runs it will see whether the value inside ng-bind or {{}} has changed.
On performance, why is ng-bind better than {{}} as has been suggested, and where's the reference?
Details like this aren't always available in the documentation - you have to read the source. I took a peek and it seems that (as of 2014-11-24) they both work in a very similar way. Both cause a single directive to be instantiated to change the value when needed (the curly interpolation directive is generated on the fly).
Both directives evaluate the expressions involved on every $digest just like everything else. The main difference is that while ng-bind doesn't do any further processing on the value, with curlies, the entire interpolated text is recalculated on every digest. Essentially a string is built using $interpolate and that is compared with the previous value (this happens within the bowels of $digest). Neither way will update the DOM if the value (either the plain value with ng-bind or the interpolated result with curlies) hasn't changed.
To me the accepted answer on that question is a more compelling reason to use ng-bind, i.e. you can use it to prevent a visible flash of the template tags before Angular loads and compiles them, without resorting to hacks like ng-cloak.
Depending on variables there may also be cases where curly interpolation is actually more performant. One situation I can think of is when using ng-bind instead of interpolation requires you to create a lot of otherwise redundant <span> elements, and that tips the scales in the other direction. An interpolation expression also causes a single watcher to be created for the entire string independent of how many variables you use, as opposed to ng-bind which creates one watcher for each instance.
But as always, don't optimize for performance early, and if you do, profile to find out which part really matters.
The major difference between ng-bind and {{}} is that ng-bind creates a watcher for variable passed to it(i.e. name as in above example), while curly brackets({{}}) will (store the entire expression in memory i.e. }perform dirty-checking and refreshing the expression in every digest cycle even if it is not required.
ng-bind will only apply when the value passed is changing actually.
for more details refer below link:
http://www.ufthelp.com/2015/11/difference-between-and-ng-bind-in.html
OK this question appears many times across many context on the web. However, I am yet to find a sufficient answer. It seems like there is no way of displaying globals in the Debug/Variables view. A workaround this is to use the Expressions view. This is fine for watching the variables, but it won't let you change their contents, as in the Variables view.
Now, one could do so via the Memory view. This is OK when dealing with simple variables, but gets complicated when dealing with compound objects (e.g., structures).
So, how can you easily watch and change the values of globals and static variables in Eclipse CDT?
It seems that changing value of global variables is possible in the Expressions view. From some reason this did not work earlier, which is why I asked this question.
Obviously, it can only work when the expression is an lvalue.
(I am not deleting this question just in case it will be helpful to someone in the future, but if the mods think it should be deleted, that's fine with me)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How does WCF deserialization instantiate objects without calling a constructor?
If I use a DataContract attribute it doesn't call my constructor, but if I skip it then it will. Why does this happen?
The purpose of serializing/deserializing is to recreate the object in its original state. The object has already been constructed so we don't need to call the constructor. It is like raising an object from the dead rather than giving birth. :)
If you need some code to happen when an object is deserialized just decorate a method with the OnDeserialized attribute and call the code you need to execute from there.