From the AngularJS directive documentation:
Best Practice: use controller when you want to expose an API to other
directives. Otherwise use link.
Is this really the only case to use controllers inside directives?
what about some init functionality such as defaulting variable and scope values? should it generally go into link, unless publicly exposed?
I only use "link" when I have to implement some deeper DOM manipulation. Any "regular" component should use controllers. Basically the idea is to use "link" only when you don't have any other option as it's more involved and requires a deeper understanding of how Angular SJ works.
Related
Can i traverse the DOM in angular like jquery ? In jquery there are multiple functions like parent(),siblings(), find(), children() etc... like this, Is there any functions in angularjs?
Is there any 'this' keyword in angular DOM traverse like jquery where in jquery this means the current element ?
Any reference links will be more helpful.
Angular comes with a cut down bundled version of jQuery, called jQuery lite:
Docs
In the main, full blown Jquery and Angular can live together, however it is recommended not to use them at the same time - there is generally a much better angular way of achieving what you need to do. For instance testing your logic will be easier.
"This" in your example would refer to something off the current controller and on that controller's scope. It is recommended that you use angular to control and manipulate that element in angular.
From what I've gathered, link deals with dom manipulation while controller deals with directive specific logic. So does it make sense to have both link and controller with a directive? Since compile returns link, what about compile and controller used together?
For the number of directive that i have seen here is something that seems to be common
You implement controller if you want to expose an API for your directive. This API is used to control the directive. When directives take dependencies on other directives using require, what gets injected is a controller instance.
When dealing with forms we see FormController and NgModelController which are good examples of directive controllers.
For most of the other cases link function used.
For small cases if we need to do DOM manipulation compile can be used
We are looking at implementing an Angular Wizard. Though routes are the best way to do it, we would like the wizard to be presented in such a way that it is usable as a directive.
For eg, someone must be able to use the wizard like (with sufficient options) and all the ui-router logic in between should work.
Is it possible in Angular to wrap the ui-router logic into a directive? Can we declare directives whose dependency is the ui-router (or something like the routeProvider) and start routing inside a directive?
There are two ways (AFAIK) to associate a controller with a view template/partial: the route specified in $routeProvider and the ngController directive. Especially (but not exclusively) for simple routing, is there any benefit/efficiency of one over the other?
My project currently uses the $routeProvider approach, but I've been given the task of nesting views. This seems simple enough with ngInclude, as long as the partial specifies its ngController.
This question really comes down to design and as such it is a bit opinion based. That in mind, the best guidance I know is:
$routeProvider - Allows you to specify a single controller for a template. Since this is part of the routing it makes it easy to find the controller that goes with the page. I use this to store and load overall page logic rather than element specific logic.
This is also important because it means you can load the exact same template for two different routes but the behavior and data could be different because the controller can be changed. This is not something that is easy to do with the ngController option.
ngController - This scopes the controller to a specific element on the page/template. That can make the code easier to read when you need multiple controllers on a single page and it allows the controller to be more specifically scoped.
So it really comes down to scope and intent. Hopefully these rules will help when deciding which to use.
If you think of a view including all scripts as a self-contained package, developed by a single person or team, then ngController is the way to go, imho.
$routeProvider on the other hand provides you with advanced features like injection of values via the resolve property of the route. That way you can have your AJAX loaded data directly injected into your controller, e.g., instead of the controller having it to get itself. Or have the route change to wait for that data etc.
Btw: If you need routing and nested views you can take a look at angular ui-router
I wanted to know, If we want to manipulate the DOM. Where we should do that.
Is it in a Controller or a directive or somewhere else ?
I have read somewhere that manipulating the DOM in controller should be avoided. Is it correct?
You should use Angular JS Directive for DOM manipulations. DOM Manipulations should not exist in Controllers, Services or anywhere else but in Directives.
One of the nicer features of AngularJS is the framework's ability to separate the roles of the model, the view, and the controller. The separation is clean enough that you shouldn't need to manipulate the DOM directly from code inside the controller. Instead, the controller only manipulates the model, which influences the view through data bindings and directives. The end result is a clean and testable.
Take a look at this
Video - This video tutorial covers manipulating the DOM in AngularJS using directives with a link function.
Best practice is:
Dom manipulations only in directives.
Read here