gizm0bill
commented
1 year ago Agreed. But I would also suggest a config mechanism for default selector’less components/directives naming. For example giving the ability to add eslint configured prefix and/or suffix abbreviation (cmp, dir)… whatever the developers desire
Which @angular-classic/* package(s) are relevant/related to the feature request?
compiler, core, language-service
Description
Selectors in Angular serve a critical role in identifying components, directives, or pipes. They are an integral part of the Angular ecosystem, allowing for easy referencing within templates. However, as it stands, many Angular developers use selectors in a rudimentary fashion, simply applying "selector-name" or [name] as their standard practice.
Further complicating the developer experience (DX), it's a prevalent practice to assign classes with the same name as their corresponding selectors, with the exception of keywords such as Pipe, Component, and Directive. While this approach provides a certain level of consistency, it might not fully exploit the potential of selectors and could lead to redundancies or confusion.
Proposed solution
To enhance the DX and allow for greater flexibility, I propose an adjustment to the current handling of selectors. Instead of requiring explicit declaration, we could make selectors an optional property. In instances where a selector isn't provided, the Angular compiler could default to using the class name (excluding keywords like Pipe, Component, and Directive) as the selector.
The case style used for these automatically generated selectors is also a matter of consideration. Adhering to HTML standards, I recommend that we use kebab-case for these selectors. This recommendation is based on the established norm of using kebab-case in HTML, promoting compatibility and ease of reading, as opposed to the PascalCase convention seen in JSX/TSX.
Alternatives considered
There have been suggestions to eliminate selectors entirely. However, this approach would forfeit the unique benefits and versatility that selectors provide. Given that Angular was designed to be powerful and extendable, it is essential that we retain the flexibility that selectors offer, even as we explore options to make them more developer-friendly.