8000 ngIf improvements for Rx · Issue #13061 · angular/angular · GitHub
[go: up one dir, main page]

Skip to content

ngIf improvements for Rx #13061

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mhevery opened this issue Nov 23, 2016 · 12 comments
Closed

ngIf improvements for Rx #13061

mhevery opened this issue Nov 23, 2016 · 12 comments
Assignees
Labels
area: common Issues related to APIs in the @angular/common package feature Issue that requests a new feature freq3: high

Comments

@mhevery
Copy link
Contributor
mhevery commented Nov 23, 2016

Goals

When writing Rx style code it is often necessary to write code like this

{{ (userObs|async).?lastName}}, {{ (userObs|async).?firstName}}

The issue is that:

  1. every async creates a listener and
  2. the need to use the .? makes coding cumbersome.

What is needed is to be able to subscribe to the observable once and then refer to it in subsequent location. Additionally we need a way to display an alternative template while the observable has not yet yielded a value.

Proposal

  • Allow ngIf to assign data to local value.
  • Add an else feature to ngIf so that an alternative template can be shown until the observable yields a value.
<div *ngIf="userObs | async; else loading; let user">
  {{ user.lastName}}, {{ user.firstName }}
</div>
<template #loading>
  loading...
</template>

NOTE: the microsyntax is consistent with existing implementation of the microsyntax. For expanded form see:

<template [ngIf]="userObs | async" [ngIfElse]="loading" let-user>
  {{ user.lastName}}, {{ user.firstName }}
</template>
<template #loading>
  loading...
</template>
@mhevery mhevery added the area: common Issues related to APIs in the @angular/common package label Nov 23, 2016
@fxck
Copy link
fxck commented Nov 23, 2016

This would be useful in many other places, I wouldn't limit it to ngIf.

@DzmitryShylovich
Copy link
Contributor

Allow ngIf to assign data to local value.

I think it would be better to allow assign result of the async pipe to a local var #12237

@mhevery
Copy link
Contributor Author
mhevery commented Nov 23, 2016

@DzmitryShylovich

I think it would be better to allow assign result of the async pipe to a local var #12237

Pipes are not allowed to do that, and it would not fit with our mental model.

@thelgevold
Copy link
Contributor

I am not a huge fan of this proposal as it "encourages" logic in the templates.

IMHO I think this logic should be resolved in code for better testability/reusability.

In these cases I think it's better to use an object with a default value and manual rx subscription over async pipe(s).

Also, I think it's better to remove the repeated asyncs by moving it to a wrapping ngIf rather than putting it on each individual bound field.

@olegdunkan
Copy link
Contributor

IMHO It's enough

<template [ngIf]="userObs | async" let-user>
  {{ user.lastName}}, {{ user.firstName }}
</template>

I agree with @thelgevold if some directive requires something existing inside templates it source of common pitfalls.
But any way this feature will be very helpful.

@pkozlowski-opensource pkozlowski-opensource added freq3: high feature Issue that requests a new feature labels Nov 24, 2016
@DzmitryShylovich
Copy link
Contributor

Then we should do the same with all other structural directives.

@olegdunkan
Copy link
Contributor
olegdunkan commented Nov 24, 2016

But what will be if we write:

<template [ngIf]="userObs" let-user>
  {{ <user or userObs>.lastName}}, {{ <user or userObs>.firstName }}
</template>

Ambiguous thing could happen, will we use 'user' or 'userObs'? 'async' correlates with let-<name_of_variable>it's also the source of common pitfalls.

@DzmitryShylovich
Copy link
Contributor

@olegdunkan user will be the same as userObs

@olegdunkan
Copy link
Contributor

@DzmitryShylovich ok, aka alias) but it will stay ambiguous.

@kylecordes
Copy link

The notion of a ngIf which captures the value of the expression result and makes it available, has been around a while. I have an implementation of it linked below, but I'm pretty sure I saw another implementation prior to this (about a year ago).

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

It is essentially a blend of ngIf and ngFor, written a long time ago based on a (probably incomplete) understanding of how those things work all the way down.

Somewhere I got the impression that this idea had been considered and rejected, so I'm thrilled to see the core team looking at it again now. Very useful addition.

@mhevery mhevery self-assigned this Dec 7, 2016
@vicb
Copy link
Contributor
vicb commented Dec 8, 2016

@mhevery a little bit off topic but as we have discussed about it, django has a for else

{% for user in users %}
    <li>{{ user.username|e }}</li>
{% else %}
    <li><em>no users found</em></li>
{% endfor %}

mhevery added a commit to mhevery/angular that referenced this issue Dec 9, 2016
NgIf syntax has been extended to support else clause to display template
when the condition is false. In addition the condition value can now
be stored in local variable, for later reuse. This is especially useful
when used with the `async` pipe.

Example:

```
<div *ngIf="userObservable | async; else loading; let user">
  Hello {{user.last}}, {{user.first}}!
</div>
<template #loading>Waiting...</template>
```

Closes angular#13061
@vicb vicb closed this as completed in b4db73d Dec 9, 2016
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: common Issues related to APIs in the @angular/common package feature Issue that requests a new feature freq3: high
Projects
None yet
8 participants
0