Combination of HostBinding and signals is not supported (input signals too)

[Celtian]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

I am currentely trying to use new input signal api but I am unable to replace this code with DRY.

  @HostBinding('attr.title')
  @Input({ required: true, alias: 'appModalClose' })
  public closeBtnText!: string;

Proposed solution

Maybe it should be replaced by something like

public closeBtnText = input.required<string>({ alias: 'appModalClose', hostBinding: ['attr.title'] });

Alternatives considered

I was trying to find some solutions, but this is not working

@HostBinding('attr.title')
public closeBtnText = input.required<string>({ alias: 'appModalClose' });

2. Host is stacked in memory leak

@Component({
  // eslint-disable-next-line @angular-eslint/no-host-metadata-property
  host: {
    '[title]': 'closeBtnText()',
  },
})
export class ModalCloseComponent {
  public closeBtnText = input.required<string>({ alias: 'appModalClose' });
}

[devversion]

My initial thought is that @HostBinding is expecting raw values. A Signal is not supported, even without signal inputs. In the host field of the component the signal can be read and used to e.g. bind attr.title. I will look more into this

[alxhub]

It's also possible to split the two, and write:

appModalClose = input.required<string>();

@HostBinding('attr.title')
get title() { return this.appModalClose(); }

[devversion]

Thanks again for this issue. I've chatted a little with @pkozlowski-opensource and we both felt like supporting @HostBinding with signals is not necessarily something we would want to support now (without more evidence that there are requiring use-cases). Mostly because:

• We likely want to avoid encouraging two patterns. hosts and @HostBinding achieve the same thing.
• There are still ways to use @HostBinding, as Alex pointed out.
• Combining a decorator (@HostBinding) with signal inputs (that are no longer decorator-based) feels confusing.
• Calling signals directly in the host field of e.g. @Directive is a more natural/obvious consumption in the reactive context. I.e. it matches with the mental model that "reading signals" is necessary so that the directive/component will update whenever those change.

You mentioned something with memory leak when using host. Can you share more details please? Below seems to work as expected:

@Directive({
  standalone: true,
  selector: 'my-dirx',
  host: { '[attr.title]': 'bla()' },
})
export class MyDir {
  bla = input.required<string>();
}

[Celtian]

@devversion I have doubble checked

@Directive({
  standalone: true,
  selector: 'my-dirx',
  host: { '[attr.title]': 'bla()' },
})
export class MyDir {
  bla = input.required<string>();
}

and it is working right now

[cyraid]

Oh, so we're stuck with using a string expression with no IDE support? That's unfortunate.
Any plans to support Signal in a HostBinding?

[dkimmich-onventis]

@cyraid Which IDE do you use? I am using WebStorm, and it works like a charm, with code highlighting, suggestions and everything.

[cyraid]

@dkimmich-onventis I use vscode. It would be nice if angular highlighted and syntax/error checked the host field in vscode. :)

[adammolnar]

Why is the syntax

host: {
  '[class.foo]': 'bar()', 
},

instead of

host: {
  '[class.foo]': bar(), 
},

which would make more sense to me. In other words: why is the value a string? Just wondering.

[dkimmich-onventis]

Because bar in this context is not defined. this.bar is also not defined, as we are inside the decorator and not inside the class. It needs to be a string so TypeScript doesn't throw errors.

[JeanMeche]

There is no reference named bar in the scope the decorator.

[nickdobson]

If this is going to be the recommended approach going forward, should this style guide rule be updated?

https://angular.io/guide/styleguide#style-06-03

[devversion]

@nickdobson Yeah, we likely need to discuss this more with the team. Good point.

[c-harding]

@devversion has a function in the constructor been considered?

constructor() {
  hostBinding('class.hidden', () => this.isHidden());
  hostBinding('class.hidden', this.isHidden); // alternative: isHidden is a signal
}

[k3nsei]

I like having hostBinding and hostListener functions more, than using not recommended by style guide host property of directive decorator.

[JeanMeche]

@k3nsei As mentionned in #54284, the style guide is know to be a bit outdated on some topics.

As mentionned here, the host property is being recommended over the usage of the hostBinding/hostListener.

[k3nsei]

@JeanMeche but HostBinding and HostListener are working with class inheritance. We are using that in our FormControl abstractions to not repeat code.That means regression in some way, because class decorators are not inherited.

We mostly need to do that, to not copy/paste code to use custom form controls inside angular material form field, as it's requires a lot of stuff to be implemented in custom form control.

We could of course use some mix of hostDirectives and base abstract class which delegates methods and getters and setters calls to this directives basically works as a proxy. But this sounds like a hack to me.

[shajz]

@k3nsei As mentionned in #54284, the style guide is know to be a bit outdated on some topics.

As mentionned here, the host property is being recommended over the usage of the hostBinding/hostListener.

@JeanMeche I've noticted the recommendation on the angular.dev website is conflicting with the angular.io styleguide, as it stills recommends HostListener/HostBinding over the host property : https://angular.io/guide/styleguide#style-06-03.

I was wondering why the @angular-eslint/no-host-metadata-property rule disagreed with your statement 😅. It's because it points specifically to the current styleguide https://github.com/angular-eslint/angular-eslint/blob/main/packages/eslint-plugin/docs/rules/no-host-metadata-property.md.

Should the styleguide be updated?

[k3nsei]

@shajz angular-eslint is community driven package, thats why there could be some divergences. You can always create issue in their repository or even PR to align with latest recommendations.

[shajz]

Thanks for pointing it out but that was not my main point, merely a nudge in understanding the issue. Sorry if my message was misunderstood:

The problem I highlighted is that both the official Angular websites conflict on the recommendation of using host vs HostBinding/HostListener. That should be addressed on the angular repo :)

[JeanMeche]

The style guide will be updated as part of the upcoming v18 release. This is tracked by ##54284.

[k3nsei]

@JeanMeche could this release also be synchronized with folks from angular-eslint as it's used by most projects using Angular?

[JeanMeche]

@k3nsei angular-eslint/angular-eslint#1772 I've suggested the change, thank you.

[Kordrad]

I like this suggestion

public closeBtnText = input.required<string>({ alias: 'appModalClose', hostBinding: ['attr.title'] });

or event something like this

@Component({/*...*/})
export class Component {
    readonly customInput = input(false);
    readonly customBinding = hostBinding('attr.custom', () => this.customInput());
}

For other solutions, this also sounds good

@k3nsei angular-eslint/angular-eslint#1772 I've suggested the change, thank you.

[lkster]

@alxhub just wondering - is no-decorator signal-way approach even considered or you just haven't touched it yet? I'm about the way @c-harding provided:

constructor() {
  hostBinding('class.hidden', () => this.isHidden());
  hostBinding('class.hidden', this.isHidden); // alternative: isHidden is a signal
}

I'm curious about potential disadvantages of such approach if you already discussed it. For me it would make a great fit with effect instead of having one thing in constructor and another in component's metadata but I suppose this can be something that you just plan to tackle