Introduction

In Angular templates, *ngIf conditionally renders part of the DOM, and the else clause lets you render an alternate template when the condition is false. It is a clean way to switch between loading, empty, and ready states without filling the component class with manual DOM logic.

Basic *ngIf else Syntax

The classic pattern uses an element with *ngIf and an ng-template for the fallback:

1<div *ngIf="user; else guestTemplate">
2  Welcome, {{ user.name }}
3</div>
4
5<ng-template #guestTemplate>
6  <p>Please sign in.</p>
7</ng-template>

If user is truthy, Angular renders the div. If not, Angular renders the guestTemplate.

The key idea is that else does not point to another component. It points to a named template reference.

Practical UI States

*ngIf else becomes most useful when a view has two explicit states such as:

• logged in or logged out
• data loaded or still loading
• item exists or item missing

A loading example is a common pattern:

1<section *ngIf="products.length; else loadingTemplate">
2  <ul>
3    <li *ngFor="let product of products">
4      {{ product.name }}
5    </li>
6  </ul>
7</section>
8
9<ng-template #loadingTemplate>
10  <p>Loading products...</p>
11</ng-template>

This keeps the template readable because the alternate view is named and isolated.

Using then and else Together

Angular also supports an explicit then and else form. That can be helpful when both branches are substantial and you want neither one inline.

1<ng-container *ngIf="isAdmin; then adminTemplate else userTemplate"></ng-container>
2
3<ng-template #adminTemplate>
4  <p>Admin dashboard</p>
5</ng-template>
6
7<ng-template #userTemplate>
8  <p>Standard dashboard</p>
9</ng-template>

This style is useful when the true branch is large enough that inlining it would clutter the template.

Keep Logic in the Component, Not the Template

A common anti-pattern is putting too much decision logic inside *ngIf. The directive is best when the expression is easy to read.

Prefer this:

export class UserPanelComponent {
  readonly isReady = true;
}

1<div *ngIf="isReady; else waitingTemplate">
2  Ready
3</div>
4
5<ng-template #waitingTemplate>
6  Waiting...
7</ng-template>

Over this:

<div *ngIf="user && user.permissions && user.permissions.includes('ADMIN') && !isLoading; else waitingTemplate">
  Ready
</div>

The second version works, but it pushes too much logic into the template. Move complex checks into a component property or computed getter so the UI stays understandable.

*ngIf else Versus Modern @if

In modern Angular, the new built-in control-flow syntax such as @if and @else is becoming the newer style. However, *ngIf else is still common in existing codebases and remains important to understand.

So if you see:

1@if (user) {
2  <p>Welcome {{ user.name }}</p>
3} @else {
4  <p>Please sign in.</p>
5}

That is conceptually the same kind of conditional rendering. The syntax is newer, but the template idea is similar. If you are maintaining older Angular templates or learning from existing projects, *ngIf else is still worth knowing well.

A Full Example With Async Data

Here is a realistic component that shows a loading message until data arrives:

1import { Component, OnInit } from '@angular/core';
2
3@Component({
4  selector: 'app-orders',
5  templateUrl: './orders.component.html',
6})
7export class OrdersComponent implements OnInit {
8  orders: string[] = [];
9  loaded = false;
10
11  ngOnInit(): void {
12    setTimeout(() => {
13      this.orders = ['A-100', 'A-101'];
14      this.loaded = true;
15    }, 1000);
16  }
17}

1<div *ngIf="loaded; else loadingTemplate">
2  <ul>
3    <li *ngFor="let order of orders">
4      {{ order }}
5    </li>
6  </ul>
7</div>
8
9<ng-template #loadingTemplate>
10  <p>Loading orders...</p>
11</ng-template>

This is a straightforward pattern for asynchronous screens because it keeps loading UI and ready UI clearly separated.

Common Pitfalls

The most common pitfall is trying to put the fallback content directly inside the else clause instead of using an ng-template reference.

Another mistake is stuffing complex business logic into the *ngIf expression. The template becomes harder to debug and harder to read.

A third issue is forgetting that *ngIf adds or removes elements from the DOM rather than merely hiding them with CSS. That affects component lifecycle and view state.

Finally, some developers mix *ngIf else and newer @if syntax without team conventions. Pick a style that fits the codebase and use it consistently.

Summary

• '*ngIf="condition; else templateRef" renders alternate content when the condition is false.'
• The fallback must be an ng-template identified by a template reference.
• Use then and else together when both branches are large.
• Keep template conditions readable by moving complex logic into the component.
• Modern Angular also offers @if, but *ngIf else remains common and useful.