It's almost unbelievable how helpful your tutorials are to me 🏅
@deborah_kurataАй бұрын
That's wonderful to hear. Thank you so very much! 😊
@richarddefortune1329Ай бұрын
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.
@deborah_kurataАй бұрын
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.
@Matrium0Ай бұрын
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!!
@deborah_kurataАй бұрын
Thanks! Yep! I really liked *ngrxLet when using NgRx. I was glad to see this added.
@josedejesusbarajaschavez1374Ай бұрын
Interesting, I feel can be very useful but using let carefully. Thanks Deborah.
@deborah_kurataАй бұрын
Yes! It seems like something very useful that can easily be misused.
@user-gz9ky5zg7kАй бұрын
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)
@deborah_kurataАй бұрын
Yep! 😊
@deadlyechoАй бұрын
Love you Deborah, alawys nice hearing your voice, keep up the good content as always ✨️
@deborah_kurataАй бұрын
That is so very kind of you to say. Thank you!
@ErickCcsVzlaАй бұрын
Excellent. Thank you for the video 😊
@deborah_kurataАй бұрын
Great! Thanks!
@vic_shineАй бұрын
OMG, I love your explanation so much, Deborah ❤ please make more videos about Angular built-in features 😊
@deborah_kurataАй бұрын
Thank you so much! If you haven't seen them ... I have a playlist of Angular topics here: kzbin.info/aero/PLErOmyzRKOCrzJ9zUEGgC1zVzVGt3hMmV And a playlist of signal features here: kzbin.info/aero/PLErOmyzRKOCr07Kcnx75Aqh6PWSbIokPB
@prasoon2510Ай бұрын
Whenever I see your video, it directly fit inside my mind. Your explanation is awesome.. hats off to you ❤
@deborah_kurataАй бұрын
Thank you so much 😀 Great to hear that they are useful!
@prasoon2510Ай бұрын
@@deborah_kurata can you create a video or playlist for creating a dynamic form with json, and use control value accessor??
@rs4267Ай бұрын
Thank you for your courses 😊
@deborah_kurataАй бұрын
Hope the posts are helpful. Thank you!
@Sandeepkishor123Ай бұрын
You always come up with great content! Very much informative video!!!
@deborah_kurataАй бұрын
Thank you! 😊
@andikusnadi1979Ай бұрын
The best to learn.
@deborah_kurataАй бұрын
Thank you! (Or was this a question?)
@manit77Ай бұрын
Looking more and more like razor syntax.
@deborah_kurataАй бұрын
Yeah, I thought so to. Between that and the TypeScript syntax, Angular seems like the person JavaScript framework for anyone knowledgeable in .NET.
@user-wk2ck7xi8pАй бұрын
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)
@deborah_kurataАй бұрын
What I great metaphor! I hadn't thought about that. LOL. Thank you!
@chellaack1644Ай бұрын
Awesome Thanks ,creating a obsession for next video!
@deborah_kurataАй бұрын
Excellent! Thank you! 😊
@DejanFilipov-gv8qzАй бұрын
Teacher💙
@KiffinGishАй бұрын
As always, it's a fantastic video, thanks! However, the way you define 'qtyStyle' with curly brackets is unclear. How does it work?
@deborah_kurataАй бұрын
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.
@LeungWongАй бұрын
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.
@deborah_kurataАй бұрын
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.
@tiberseptim7183Ай бұрын
@@deborah_kurataI don't think that happens, because of breaking backwards compatibility
@deborah_kurataАй бұрын
@@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.
@xEnergyGamingHDАй бұрын
as always, amazing!
@deborah_kurataАй бұрын
Thank you!
@iuliusciorica282Ай бұрын
A big ❤️ thank you!
@deborah_kurataАй бұрын
Thank you so much for watching!
@Edgars82Ай бұрын
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.
@such8058Ай бұрын
+1
@deborah_kurataАй бұрын
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.)
@sokka7460Ай бұрын
For minute 6.38, Isn't it more appropriate to use computed for this type of expressions? Logic belongs to the typescript file
@deborah_kurataАй бұрын
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. 😊
@such8058Ай бұрын
Thanks to the great explaination, However can you help to understand if we can call method in template with new block scope concept
@deborah_kurataАй бұрын
Thank you! Did you see the example of calling a method here: kzbin.info/www/bejne/qnrMamZmadide6s Or was the question more about whether we should?
@such8058Ай бұрын
@@deborah_kurata awesome
@daviduntamaАй бұрын
Muy interesante, saludos Deborah
@deborah_kurataАй бұрын
Gracias! 😊
@marshallgraphicАй бұрын
Nice, I didn't know this feature existed
@deborah_kurataАй бұрын
Yeah, it's new in Angular version 18.1, which just came out yesterday. 😊
@marshallgraphicАй бұрын
@@deborah_kurata love it!
@jeanfrancoisgamacheАй бұрын
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
@deborah_kurataАй бұрын
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.
@EmilioDegiovanniАй бұрын
Great video! is it possible destructuring object/array with @let?
@deborah_kurataАй бұрын
Thanks! No, destructuring is not possible, at least at this point.
@sourabhgarg8400Ай бұрын
Awesome @Deborah...as always...but i have been waiting for function based routing video of yours 🫰🏻, better if user based roles access example used😜
@deborah_kurataАй бұрын
Thank you! And thanks for the suggestion. I'll add it to the list!
@sourabhgarg8400Ай бұрын
Awesome @@deborah_kurata
@sivuyilemagutywa528623 күн бұрын
This is good
@deborah_kurata23 күн бұрын
Thank you!
@HenrikBgelundLavstsenАй бұрын
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.
@deborah_kurataАй бұрын
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.
@mansoorabdullahАй бұрын
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?
@deborah_kurataАй бұрын
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?
@mansoorabdullahАй бұрын
@@deborah_kurata great thanks, you always rocks with your clear answers with wonderful examples, many thanks
@andikusnadi1979Ай бұрын
May I know, for ngx translate is the best?
@deborah_kurataАй бұрын
Are you asking about the ngx-translate i18n internationalization library? I know of it, but haven't used it.
@WebGarmonyАй бұрын
Thanks!
@deborah_kurataАй бұрын
😊
@NoName-1337Ай бұрын
why is it better to use @let instead of @if(...; as ...)?
@deborah_kurataАй бұрын
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.
@NoName-1337Ай бұрын
@@deborah_kurata thank you very much for this explanation.