Control flow não é só sintaxe mais limpa

Limpo não basta#

Eu gosto do control flow novo porque ele reduz malabarismo de template, mas 'sintaxe mais limpa' não é motivo forte para abrir uma migração ampla. Em app maduro, eu quero que a mudança exponha uma decisão real de UI: loading, erro, vazio, pronto, identidade ou estado finito.

Esse recorte mantém a migração útil. Um template já tocado pode ficar mais fácil de revisar sem transformar a base inteira em campanha de sintaxe.

O que cada bloco deve provar#

A decisão de identidade da lista#

@for exigir track não é burocracia. Ele força o time a decidir como o DOM se relaciona com os dados. Isso importa para linhas com inputs, foco, animação e componentes repetidos com estado interno.

Se o backend entrega um id estável, use. Se não entrega, pergunte se a UI está escondendo um problema de modelagem. Usar identidade do objeto ou index pode servir para listas estáticas, mas não deveria ser o default para dados dinâmicos de produto.

Eu questionaria track $index em uma lista de produto que pode ser ordenada ou filtrada. Ele pode preservar estado na linha errada quando a ordem muda, que é exatamente o tipo de bug que uma migração de sintaxe não deveria introduzir.

@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" />
    }
  }
}

Uma migração que eu aceitaria#

Eu aceitaria um PR de control flow quando o time já está mexendo na tela e o diff melhora uma de três coisas: modelo de estado mais claro, decisão correta de track ou estado vazio/fallback útil.

Eu questionaria um PR no repositório inteiro que só troca sintaxe. O código pode compilar, mas o custo de review é real e o produto não aprendeu nada.