Built-in @while Control Flow Block

Start by comparing the proposed @while semantics with Angular's existing @for, @if, @switch, and @let control-flow entry points, and review issue #61292's @repeat alternative. Done requires an agreed syntax and loop-safety model, plus an implementation plan and tests; this RFC names no files or test targets.

RFC: Built-in @while Control Flow Block

Summary

Introduce a @while (or conditionally-based @repeat) control flow block to Angular templates. This block will allow developers to iterate based on a condition evaluated at runtime, removing the strict requirement of providing an Iterable (as currently required by @for).

Motivation

The introduction of the new built-in control flow (@if, @for, @switch) in Angular v17 was a massive leap forward for Developer Experience (DX) and performance. However, @for strictly requires an Iterable. While this covers 95% of use cases (iterating over arrays), it introduces significant boilerplate and memory overhead for the remaining 5%, forcing developers to adapt their data structures purely to satisfy the template engine.

There are two major pain points with the current @for implementation:

1. The "Dummy Array" Anti-Pattern (Memory Overhead)

When a developer needs to render a purely visual repetition (e.g., 5 star icons for a rating, 10 skeleton loaders, or pagination numbers), they are forced to allocate memory for a "dummy array" in the component class.

// Component polluted with UI-only structural data
skeletonItems = new Array(10);
// OR
stars = Array.from({length: 5});

This violates the Separation of Concerns (the TS component shouldn't allocate data structures just for UI repetition) and creates unnecessary work for the Garbage Collector (heap allocation for empty arrays).

2. Flattening Non-Linear Data Structures (O(N) Complexity)

When dealing with non-linear structures like Linked Lists, Trees, or ASTs (e.g., rendering a Breadcrumb by traversing node = node.parent, or reading a cursor-based pagination), developers cannot use @for directly. They are forced to write a "flattening" method in the component to convert the linked structure into a flat array.
This results in O(N) time and space complexity just to prepare the data before the rendering even begins.

Proposed Syntax

We propose a @while block that evaluates a condition and provides an optional step expression (to prevent infinite loops), similar to the mental model of a traditional for or while loop.

@let currentNode = activeCategory;
@while (currentNode !== null; step: currentNode = currentNode.parent) {
  <span class="breadcrumb">{{ currentNode.name }}</span>
}

Or for simple repetitions (working hand-in-hand with the new @let syntax):

@let i = 0;
@while (i < skeletonCount; step: i = i + 1) {
  <app-skeleton />
}

Real-World Use Cases

Use Case 1: Pure UI Repetition (Skeleton Loaders)

Render N items without allocating a dummy array.

<div class="skeleton-container">
  @let count = 0;
  @while (count < 10; step: count = count + 1) {
    <div class="skeleton-card"></div>
  }
</div>

Use Case 2: Linked Data Traversal (Breadcrumbs / Comments Thread)

Traversing a linked list directly in the template without flattening it in TypeScript.

<div class="breadcrumbs">
  @let node = leafNode;
  @while (node !== null; step: node = node.parent) {
    <a [routerLink]="node.url">{{ node.label }}</a>
  }
</div>

Use Case 3: Time / Calendar Generation

Generating time slots or calendar days without pre-instantiating 30 Date objects in an array.

@let currentDate = startDate;
@while (currentDate < endDate; step: currentDate = addDays(currentDate, 1)) {
  <div class="calendar-day">{{ currentDate | date:'shortDate' }}</div>
}

Alternatives Considered

1. Using Generators with @for

It is technically possible to pass a Generator function to @for today.

// Inside the component
*generateStars(n: number) { for(let i=0; i<n; i++) yield i; }

Why it's insufficient: It is highly unergonomic (poor DX). Forcing developers to write Generator functions in their TS class just to render 3 UI elements is a significant regression in developer experience compared to native loop constructs.

2. A simple @repeat(n) block (Issue #61292)

There is a community request for a @repeat(n) block which would solve the "Dummy Array" problem.
Why it's insufficient: While @repeat(n) is great for skeletons, it completely ignores the Linked List / Cursor traversal use cases. A @while block is a much more powerful and versatile primitive that solves both problems without expanding the API surface too much.