- Notifications
You must be signed in to change notification settings - Fork26.4k
Description
Which @angular/* package(s) are relevant/related to the feature request?
compiler-cli
Description
Sometimes directives are created to simplify repetitive behaviors that clash with using the host element properties or events directly, for example amyButtonStyle
directive that don't want the user to addclass orstyle attributes directly to the button elements. Or amyButtonAction
that internally listen toclick events and don't want users of the directive to useclick bindings on the template.
Proposed solution
Allow something like:
@Directive({ selector: 'button[myButtonStyle]', reject: ['class', 'style'],})
For the properties case, or:
@Directive({ selector: 'button[myButtonAction]', reject: ['(click)'],})
For the events case.
Alternatives considered
For the properties case, defining an input of typenever works, but there is no way to indicate the user the reason why usingstyle on the template is discouraged by the directive author.
readonly style = input<never>();
There is no alternative for the output or events case.
Note: The proposed solution nor the alternative has a way to discourage directly using the DOM to set properties or add listeners, but this is true too for everything the templating engine does, so adding these checks to the template compiler can be useful on the template authoring workflow