I ran across this in a book called ng-book by Ari Lerner.
"The compile option by itself is not explicitly used very often; however, the link function is used
very often."
Also, I refer this page but still this confuse me (Difference between the 'controller', 'link' and 'compile' functions when defining a directive)
Can someone justify this a little bit further?
Keep in mind that compile is used to return the linking function that allows the template to be bound to the scope. The cases where you need to interject yourself into this process are mainly limited to the need to actually manipulate the template prior to that binding. One example would be to modify the template based on the attributes set by the user. In short most developers forget about compile unless they need to modify the template. 'Most' are more concerned with the instance of their directive and what to do with the scope bound to that instance (domain of the linking function).
I am using 'Most' very loosely as I have absolutely no data regarding this.
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.
Traditionally I have managed my Angular code like this
//File 1
angular.module('name',[])
//File 2
function TestController(){
}
TestController.prototype.// inherited stuff
angular.module('name').controller('testController',TestController);
This worked great and allowed me to partition my files easily. Now I try to upgrade to 1.3 and get the infamous...
Error: [ng:areq] Argument 'TestController' is not a function, got undefined
Of course this is due to this change which claims a desire to clean up the way people write code. What about this pattern is more complex? Is there a way to maintain this pattern without changing the global settings?
There is actually a comment on the page you linked to that had a fairly solid explanation.
Global controllers refer to your controllers being defined as function
on the window object. This means that they are openly available to
conflict with any other bit of JavaScript that happens to define a
function with the same name. Admittedly, if you post-fix your
controllers with ...Controller then this could well not happen but
there is always the chance, especially if you were to use a number of
3rd party libraries. It is much safer to put these controller
functions inside the safety of a module. You then have more control
over when and where this module gets loaded. Unfortunately controller
names are global across an individual Angular app and so you still
have the potential for conflict but at least you can't clash with
completely different code in the JavaScript global namespace.
So the idea is that global controller functions could conflict with any other global function in any javascript you use. So to eliminate the chance of a conflict with your own code or a third-party script, not using global controllers makes your code safer and more consistent.
As mentioned in the comments by #Brett, you can use IIFE around your prototyping. Here is an update of your plunk that uses that. The main change just looks like this.
(function() {
TestController.prototype.name = 'World'
})();
What comes to my mind is 2 things:
1) in that way functions wont be kept in memory more than they should.
2) if you minify your code, minifyer will have to generate new names for all global objects, which is sfine when you have small project, but will be a problem when it's not.
Also it should prevent tests to modify unnecessary data.
I'm creating a directive around a third party library, to go in a form, where the option chosen in a select drop-down will bring up a different set of form elements.
In the parent element of each subset of form elements I'm trying to use an expression similar to this: ng-if="myScopeObj.val === ThirdParty.CONSTANT_VAL". I came to realize it's not working because the "ThirdParty" library isn't on the scope.
Should I just assign the library to a variable on the scope, or is there some pattern that can address this? It seems like creating isThis() or isThat() functions for every constant in the library wouldn't be a great solution.
Should I create a service to wrap the third party library and then inject it into the directive? Though I'd still need to put the injected service on the scope. Would that be overkill for a library that doesn't access remote APIs? I don't think it'd need to be mocked for testing, anyway.
You're correct that you do need to get the value on the $scope somehow in order for it to be usable. And you're correct that one of the primary benefits of wrapping in a service is that you can mock the library. Another benefit of wrapping in a service is self-documentation. As someone else (or yourself at a later time) looking at your code, I could be confused as to where ThirdParty is coming from. Working in Angular, the assumption is that all dependencies are injected, and breaking convention comes at a cognitive cost. Having a service also can make it easier to swap out the underlying library later for a different implementation. Anyway, your simplest fix is:
$scope.ThirdParty = ThirdParty;
I am in the process of taking over a pretty large angular project from another developer. One thing I noticed was there are a lot of undeclared properties being assigned in the html markup and not declared in the controller.
I am fully aware Angular takes care of creating these properties anyway. But its best practices to declare everything in the controller so other developers won't have to hunt them down.
Is there anyway to get a list of non-explicitly declared properties on a controller? So I can clean it up a bit?
Thank you!
The most reliable method is probably output $scope to the console:
console.log($scope);
You'll see the AngularJS bits ($$somethingSomething), but you're sure to see all the undeclared bits as well. The alternative is to take a text based approach by searching for ng-* tags, but would probably be worse.
I'm part of a team with about 6 UI devs, of varying quality and next to no Angular experience. Many are contractors, with little experience with the code base. The app has a very fancy (complicated) UI. It supports IE8+ (soon hopefully IE9+).
We're introducing Angular for a major extension to the app, and I've been asked to write guidelines on the use of Angular for the team.
We'll use directives to create fancy UI elements, all prefixed with "ipwr" to avoid name clashes. I'm trying to decide whether to mandate that devs give their directives the restriction "element" or "attribute". Mandating only one, to avoid chaos and confusion.
My question is: what restrict is better or more popular for directives, "element" or "attribute"?
My main concern is ease of use for people with little Angular experience who are new to the application code base, to reduce bugs, copy and paste behaviour, etc.
The angular guidance says that you should use the "element" restriction whenever the directive has full control over it's template meaning it has a template that it is rendering out, etc.
For attributes, they suggest to use these only when you are adding "behavior" to an existing element or decorating an existing element.
For example, think of the ng-click directive, this is used a attribute not as a element because the click directive is just adding the click behavior to some element.
Another example would be the ng-repeat directive, it is also used as an attribute not as a element because it is going to repeat the element in which it is being used in.
Now, this guidance is from the angular documentation; however, I don't know necessarily that element vs. attribute is going to give you a "better" approach it's more of a convention.
Now if you have to support older browsers, then you may want to consider using either the comment or class directives.
My personal preference is to just use the attribute restriction; mainly because people that are new to angular get overwhelmed at first when they see the restrict and it's variations of the options that can be used.
I usually defer to the John Papa AngularJS style guide when making these types of decisions. He says:
Lean towards implementing as an element when its standalone and as an
attribute when it enhances its existing DOM element.
If you want to keep your HTML valid you'd use attributes, e.g. if you have a directive ipwr-modal, you can declare it as <div data-ipwr-modal="you-could-put-some-binding-here"></div>.
When creating directives with a custom layout, however, you'd better use element declaration (if you don't need to have your HTML valid). This is the more obvious way to say: "hey, we have a custom component here".
This blog post explains it with some more ideas
Some points to consider:
Most of the time attributes is the best/most convenient option (it's not the default by chance).
Anything you can do with element-bound directives, you can do with attribute-bound as well.
Element-bound directives can be more descriptive/readable at times.
If you want your code to pass certain types of validation, you should use attributes.
Since you want to support IE8, keep in mind that custom tags have an extra overhead (more info), which hurts maintainability.
BTW, you can't limit directives to elements only (without affecting functionality), so it is more a question of allowing 'element' or not. Note that an element often has more than one directives and directives placed on the same element can cooperate and augment each other's behaviour. So limiting the use of directives to 'element', means limiting the number of custom directives per element to 1, which severly reduces the functionality-potential.
That said, this is what I ('d) do:
If IE8 is not an issue, allow both (mostly use attributes).
If IE8 (or the overhead for custom tags) is an issue, use only attributes.
In general, if only one form should be allowed, it should be attributes (works anywhere, no extra overhead, offers all functionality).