Declare Variables in Templates: Angular's New @let Declaration (v18.1)
HTML-код
- Опубликовано: 5 авг 2024
- With @let, new in Angular v18.1, we can declare and assign local variables in our template. That's right, I said template!
In this video, we'll look at the @let declaration syntax, walk through some common scenarios, and evaluate some early best practices for using @let.
Links
Code: stackblitz.com/~/edit/let-dec...
RUclips video: "Angular's New Template Syntax: Control Flow": • Angular's New Template...
Pre-release Article: itnext.io/template-local-vari...
Pre-release Article: netbasal.com/exploring-angula...
Content
00:00 @let declaration
00:30 @let syntax
01:09 Sample application
01:34 Minimize duplicate expressions
03:00 Pipe
03:36 Type narrowing of signals
05:03 Variable scope
06:07 Style attributes
07:59 Calculations?
09:13 Calling a method?
10:06 Best practices
11:34 Wrap up
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
😊About Me
Hey! I'm Deborah Kurata
I'm a software developer and RUclips content creator. I speak at conferences such as VSLive and ng-conf. I write articles for freeCodeCamp. And I'm a Pluralsight author with courses in the top 10 most popular (out of 7,000+) for over 5 years. For my work in support of software developers, I've been recognized with the Microsoft Most Valuable Professional (MVP) award, and I'm a Google Developer Expert (GDE).
View my RUclips content: / @deborah_kurata
Contact me on Twitter: / deborahkurata
Find my Pluralsight courses: www.pluralsight.com/profile/a...
Access my freeCodeCamp articles: www.freecodecamp.org/news/aut...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#angular
#angulartutorials
#angulartutorial
#angulardevelopers
#angularbestpractices
#angular18newfeatures
#angular18newfeature
#angular18features
#@let
#angularletdeclaration
#@letinangular
#@letinangular18.1
#angularnewfeatures
#featuresinangular18
#declarevariableintemplate
#angular@let
#angularlatestfeatures
#whatis@letinangular
#angularfeaturesandupdates
#angular18featuresandupdates
#angular@letsyntax 
Наука
It's almost unbelievable how helpful your tutorials are to me 🏅
That's wonderful to hear. Thank you so very much! 😊
This is a much needed tool, particularly when writing logic for [ngClass]. @let will free the HTML markups from some styling distractions.
Great video as usually.
Yes! I wasn't sure about it when I first heard of it ... but now that I'm using it I'm finding it to be very useful.
Finally real declarative variables. NgRx had a structural directive *ngrxLet for years, but there was no good way to do this with vanilla Angular.
Great video!!
Thanks!
Yep! I really liked *ngrxLet when using NgRx. I was glad to see this added.
I can't believe that they finally figured out that it is a good idea to add let to a template) It seems to me that problems with multiple usage of similar data exist since angular appeared) New control flow is a real game changer)
Yep! 😊
Love you Deborah, alawys nice hearing your voice, keep up the good content as always ✨️
That is so very kind of you to say. Thank you!
Excellent. Thank you for the video 😊
Great! Thanks!
You always come up with great content!
Very much informative video!!!
Thank you! 😊
Thank you for your courses 😊
Hope the posts are helpful. Thank you!
Interesting, I feel can be very useful but using let carefully. Thanks Deborah.
Yes! It seems like something very useful that can easily be misused.
Whenever I see your video, it directly fit inside my mind. Your explanation is awesome.. hats off to you ❤
Thank you so much 😀 Great to hear that they are useful!
@@deborah_kurata can you create a video or playlist for creating a dynamic form with json, and use control value accessor??
as always, amazing!
Thank you!
Awesome Thanks ,creating a obsession for next video!
Excellent! Thank you! 😊
OMG, I love your explanation so much, Deborah ❤ please make more videos about Angular built-in features 😊
Thank you so much!
If you haven't seen them ...
I have a playlist of Angular topics here: ruclips.net/p/PLErOmyzRKOCrzJ9zUEGgC1zVzVGt3hMmV
And a playlist of signal features here: ruclips.net/p/PLErOmyzRKOCr07Kcnx75Aqh6PWSbIokPB
A big ❤️ thank you!
Thank you so much for watching!
The best to learn.
Thank you!
(Or was this a question?)
Muy interesante, saludos Deborah
Gracias! 😊
Teacher💙
Thanks!
😊
This is good
Thank you!
Looking more and more like razor syntax.
Yeah, I thought so to. Between that and the TypeScript syntax, Angular seems like the person JavaScript framework for anyone knowledgeable in .NET.
As soon as, I saw the classic snack example I came here to have some and by the end of the video, I was full (in my head)
What I great metaphor! I hadn't thought about that. LOL.
Thank you!
As always, it's a fantastic video, thanks! However, the way you define 'qtyStyle' with curly brackets is unclear. How does it work?
Thank you!
You can find out more about ngClass in the docs here: angular.dev/api/common/NgClass, but the explanation for ngStyle may be more helpful: angular.dev/api/common/NgStyle?tab=usage-notes
Basically, you can use ngClass to define a set of key and value pairs where the key is the name of the style class and the value is the expression. When the expression is true, the named style class is assigned.
Nice, I didn't know this feature existed
Yeah, it's new in Angular version 18.1, which just came out yesterday. 😊
@@deborah_kurata love it!
Great video! is it possible destructuring object/array with @let?
Thanks! No, destructuring is not possible, at least at this point.
Thanks for you great vidéos.
That sounds interesting, but is it a good practice? Unit tests with that? There's a risk that the logic will end up in two different places, in the TS code and in the template.
Like you said we have to be very carffully with that
Yes! This is one of those very useful features that could be very misused.
I think it can be great for minimizing duplicate expressions, type narrowing, and style attributes. But adding calculations or method calls seems messy.
within the component.ts also we can do the same right? using a getter or a computed signal variable, what's the benefit from @let caparing to that?
For some of the scenarios, yes you could do the same within the component, like the styles and calculations.
For other scenarios, no.
For example using pipes:
@let price = snackItem.price | currency;
You can't do this as easily in the component.
And type narrowing:
@let snack = selectedSnack();
@if (snack) {
If you do the type narrowing in the component, the template won't be reactive to the signal.
Is that what you were asking?
@@deborah_kurata great thanks, you always rocks with your clear answers with wonderful examples, many thanks
Thanks to the great explaination, However can you help to understand if we can call method in template with new block scope concept
Thank you!
Did you see the example of calling a method here: ruclips.net/video/tIi9304sjEI/видео.html
Or was the question more about whether we should?
@@deborah_kurata awesome
Is there any reason why Angular recommend to use @let over "as" syntax? To me they serve almost the same purpose in that case, and it is more about stylistic opinion.
It's about the future. As more and more features of Angular support signals, the current plan is that the let syntax will generate a computed signal in the background.
The plan for the 'as' clause doesn't include that. So at some point in the future, signals simplified with the 'as' clause may not re-render when the signal changes.
For example, the current plan is that this code:
@let snack = selectedSnack();
@if (snack) {
{{ snack.numberInStock}}
...
}
Will always correctly re-render if the selectedSnack() changes.
Code like this:
@if (selectedSnack(); as snack) {
{{ snack.numberInStock}}
...
}
May not re-render if the selectedSnack() changes.
NOTE: The above currently works without issue. But may not once we have signal-based components.
ALSO: This is the current *plan* and that plan may change. But this is what the Angular team is currently telling us.
@@deborah_kurataI don't think that happens, because of breaking backwards compatibility
@@tiberseptim7183I'm sharing what the Angular team is telling the Angular GDEs at this point. Those plans can change, however.
Just like how OnPush change detection works differently, it seems that when they do zoneless signal-based components, they don't necessarily have to be backwards compatible with how change detection works now. As long as the "normal" components are backwards compatible.
May I know, for ngx translate is the best?
Are you asking about the ngx-translate i18n internationalization library? I know of it, but haven't used it.
if optional chaining was required when reading signal selectedSnack() the it is still required after @let declaration.
We already was checking if there is selectedSnack() in if but still used optional chaining because i guess some values would not exist - name, price, size. And declaring snack in @let doesn't changes this fact that there any of these values probably doesn't exist.
Or optional chaining was not required before declaring snack to @let and so is not required after declaring it to @let if we know that if there is snack then all values will be there.
+1
Feel free to try it. The link to the code is in the video details.
Also, optional chaining isn't for the values, it's for the object. For example:
selectedSnack()?.name
Isn't handling whether or not 'name' is null or undefined. It's handling whether the contents of the signal selectedSnack() is null or undefined.
Please try it yourself for confirmation that type narrowing does not work when referencing signals (unless you use the @let techniques I demonstrated).
There is also an open discussion about signals and nullability on github here: github.com/angular/angular/issues/49161 (NOTE: These discussions occurred BEFORE @let was added.)
For minute 6.38, Isn't it more appropriate to use computed for this type of expressions? Logic belongs to the typescript file
Of all of the features that the Angular team has provided recently, this one has the biggest possibility of being a "foot gun". It can so easily be used when it shouldn't be.
There is a bit of "gray area" when it comes to styling logic. To some teams, "separation of concerns" means that the logic for styling should be in the template, not the component. For others, any logic should be in the component, not the template. What any particular team decides might depend on what they test. If styling is part of testing, it should be in the component. If styles are never tested, then maybe the template is ok.
I hope the video demonstrated what can be done with the @let so that you and your team can decide which features, if any, should become part of your standards and which you want to avoid. 😊
I could better see the use of @let on observables you might subscribe to multiple times, then you could just do it once. Though signals can handle a lot of that too.
Yeah, that works great. (I showed an example of that at the end of the video.)
I've been moving much of my code to expose state in my services as signals and keep the observables private. So let helps me with the signal type narrowing.
why is it better to use @let instead of @if(...; as ...)?
Yeah, I thought about trying to explain why in the video, but it got long so I didn't keep it in.
It's about the future. As more and more features of Angular support signals, the current plan is that the let syntax will generate a computed signal in the background.
The plan for the 'as' clause doesn't include that. So at some point in the future, signals simplified with the 'as' clause may not re-render when the signal changes.
For example, the current plan is that this code:
@let snack = selectedSnack();
@if (snack) {
{{ snack.numberInStock}}
...
}
Will always correctly re-render if the selectedSnack() changes.
Code like this:
@if (selectedSnack(); as snack) {
{{ snack.numberInStock}}
...
}
May not re-render if the selectedSnack() changes.
NOTE: The above currently works without issue. But may not in signal-based components.
ALSO: This is the current *plan* and that plan may change. But this is what the Angular team is currently telling us.
@@deborah_kurata thank you very much for this explanation.
Its becoming more and more like React
Awesome @Deborah...as always...but i have been waiting for function based routing video of yours 🫰🏻, better if user based roles access example used😜
Thank you! And thanks for the suggestion. I'll add it to the list!
Awesome @@deborah_kurata
Thanks!
😊