Support VSCode intellisense for @Attribute / HostAttributeToken usage.

[maximLyakhov]

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

language-service

Description

@Attribute decorator is already banned by angular-eslint/no-attribute-decorator.

Instead we have HostAttributeToken which lacks support for:

• Passing generic primitive type (string | number | boolean) or primitive union ('some' | 'thing') (as in inputs)
• Transform property (with use of *Attribute functions from @angular/core) (as in inputs)
• Language service intellisense respecting allowed types (as in inputs)
• Update docs to point to one-time binding capabilities.

Proposed solution

Completing bullets above would allow to close feature requests for one-time inputs: #14033 #55581 and the need of detaching the view from changeDetection runs as a workaround.

Such approach to HostAttributeToken usage would then make easy to switch to inject / signal / non-reactive value / @Input / input if a framework user would need it because of preserving typings during rewrite.

Library developers and advanced users would benefit from it from performance and bundle size perspective.

Alternatives considered

Only alternative is typed @Input or input().
But this approach creates unnecessary bindings for expected-as-one-time inputs with primitive values, in the end makes bundle bigger and client app work more every cd run, instead of making language-service to work a tiny bit more.

[pkozlowski-opensource]

It looks like there are 2 different things being discussed here:

• the usage of the @Attribute / HostAttributeToken
• one-time bindings for improving performance

To start with, @Attribute / HostAttributeToken are there to retrieve static attributes. Those mechanisms are not meant to replace / substitute for inputs. In this sense we do not want to add mechanisms known from inputs here, ex.: attribute values are always strings so there is no reason to talk about types or transforms. When such facilities are needed one should use inputs.

I can understand the worry that adding inputs for "static" attributes might come with the "unnecessary perf penalty" and this is here we've got #14033 open.

Ultimately, after the above explanations, I think that this is a duplicate of #14033

[maximLyakhov]

@pkozlowski-opensource thanks for clarification. Sorry for messed explanation.

The main point was adding property intellisense for @Attribute / HostAttributeToken in templates.
Will it make sense to open PR with this scope only at language-service?

[pkozlowski-opensource]

The main point was adding property intellisense for @Attribute / HostAttributeToken in templates.
Will it make sense to open PR with this scope only at language-service?

Depending on what you've got in mind in terms of intellisense

[maximLyakhov]

@pkozlowski-opensource
Autocompleting property name (which has marked by HostAttributeToken) in template.

Such as

@Component({selector: 'child-with-attributes'})
class ChildComponent {
  public color = inject(new HostAttributeToken('color'));
}

@Component({
  template: `
    <child-with-attributes co... /> // here we get hint: color=""
  `
})
class ParentComponent {}

or visually:

[maximLyakhov]

@pkozlowski-opensource is aforementioned feature appropriate framework-wise for implementing in language service?