Template Local Variables

[kylecordes]

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

[DzmitryShylovich]

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

you can create such directive yourself

[kylecordes]

@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]

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

[DzmitryShylovich]

@mlc-mlapis yeap

[ddavid67]

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]

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]

@tinchou you can map empty array to null

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

[Modellium]

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 functionnality. And this hack reaches its limit when you need to use a falsy value from your local variable.

[pkt-zer0]

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

[mischkl]

Also discussed in some depth in #2451