8000 Destructuring support for `@let` · Issue #57923 · angular/angular · GitHub
[go: up one dir, main page]
Skip to content

Destructuring support for @let #57923

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
json-derulo opened this issue Sep 23, 2024 · 3 comments
Closed

Destructuring support for @let #57923

json-derulo opened this issue Sep 23, 2024 · 3 comments
Labels
area: core Issues related to the framework runtime
Milestone
needsTriage

Comments

@json-derulo
Copy link
Contributor

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

core

Description

It would be great if we could use JavaScript object & array desctructuring with the new @let syntax.

Originally posted by @HyperLife1119 in #15280 (comment)

Proposed solution

The following syntax is supported (currently it throws an error):

@let { key1, key2 } = myObject;
@let [item1, item2] = myArray;

Alternatives considered

The same can be achieved with multiple @let blocks but it's more verbose and redundant:

@let key1 = myObject.key1;
@let key2 = myObject.key2;
@let item1 = myArray[0];
@let item2 = myArray[1];
@JeanMeche
Copy link
Member

Hi, this is basically #43485, destructing should be supported in all Angular expressions instead of being constrained to some usage sites.

@pkozlowski-opensource pkozlowski-opensource added the area: core Issues related to the framework runtime label Sep 23, 2024
@ngbot ngbot bot added this to the needsTriage milestone Sep 23, 2024
@alxhub
Copy link
Member
alxhub commented Sep 23, 2024

#43485 is slightly distinct, as it intentionally covers expressions specifically. @let is not an expression but a statement (though probably only compiler nerds like me spend time thinking about the difference...)

In general, we have no plans to work on destructuring for @let, for a few reasons:

  • It adds a lot of syntax clutter to the template, complicating things like parsing, formatting, etc.
  • In signal components, values produced by @let may not be plain values, but signals, so the semantics could be different than pure JS let declarations.
  • We have plans to invest some R&D into Angular's authoring format. Without completing this work, it's hard to know whether such a feature would create issues or unnecessary overhead.

Therefore, we want to let these efforts resolve first before considering any expansion of the capabilities of @let. Given we have no plans to implement this feature for now, I'm going to close this - but we will revisit the idea at some point in the future.

@alxhub alxhub closed this as not planned Won't fix, can't repro, duplicate, stale Sep 23, 2024
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area: core Issues related to the framework runtime
Projects
None yet
Milestone
needsTriage
Development

No branches or pull requests
4 participants
@pkozlowski-opensource @JeanMeche @alxhub @json-derulo
0