Should the best practice be to prefix Component and Directive selectors, but not properties of components.
See original GitHub issueProblem
Assume the following HTML snippet
<button title="OK" tooltip="When done." (click)="..." *if="...">text</button>
- It looks like we are using browser
button
- It looks like
title
andtooltip
are properties ofbutton
.
Surprise
Now imagine that the actual implementation is:
@Component({ selector:'button', properties: ['title'] })
@View(...)
class Button {
title: string;
}
@Directives({selector:'[tooltip]', properties: ['tooltip']})
class Tooltip {
tooltip: string;
}
But after seeing the implementation the developer realizes that:
button
is not a native componenttooltip
is a separate, unrelated directive which decorates thebutton
This creates a level of surprise for the developer and effects the readability of the HTML.
Proposal
As a best practice (not enforced) recommend that:
- All components are prefixed (but not their properties)
- All directives are prefixed
Implication
Now let’s rewrite the example with the above rules.
<md-button title="OK" jq-tooltip="When done." (click)="..." *ng-if="...">text</button>
It is immediately clear that:
md-button
is a custom component andtitle
is its propertyjq-tooltip
is a separate directive. Given that they have different prefixes (md-
andjq-
) it is unlikely that they have a communication channel.ng-if
comes from yet separate library. (again unlikely that they somehow communicate)
But why prefix the ng-if
? Well remember that it is short hand for:
<template ng-if="...">
<md-button title="OK" jq-tooltip="When done." (click)="...">text</button>
</template>
And if we don’t prefix it it would look like that template
has if
property, which is not the case.
Issue Analytics
- State:
- Created 8 years ago
- Comments:33 (18 by maintainers)
Top Results From Across the Web
Angular directives | decorator | Attributes | Structural - Medium
The directive selector is prefixed by the app prefix defined in the ... You should know that Angular does not recommend this option....
Read more >The selector of the directive "TrimInputDirective" should have ...
Now I can't do this as my selector isn't a defined attribute I would add to a HTML element. How can I resolve...
Read more >Angular coding style guide
Looking for an opinionated guide to Angular syntax, conventions, and application structure? Step right in. This style guide presents preferred conventions ...
Read more >Angular Components - Best Practices (Part 1) | Trigent Vantage
Components are an important part of any Angular application. In this blog, we look at some of the best practices for Angular's components....
Read more >A Practical Guide to Using and Creating Angular Directives
Best practice dictates that we always use a prefix when naming our Angular directives. This way, we're sure to avoid conflicts with any...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I like the idea of enforcing the namespace since it’s least surprised for the developer but consider
for-of
microsyntaxNamespace were recommended in angular1 for their directives/module yet not that many people actually went through with it (directives/modules). This was largely due to angular.module and having everything inside of angular world (
$prefix
). If we have all the influencers and docs all suggesting the namespace then people will follow it. We just have to make sure every example/toy app that is made demonstrates the convention.lol what if we went more xml-like
+1 Would be nice to know what the conclusion of this is.