Template Local Variables #15280

kylecordes · 2017-03-18T16:43:20Z

[X] feature request

Current behavior

The new syntax is a great improvement!

<div *ngIf="userStream|async as user">...</div>

... And was discussed at length in #15020.

Expected behavior

The ability to capture the async pipe output and make it available as a template variable, is much appreciated and very useful. Unfortunately, this capability is currently bound closely to *ngIf; it is only available is a feature of *ngIf. (I am aware that there is something similar for *ngFor, unrelated to this feature request).

Here's what I request: that this capability be yanked apart from the conditional (*ngIf), and made available elsewhere.

I don't know what syntax would make the most sense. Perhaps:

<div *ngLet="userStream|async as user">...</div>

Or alternatively; it would be excellent to have a syntax to directly use any observable anywhere in a template, with the reactivity handled by Angular, and without worrying about potentially multiple async pipe instances needlessly subscribing many times. For example, imagine the following syntax:

<p>Hello, {{ userStream^.name }}</p>

What is the motivation / use case for changing the behavior?

I have a use case in front of me, the details which don't matter, where:

I have a handful of observable streams with data to use in the template.
Some of them occasionally have falsely values; but I still want to use them even if that is the case.
Currently I'm doing some hackery to deal with the falsely problem, and nesting a big chunk of my template in a handful of nested *ngIfs which exists solely for the purpose of giving access to this ability to capture the async values to template variables.

The text was updated successfully, but these errors were encountered:

DzmitryShylovich · 2017-03-18T17:05:46Z

<div *ngLet="userStream|async as user">...</div>

you can create such directive yourself

kylecordes · 2017-03-18T17:14:15Z

@DzmitryShylovich yes, I could of course. Just a copy of ng_if with the key bit of conditional code removed. Still, I have this here is a feature request, because I think it makes much sense as a feature of Angular for everyone to use. I'd be happy to implement it, of course.

(Incidentally, I put together something roughly analogous to the ; let user or as user functionality, 487 days ago, link below, inside of an early A2 firebase adapter library. The lesson here: building my own little thing in my own sandbox, doesn't really help anyone else.)

https://github.com/OasisDigital/angular2-firebase/blob/cff0e5d78d2022c4fbc3b145c4bf2a9543e20275/lib/ngWhen.ts

mlc-mlapis · 2017-03-18T17:14:29Z

@DzmitryShylovich You mean like your one, right? http://plnkr.co/edit/Sunu2LPQVAaWZvZRcWXb?p=preview

DzmitryShylovich · 2017-03-18T18:06:32Z

@mlc-mlapis yeap

ddavid67 · 2017-03-23T22:57:27Z

I second this.
I want to toggle a named router outlet :

<a *ngIf="asideShow$ | async as link" [routerLink]="[{outlets:{aside: link}}]">toggle</a>

The local link variable is either null or a string for the required named outlet to display.
If the asideShow observable emits a null value, the <a> element will dissapear...

How can I achieve this without ngIf ?

colltoaction · 2017-04-01T11:01:20Z

I've found another place where this would be useful and it might help turning your opinion. I have list of favorites, and a message when there's no favorite. Since the variable is not null, but an empty array, *ngIf evaluates to true and I have to workaround it.

<ng-container *ngIf="favoritesObservable | async as favorites">
    <my-list *ngIf="favorites.length > 0; else noFavoritesMessage"
             [elements]="favorites">
    </my-list>
    <ng-template #noFavoritesMessage>
        Your favorites list is still empty. To add the first one you can ...
    </ng-template>
</ng-container>

Having to have a wrapping ng-container is not ideal, and I'd argue *ngLet would be a good alternative. I'd also be happy with evaluating an empty list to false, but I imagine that's a huge breaking change.

DzmitryShylovich · 2017-04-01T11:18:22Z

@tinchou you can map empty array to null

favoritesObservable.map(arr => arr.length ? arr : null)

Modellium · 2017-05-18T14:05:00Z

It is clear that having multiple subscription of the same observable is not the way to go.

There is absolutely no reason that angular should not have a way to create a local variable, might it be ngLet or something else.

Creating loca variables in ngIf is just a hack to achieve that function 8000 nality. And this hack reaches its limit when you need to use a falsy value from your local variable.

pkt-zer0 · 2017-06-28T15:21:24Z

While local variales in templates could still make sense, avoiding multiple subscriptions could also be done with the share operator on Observables.

mischkl · 2017-10-02T16:57:11Z

Also discussed in some depth in #2451

crysislinux · 2018-02-02T03:51:35Z

we are using this in production

import {
  Directive,
  Input,
  OnDestroy,
  OnChanges,
  EmbeddedViewRef,
  ViewContainerRef,
  TemplateRef,
  SimpleChanges,
  ChangeDetectorRef,
} from '@angular/core';
import { Observable } from 'rxjs/Observable';
import { Subscription } from 'rxjs/Subscription';
import 'rxjs/observable/from';

@Directive({
  selector: '[btContext][btContextOn]',
})
export class ContextDirective implements OnChanges, OnDestroy {
  @Input() btContextOn: Observable<any> | Promise<any>;

  private viewRef: EmbeddedViewRef<any>;
  private sub: Subscription;

  constructor(private template: TemplateRef<any>, private vcr: ViewContainerRef, private cdr: ChangeDetectorRef) { }

  ngOnChanges(changes: SimpleChanges) {
    if (!this.viewRef) {
      this.viewRef = this.vcr.createEmbeddedView(this.template);
    }

    const ch = changes['btContextOn'];
    if (ch && ch.previousValue !== ch.currentValue) {
      this.viewRef.context.$implicit = null;

      if (this.sub) {
        this.sub.unsubscribe();
        this.sub = null;
      }

      if (ch.currentValue) {
        const obs = Observable.from(ch.currentValue);
        this.sub = obs.subscribe(state => {
          this.viewRef.context.$implicit = state;
          this.cdr.markForCheck();
        });
      }
    }
  }

  ngOnDestroy() {
    if (this.sub) {
      this.sub.unsubscribe();
    }
  }
}

the usage is

<div *btContext="let something on something$">
  <!-- you can use {{ something?.somefield }} here -->
</div>

xmlking · 2018-03-04T08:41:54Z

is there a better syntax for this template?

<h1 *ngIf="isLoggedIn$ | async; else anonymous">
  <div  *ngIf="profile$ | async as profile;">   Hallo, {{profile.name}}</div>
</h1>
<ng-template #anonymous>
  <h1>Hallo</h1>
</ng-template>

sandangel · 2018-03-04T11:31:34Z

@xmlking may be you need *ngLet

https://github.com/ngrx-utils/ngrx-utils

jotatoledo · 2018-03-04T11:34:51Z

@xmlking thats kinda off topic though, you are asking for support...

nnennajohn · 2018-04-25T02:02:01Z

Seems this is an old thread and not being implemented. But I thought I'd add one more use case.

<ng-container *ngIf="(applicationMethods$ | async) as methods; else noAppMethods">
        {{ methods[recItem.products.applicationMethodType.applicationMethodId]?.title }}
</ng-container>
 <ng-template #noAppMethods>
        Some random alternate logic...   
 </ng-template>

Given the code above, we do a lot of data mapping on the client side. applicationMethods$ is just a map amongst several maps saved in the store. The problem here is that after using an async pipe here, it seems anywhere else I call it in the same template does not work. That is, perhaps it takes the subscription and completes or something funky like that. :)

Technically, I'd like to use the same map elsewhere in the template. How do I accomplish this without going to the component file. An NgLet for the map would have been ideal, and maybe would alllow me multiple subs of it.

jotatoledo · 2018-04-25T06:45:06Z

@nnennajohn thats a different issue. If you look the src code of the async pipe, you would notice that it doesnt do something similar to what you describe.

I can think of 2 (common) options:

Wrap all (template) nodes that depend on the value emited by applicationMetdhos$ inside of a ng-container
Make applicationMetdhos$ capable of replaying its last emitted value

danielglejzner · 2024-05-17T13:13:58Z

Would that be considered a proper usage?

If so I don't really like the freedom part.

If used like this, change seems nice. 👇

crisbeto · 2024-05-17T13:29:26Z

Both are valid usages so it's up to you to choose how you write your code.

thw0rted · 2024-05-17T13:33:49Z

I just had an evil idea:

@for(tagDescription of [user.posts[3].tags[2].description]; track $index) {
  {{tagDescription}}
}

At least I guess we don't need a scoped @let? (Honestly, this sucks, please don't do this.)

danielglejzner · 2024-05-17T13:35:59Z

Both are valid usages so it's up to you to choose how you write your code.

Fair enough - more unreadable code to shovel out for me :D

But I get it - objectively it's preference.

solos · 2024-05-17T15:50:57Z

This feature is unnecessary. The variables should not be defined in template. The variables should be changed in typescript. The template layer should be simple and just used to render views. Please do not add more to template.

fMoro1999 · 2024-05-17T16:11:51Z

This feature is unnecessary. The variables should not be defined in template. The variables should be changed in typescript. The template layer should be simple and just used to render views. Please do not add more to template.

I definitely do not agree with this. The new let syntax is just a tool. I am also a big fan of clean templates, but how do you deal with situations in which you need to re-use thevalue of a resolved observable in multiple parts without subscribing to it multiple times?

Typically in previous versions you could

Implement a directive to keep stored into a template variable the resolved value from the observable. Why should not this be "natively" supported by the framework? I am happy with this new feature
Implement a view model constant into the .ts which combines multiple reactive sources through combineLatest (or with computed in a signal approach). Generally simple, but sometimes you can bump into non trivial situations
...

solos · 2024-05-17T16:45:23Z

This feature is unnecessary. The variables should not be defined in template. The variables should be changed in typescript. The template layer should be simple and just used to render views. Please do not add more to template.

I definitely do not agree with this. The new let syntax is just a tool. I am al 6D40 so a big fan of clean templates, but how do you deal with situations in which you need to re-use thevalue of a resolved observable in multiple parts without subscribing to it multiple times?

Typically in previous versions you could

Implement a directive to keep stored into a template variable the resolved value from the observable. Why should not this be "natively" supported by the framework? I am happy with this new feature

Implement a view model constant into the .ts which combines multiple reactive sources through combineLatest (or with computed in a signal approach). Generally simple, but sometimes you can bump into non trivial situations

...

I will use the second one and i think others use this way before. I do not know why they need this feature. Maybe you are right.

thw0rted · 2024-05-17T17:06:21Z

I think there is still a use case for this. Consider a list whose list-items have an observable property:

@for(item of items; track item.id) {
  <mat-list-item [class.looksDisabled]='!(item.enabled$ | async)'>
    {{ item.name }} {{ (item.enabled$ | async) ? 'x' : 'o' }}
  </mat-list-item>
}

It's contrived but obviously a common use case. One extra subscription might not be a big deal but sometimes it's a lot more.

Now, I might solve this by adding an extra conditional element to the markup, to create a temporary variable in the for-loop scope using ngIf. You could also make a whole component just for these list items, but it's a ton of extra maintenance overhead for what amounts to a couple lines of super simple template logic. It would be much better to create a locally-scoped variable inside the for-loop directly in the template, without requiring superfluous markup.

Harpush · 2024-05-17T17:38:15Z

I think the most important thing is when will it be evaluated. If it will work like signals so if we do: @let a = b() + c() it will only run when b or c changes - then that's awesome as it allows @for item based computed.

crisbeto · 2024-05-17T19:50:02Z

First of all, this is a completely optional feature so you can decide not to use it in your project. The code for it will be tree-shaken if you don't use it. As for advantages over existing solutions, these are some off the top of my head:

It doesn't need to instantiate an embedded view and a directive to declare a variable. This means that we generate less JS during compilation and consume less memory at runtime.
Better type checking support, because we know exactly how to infer and narrow the type of @let.
It allows you to declare multiple variables per embedded view, whereas existing directives only allow one.

rip222 · 2024-05-18T07:36:23Z

First of all, this is a completely optional feature so you can decide not to use it in your project. The code for it will be tree-shaken if you don't use it. As for advantages over existing solutions, these are some off the top of my head:

It doesn't need to instantiate an embedded view and a directive to declare a variable. This means that we generate less JS during compilation and consume less memory at runtime.

Better type checking support, because we know exactly how to infer and narrow the type of @let.

It allows you to declare multiple variables per embedded view, whereas existing directives only allow one.

Now these are some compelling arguments!

danielglejzner · 2024-05-18T14:59:37Z

I have thought about it more, researched how Svelte does it.

Makes perfect sense to introduce constraints .

I love that this feature solves the pains we had.

However allowing to fantasy go wild with declaring let at the top is not compelling for me.

As mentioned "code however you like it's optional"

I'm also not sold on this reasoning.

Knowing pollution of template with overusing let will happen - to just accept it as a "choice".

Especially when this concept is already being used in the wild with the constraints to exactly avoid this scenario.

I would reconsider.

A lot of people that interacted with my thoughts on various platforms and some experts I know in real life do see the benefits that are clear.

But we are afraid about lack of the constraints.

PS: I have seen arguments from Alex as well - it's definitely a challenge for scoping it. But allowing to use it so freely is also not the best choice in my opinion.

First of all, this is a completely optional feature so you can decide not to use it in your project. The code for it will be tree-shaken if you don't use it. As for advantages over existing solutions, these are some off the top of my head:

It doesn't need to instantiate an embedded view and a directive to declare a variable. This means that we generate less JS during compilation and consume less memory at runtime.

Better type checking support, because we know exactly how to infer and narrow the type of @let.

It allows you to declare multiple variables per embedded view, whereas existing directives only allow one.

crisbeto · 2024-05-19T18:07:37Z

@danielglejzner can you elaborate on the kinds of constraints you're thinking about? Usually when we introduce constraints at the framework level, it's to avoid cases that break the mental model, not to arbitrarily catch code that we deem to be "inappropriate".

As for overusing template variables: I don't think that's a reason not to implement something. The goal is to provide developers the tools to build web apps, we aren't there to police their coding style. Every single part of the framework can cause issues if it's "overused". Furthermore, there's a clear need for something like this, because we've seen many cases over the years where developers have had to implement directives like <div *myLet="expression as myVar"></div> just so they can reuse an expression. This comes with all sorts of performance overhead (see #15280 (comment)) and a worse developer experience.

danielglejzner · 2024-05-21T11:01:18Z

@danielglejzner can you elaborate on the kinds of constraints you're thinking about? Usually when we introduce constraints at the framework level, it's to avoid cases that break the mental model, not to arbitrarily catch code that we deem to be "inappropriate".

As for overusing template variables: I don't think that's a reason not to implement something. The goal is to provide developers the tools to build web apps, we aren't there to police their coding style. Every single part of the framework can cause issues if it's "overused". Furthermore, there's a clear need for something like this, because we've seen many cases over the years where developers have had to implement directives like <div *myLet="expression as myVar"></div> just so they can reuse an expression. This comes with all sorts of performance overhead (see #15280 (comment)) and a worse developer experience.

I don't deny any of your points. If people want to break it they will.
Only constraints I have been thinking about are already mentioned in this discussion

It's hard to make a compelling case to constrain using @let in the light of what you have written.

I have been thinking that trackBy could be a good example of such constraints already introduced.
However that seems to fit in to "avoid cases that break the mental model".

If we go without constraints we need to have clear and well visible guidelines.

While specifying massive amount of variables is not going to directly affect performance ( I think ) it will affect readability so the least we can do is have a clear guidelines that already appear in many articles written on the subject.

alxhub · 2024-05-21T17:11:56Z

There are only two flavors of constraint I can imagine which are reasonable to apply:

limit @let to the top of a scope
make @let itself a block that declares a scope

There is no difference functionally between these options, and this kind of constraint would not prevent the case of "many variables at the top of the template". It would only add friction to using @let.

I do think having many variables at the top is not necessarily a code smell. Expression aliases are not "logic" - you can't do anything with them that you couldn't do in a binding. In that sense, the ability to give names to your binding expressions is incredibly helpful for making templates more readable.

Other types of restrictions like "you can't make a @let variable for something only used once" or "only put @let variables in certain places" seem better enforced by linters rather than designed in restrictions.

danielglejzner · 2024-05-21T17:42:25Z

There are only two flavors of constraint I can imagine which are reasonable to apply:

limit @let to the top of a scope

make @let itself a block that declares a scope

There is no difference functionally between these options, and this kind of constraint would not prevent the case of "many variables at the top of the template". It would only add friction to using @let.

I do think having many variables at the top is not necessarily a code smell. Expression aliases are not "logic" - you can't do anything with them that you couldn't do in a binding. In that sense, the ability to give names to your binding expressions is incredibly helpful for making templates more readable.

Other types of restrictions like "you can't make a @let variable for something only used once" or "only put @let variables in certain places" seem better enforced by linters rather than designed in restrictions.

I have no more arguments :) thanks for the discussion.

yjaaidi · 2024-05-24T15:59:29Z

I have two questions about @let and signals:

when local change detection (at view level) will land, will @let create a computed signal or a function or something similar under the hood to be able to track changes at view level?
while @let is a good workaround for signal type narrowing, it will not cancel the work on signal type narrowing in the template right?
feat(compiler-cli): enable narrowing of signal reads in templates #55456

yjaaidi · 2024-05-24T16:00:29Z

Did someone let https://github.com/let know that they will get spammed a lot? 🙃

JoostK · 2024-05-24T17:14:49Z

while @let is a good workaround for signal type narrowing, it will not cancel the work on signal type narrowing in the template right?
feat(compiler-cli): enable narrowing of signal reads in templates #55456

We're still aiming to support narrowing, regardless of @let.

^{By using backticks around @let you avoid mentioning folks :-)}

@let

Enables the new `@let` syntax by default. `@let` declarations are defined as: 1. The `@let` keyword. 2. Followed by one or more whitespaces. 3. Followed by a valid JavaScript name and zero or more whitespaces. 4. Followed by the `=` symbol and zero or more whitespaces. 5. Followed by an Angular expression which can be multi-line. 6. Terminated by the `;` symbol. Example usage: ``` @let user = user$ | async; @let greeting = user ? 'Hello, ' + user.name : 'Loading'; <h1>{{greeting}}</h1> ``` Fixes angular#15280.

HyperLife1119 · 2024-07-11T02:57:29Z

I wonder if they will consider supporting object/array destructuring syntax in the future :)

@let { a, b } = object
@let [a, b] = array

angular-automatic-lock-bot · 2024-08-12T00:10:14Z

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

IgorMinar added area: core Issues related to the framework runtime feature Issue that requests a new feature labels Mar 20, 2017

trotyl mentioned this issue Sep 25, 2017

ngIf, number values and 0 #19364

Closed

mischkl mentioned this issue Oct 2, 2017

Support assigning expression result to local variable within templates #2451

Closed

ngbot bot added this to the Backlog milestone Jan 23, 2018

sanbornsen mentioned this issue Aug 7, 2018

feat(common): ng-let directive is added to store async value locally #25351

Closed

3 tasks

ibarsi mentioned this issue Aug 14, 2018

feat(common): ngLet directive #25472

Closed

8000 3 tasks

mauriziocescon mentioned this issue May 23, 2024

feat(content projection): component inputs accepting arrow functions returning ng-templates #56056

Closed

abdulkareemnalband mentioned this issue May 28, 2024

Directly Importing Template Dependencies in HTML Templates #56125

Open

JoostK mentioned this issue Jun 6, 2024

Improve template null check for used signals in templates #56303

Closed

crisbeto mentioned this issue Jun 26, 2024

feat(core): add support for let syntax #56715

Closed

dylhunn closed this as completed in 0a48d58 Jun 26, 2024

angular-automatic-lock-bot bot locked and limited conversation to collaborators Aug 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Template Local Variables #15280

Template Local Variables #15280

Template Local Variables #15280

Template Local Variables #15280

Comments