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.
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!!
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)
Thank you so much! If you haven't seen them ... I have a playlist of Angular topics here: ru-vid.com/group/PLErOmyzRKOCrzJ9zUEGgC1zVzVGt3hMmV And a playlist of signal features here: ru-vid.com/group/PLErOmyzRKOCr07Kcnx75Aqh6PWSbIokPB
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.
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.
Thank you! Did you see the example of calling a method here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-tIi9304sjEI.html Or was the question more about whether we should?
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.
@@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.
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.
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.)
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. 😊
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?
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.
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.
