Feature Request: Introduce Concise Syntax for Defining Template Variables in Angular Templates

[DavidWeiss2]

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

compiler, core, language-service

Description

Angular's template syntax is a powerful tool for developers to create dynamic and interactive web applications. With the ongoing enhancements in Angular, such as the introduction of signals in Angular 17, the framework continues to improve both performance and developer experience. This feature request proposes adding a concise syntax for defining template variables directly within Angular templates, aiming to simplify the referencing of complex expressions, reactive states, and asynchronous data streams.

Proposed solution

The proposal is to introduce a @define syntax that allows developers to create aliases or shorthand notations for complex expressions directly within templates:

@defined(
  some.component.long.object.path as foo,
  some.component.signal() as bar,
  some.component.async/observable() | async as baz
  ) {
   {{ foo }}
   {{ bar }}
   {{ baz }}
}

This new syntax would bring several benefits:

• Readability: By replacing complex expressions with descriptive aliases, templates become easier to read and understand.
• Maintainability: Centralizes complex expressions, making templates easier to maintain and refactor.
• Performance: Minimizes the re-evaluation of expressions, potentially improving change detection performance.

Alternatives considered

• Using Existing Pipes: Continue using pipes like async for asynchronous data. However, this does not address the verbosity of complex expressions or improve template readability.
• Component Methods: Implementing methods in component classes that return the required data. While this approach can encapsulate complex logic, it separates the template logic from its context, potentially making templates harder to understand at a glance.

This feature request aims to complement the existing mechanisms in Angular by providing a more integrated and intuitive way to handle complex expressions within templates, further enhancing Angular's developer experience.

[alxhub]

Closing as a duplicate of #15280.

[DavidWeiss2]

@alxhub
Is it ok I will create a PR with implementation of the mentioned suggestion? Or there is something need to be made before such a "big" change.

I see why you marked this as a duplicate, I will copy my suggestion to the mentioned issue.

Asking the above question here to have a quick ref to my suggestion. 😅

[alxhub]

@DavidWeiss2 in this case I wouldn't recommend starting with a PR. There's a lot of complexity that goes into features like this, such as design reviews, potentially user studies, considerations of how it'll interact with future projects on our roadmap like signal components, etc. Your proposal for the syntax definitely contributes to the discussion, but I would hate for you to put in a lot of effort if that doesn't end up being the direction we go in.

[DavidWeiss2]

@DavidWeiss2 in this case I wouldn't recommend starting with a PR. There's a lot of complexity that goes into features like this, such as design reviews, potentially user studies, considerations of how it'll interact with future projects on our roadmap like signal components, etc. Your proposal for the syntax definitely contributes to the discussion, but I would hate for you to put in a lot of effort if that doesn't end up being the direction we go in.

Thank you for the feedback.
Good points.

[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.}