I see where you are coming from. You have an established set of patterns
which work well for you. However, in many ways angular makes a lot of these
patterns potentially unecessary, and by adopting new patterns more aligned
with the angular way of doing things, you can greatly reduce the complexity
and amount of code, while still retaining (and in many cases improving)
modularity, re-usability, testability, and separation of concerns.
I think one of the confusions here is the way that so-called angular
“templates” work. Angular templates are not a string-based templating
system like many other stystem. Angular templates always start as a tree of
real browser DOM nodes before any directives are actually applied.
I might be wrong, but I get a feeling you might not be fully understanding
what directives really are. Angular directives are not language constructs,
they are simply snippets of javascript that run as angular encounters them
when it walks down the DOM tree. These snippets run in the context of the
current scope and the element that they were encountered in. This
javascript is then responsible for doing whatever it needs to do, often
decorating the dom or removing/adding new elements or cloning dom and
repeating it.
If you are familiar with jquery, let me show you what the equivalent of a
directive would be in jquery. Say we have this html:
<p weight="900" > This is my text</p>
Weight is not a real property in html, but we’d like it to mean what the
CSS font-weight should be for this paragraph (I know this would be better
done with a class+css but this is just a simple example).
The jQuery would be like this:
$('[weight]').each(function(index, element) {
console.log(index, element);
$(element).css('font-weight', $(element).attr('weight'));
});
The equivalent angular directive would be:
app.directive('weight', function(){
return{
restrict: 'A',
link: function(scope, element, attrs){
element.css('font-weight', attrs.weight);
}
}
});
As you can see, a directive is just a different syntax for binding
javascript behavior to a dom element. They are very much like writing
jquery selectors that then applying some javascript code to the results.
The directive only support a limited number of ways to match (rather than
the full selector engine). So for example these following are different
directive types along with equivalent jQuery:
Attribute directives:
$('[some-attribute]').each(......do stuff....)
app.directive('someAttribute', function(scope, element, attrs){
return {
restrict: 'A',
link: function(){
...do stuff..
}
};
});
Element directives:
$('some-element').each(......do stuff....)
app.directive('someElement', function( scope, element, attrs){
return {
restrict: 'E',
link: function(){
...do stuff..
}
};
});
Class directives:
$('.some-class').each(......do stuff....)
app.directive('someClass', function(){
return {
restrict: 'C',
link: function(scope, element, attrs){
...do stuff..
}
};
});
To go back to your originally question, I hope it is now clear that the
only difference between element directives or attribute directives, or
class directives, is how angular matches the dom element in question. Once
it has matched the element, the link function will be called with the
matching element. In fact, it is common practice when using element
directives to have them match both on elements and on attributes:
Element OR Attrtibute directives:
$(['person-selector', '[person-selector]']).each(......do stuff......)
app.directive('someClass', function(){
return {
restrict: 'EA',
link: function(scope, element, attrs){
...do stuff..
}
};
});
This way people have the choice of how to actually use the directive if
they aren’t comfortable with having non-html nodes on their page.
Hopefully this helps clarify that directives really are just a way to
associate a bit of javascript with a dom node.
Of course angular does provide some sugar on top of directives to make some
common actions easier. For example directives can have templates. Say I
have a <hello/> directive that simply replaces itself with a paragraph <p>HELLO
WORLD!</p>:
app.directive('hello', function(){
return {
restrict: 'E',
template: '<p>HELLO WORLD!</p>',
replace: true
};
});
Underneath the hood though, this is really still just matching any
<hello>elements, and executing javascript that replaces it with new dom. You
could
even write this with the lower-level construct:
app.directive('hello', function(){
return {
restrict: 'E',
link: function(scope, element, attrs){
element.replaceWith('<p>HELLO WORLD</p>');
}
};
});
Hopefuly this sheds some light and ‘demistifies’ directives. I apologize if
I’m telling you things you may already know but it may be helpful to others
since there seems to be some confusion out there about what directives
really are.
I’m sure I still haven’t done enough to convince you of the benefits of
doing things “the angular way”. And to be honest, it is difficult to do
without taking an existing real-world example, implementing the “angular
way” and then exploring any benefits/drawbacks in the different approaches.
If you’d like to provide some more complete and preferably working examples
in a plunkr, I would be happy to show what I would consider the “angular
way” of implementing the same functionality and then discuss any
thoughts/concerns you might have.
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to angular+unsubscr...@googlegroups.com.
To post to this group, send email to angular@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.
