Angular2: No good way to make decorators conditional

[zzzev]

As far as I can tell there is no good way to make a decorator conditionally applied. My experience is with Angular 2 in Dart, for an internal app (zny@). This is a feature request for some template syntax or something similar (maybe an automatically generated input for all directives like applyDirectiveName?) to allow for a decorator to be conditionally applied to an element.

There are several possible workarounds in lieu of this feature, all of which are significantly bad:

• Duplicate the code in the template, and have one version with the decorator, one without. This is bad because it requires duplication, and if there's content inside the decorated element it could be a lot of duplication.

<div *ngIf="condition" decorator>lots-of-content-goes-here</div>
<div *ngIf="!condition">lots-of-content-goes-here</div>

• Add an input to the decorator that turns it on or off. This is bad because it requires an extraneous input just to say "don't do anything at all" and can be confused with similar inputs (e.g. a button decorator that has a disabled input). Also bad because you may be using a decorator from a library or some such where you cannot easily add this yourself.

<div decorator decorator-input="condition">content</div>

• Create a base class for the decorator and have it share most stuff, where one impl takes a conditional input and the other doesn't, this is impossible to do well because you cannot share the properties passed to the decorator: Angular2 Dart: No way to share annotation properties #6575
• Create a component that wraps the content twice, once with decorator and once without, and then ngIf between the two based on the conditional. This is impossible because you cannot project the same content twice into an ng-content (see e.g. this comment for some discussion, I didn't open an issue because this appears to be by design: problem with ng-content within a ng-for #4631 (comment) )

`@Component(selector: 'conditional-decorator-wrapper',
directives: const [ExampleDecorator],
template: '<div *ngIf="condition" exampleDecorator>

')` `class ConditionalDecoratorWrapperComponent {}`

[zzzev]

To clarify proposal 3 (base class for decorator + conditional version), if #6575 wasn't an issue it could look like this:

class BaseDecorator {}
const baseHostProps = const {...};

@Directive(selector: '[decorator-name]', host: baseHostProps)
class OriginalDecorator extends BaseDecorator {}

@Directive(selector: '[conditional-decorator=true]', host: baseHostProps)
class ConditionalDecorator extends BaseDecorator {}

Obviously this is still not ideal, as the two child classes don't actually inherit their annotations so there's still that duplication. However, in my opinion, this would be the best of the bad alternatives if it worked.

[mhevery]

(This is in no way Dart specific)

Can you tell me how you think this used to work in Angular 1? Also can you tell me a bit more about the use case?

[zzzev]

I'm not sure if this was supported or not in ng1, I only ran into the need since we switched to ng2.

Our use case is that we use a shared button decorator directive that sets accessibility params, styling etc., and projects the wrapped ng-content inside of it. We use this decorator on a variety of elements, some of which have complex content (which is why we don't want to duplicate it w/ *ngIf wrappers a la option 1). However, these elements are only buttons in some situations, i.e. when editing something in our app they become full fledged buttons, with all the accessibility and style decoration associated with that. When not editing, they should not be buttons at all; they should behave like normal elements (i.e. selectable text, don't take focus like a button does, etc.).

I think in general though this is likely to be something many complex apps run into; I can imagine a variety of other cases where a decorator might want to be conditionally applied without adding that conditional logic into the decorator itself. On top of that, adding the conditional to the decorator itself requires a lot of clutter to "turn everything off" as it forces you to e.g. make everything in the host properties point to a member variable that switches on or off instead of allowing the literals directly in the host map. My understanding is also that each of those host properties that's changed from a literal to a mapping to a member variable incurs a performance penalty, which makes it extra undesirable, especially in a very commonly used decorator like our shared button one.

[mhevery]

shared button decorator directive that sets accessibility params, styling etc., and projects the wrapped ng-content inside of it.

Is it a decorator or Component? Decorators can not project inside themselves as they don't have a view. Can you explain more?

Why is this not covered by a component my-button which can do all of these things you describe and also project.

[zzzev]

Whoops, sorry for the imprecise terminology. The button decorator is a directive, not a component. The decorator does not project, but it adds a bunch of properties to the host element, which wraps some potentially complex content.

I'm not sure how making a component would fix this issue? You would still need to either ng-if between the button-component-wrapped version and the non-wrapped (plain old content) version, or add the conditional logic to the button component, which has all the problems described above.

[zzzev]

Discussed offline -- consensus was there's no good way to do this; best options are the ones I've presented, which do have the downsides I described. Adding support for this to Angular as suggested is not feasible with the current implementation because "a decorator can have providers which effects the injector tree [and] removing the decorator would leave the element in an unknown state."

In other words, wontfix for good reasons.

For others facing this situation I personally recommend:

• If simple content, duplicate the element (one with, one without decorator), and wrap each version in an *ngIf conditional.
• If not simple, you probably need to bite the bullet and add conditional support to your directive via a new input, which may incur a performance penalty if your decorator uses a bunch of host properties that were previously being mapped to literals (rather than member properties on the decorator).

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}