There's quite good doc of using *ngIf in Angular: https://angular.io/api/common/NgIf But, is that possible to have *ngIf async variable and multiple checks on that? Something like:
<div *ngIf="users$ | async as users && users.length > 1">
...
</div>
Of course, it's possible to use nested *ngIf, like:
<div *ngIf="users$ | async as users">
<ng-container *ngIf="users.length > 1">
...
</ng-container>
</div>
but it'd be really nice to use only one container, not two.
Simply do it like this
<div *ngfor="let user of users$ | async" *ngIf="(users$ | async)?.length > 1">...</div>
For "more complex" scenario do the following
<div *ngfor="let user of users$ | async" *ngIf="(users$ | async)?.length > 1 && (users$ | async)?.length < 5">...</div>
Edit: Previous wouldn't work since you cannot use *ngFor and *ngIf without using ng-template. You would do it like that for instance
<ng-template ngFor let-user [ngForOf]="users$ | async" *ngIf="(users$ | async)?.length > 1 && (users$ | async)?.length < 5">
<div>{{ user | json }}</div>
</ng-template>
Here is a stackblitz.
I hit the same issue of needing an *ngIf + async variable with multiple checks.
This ended up working well for me.
<div *ngIf="(users$ | async)?.length > 0 && (users$ | async) as users"> ... </div>
or if you prefer
<div *ngIf="(users$ | async)?.length > 0 && (users$ | async); let users"> ... </div>
Explanation
Since the result of the if expression is assigned to the local variable you specify, simply ending your check with ... && (users$ | async) as users allows you to specify multiple conditions and specify what value you want the local variable to hold when all your conditions succeed.
Note
I was initially worried that using multiple async pipes in the same expression may create multiple subscriptions, but after some light testing (I could be wrong) it seems like only one subscription is actually made.
Here's the alternative version, with a little bit cleaner template:
<ng-template [ngIf]="(users$ | async)?.length > 1" [ngIfElse]="noUsersMessage">
<div *ngFor="let user of (users$ | async)">{{ user | json }}</div>
</ng-template>
<ng-template #noUsersMessage>No users found</ng-template>
Note that we use users$ | async 2 times. That will work if you add shareReplay() operator to user$ Observable:
public users$: Observable<any[]> = this.someService.getUsers()
.pipe(shareReplay());
That way, inner template will be able to access last value of the Observable and display the results.
You can try it out on stackblitz.
I see everyone using *ngFor and *ngIf together in one tag and similar work-arounds, but I think that is an anti-pattern. In most regular coding languages, you don't do an if statement and a for loop on the same line do you? IMHO if you have to work around because they specifically don't want you to, you're not supposed to do that. Don't practice what's not "best practice."
✅✅✅ Keep it simple, if you don't need to declare the $implicit value from users$ | async as users:
<!-- readability is your friend -->
<div *ngIf="(users$ | async).length > 1"> ... </div>
But if you do need to declare as user, wrap it.
✅ For Complex Use Case; mind you, the generated markup will not even have an HTML tag, that's the beauty of ng-templates & ng-containers!
@alsami's accepted, edited answer works because *ngFor with asterisk is a shorthand for ng-template with ngFor (no asterisk), not to mention the double async pipe . The code really smells of inconsistency when you combine a no-asterisk ngFor with a *ngIf; you get the gist. The *ngIf takes precedence so why not just wrap it in a ng-container/ng-template? It won't wrap your inner elements using an HTML tag in the generated markup.
<div *ngIf="users$ | async as prods; then thenB; else elseB"></div>
<ng-template #thenB>
<!-- inner logic -->
<div *ngIf="prods?.length > 1 && users?.length < 5; else noMatchB">
Loaded and inbound
</div>
<ng-template #noMatchB>Loaded and out of bound</ng-template>
</ng-template>
<ng-template #elseB>Content to render when condition is false.</ng-template>
❌ Don't do this
<!-- Big NO NO -->
<div *ngIf="(users$ | async)?.length > 1 && (users$ | async)?.length < 5"> ... </div>
Pipes are a bit daunting after you know about their sensitivity to life cycles; they update like mad. That's why Angular do NOT have SortPipe nor FilterPipe. So, erm, don't do this; you're basically creating 2 Observables that sometimes update frantically and may cause long-term data mismatch in its children if I'm correct.
