Control Flow Is Not Just Cleaner Syntax

Cleaner is not enough#

I like the new control flow because it reduces template gymnastics, but 'cleaner syntax' is not a strong enough reason to open a broad migration. In a mature app, I want the change to expose a real UI decision: loading, error, empty, ready, identity, or a finite state.

That framing keeps the migration useful. A touched template can become easier to review without turning the whole codebase into a syntax campaign.

What each block should prove#

The list identity decision#

@for forcing track is not busywork. It makes the team decide how the DOM should relate to data. That matters for rows with inputs, focus, animations, and repeated components with internal state.

If the backend gives you a stable id, use it. If it does not, ask whether the UI is hiding a modeling problem. Falling back to object identity or index can be acceptable for static lists, but it should not be the default for dynamic product data.

I would push back on track $index for a sortable or filterable product list. It can preserve the wrong row state when the order changes, which is exactly the kind of bug a syntax migration should not introduce.

@for (order of filteredOrders(); track $index) {
  <app-order-row [order]="order" />
}

@switch (ordersState()) {
  @case ('loading') {
    <app-orders-skeleton />
  }
  @case ('empty') {
    <app-empty-orders />
  }
  @case ('ready') {
    @for (order of orders(); track order.id) {
      <app-order-row [order]="order" />
    }
  }
}

A migration I would accept#

I would accept a control flow PR when the team is already touching the screen and the diff improves one of three things: a clearer state model, a correct track decision, or a useful empty/fallback state.

I would push back on a repo-wide PR that only changes syntax. The code may compile, but the review cost is real and the product learned nothing.