Um checklist curto antes de testar zoneless

Zoneless não é só remover zone.js. Em app existente, o trabalho real é descobrir quem avisa o Angular que o estado mudou. Stable desde a v20.2 e default em projetos novos a partir da v21. Em app existente, o spike é outra conversa.

Comece com uma branch, não com uma promessa

Zoneless é a direção do Angular para novas aplicações, mas um app existente pode depender de Zone.js por padrões que nunca foram documentados. Trate a primeira tentativa como spike de compatibilidade.

O primeiro spike não é uma sprint de migração. Ele serve para encontrar telas onde timer, subscription, overlay ou widget de terceiro depende de change detection implícita há anos.

O que inspecionar

ÁreaPergunta
Subscriptions manuaisO código atualiza campos simples sem Signal, AsyncPipe, mudança de input ou markForCheck?
TimersCallbacks de setTimeout ou setInterval alteram dados lidos no template sem notificar o Angular?
APIs de estabilidadeAlgum código espera eventos de estabilidade do NgZone ou usa isStable como gate de runtime?
FormsReactive forms e estados de validação atualizam corretamente em fluxos críticos?
UI de terceirosOverlays, charts, editors e mapas assumem Zone.js?
TestesO setup de testes ainda importa zone.js/testing?
Encontrar pontos prováveis de risco zonelessbash
rg "NgZone|onStable|onUnstable|onMicrotaskEmpty|isStable|ApplicationRef|setTimeout|setInterval|subscribe\(" src
rg "zone.js|zone.js/testing|provideZoneChangeDetection|provideZonelessChangeDetection" .

O que um bom spike deve entregar

Um bom spike de zoneless termina com um relatório curto: fluxos testados, falhas encontradas, dependências que assumem Zone.js, mudanças necessárias e recomendação para adotar, testar mais ou esperar.

Um relatório útil é específico: checkout passou, o overlay do gráfico falhou depois de uma mutação em timer, o pacote de editor ainda assume Zone.js e a correção estimada é mexer em dois componentes ou atualizar uma dependência.

Se a única saída é 'compilou', o spike não respondeu a pergunta de produção. Um time precisa saber o que quebrou, o que nem foi tocado e o que seria caro demais corrigir agora.

Artefato para reaproveitar

Checklist de prontidão para zoneless

  • Crie uma branch isolada.
  • Remova pressupostos de Zone.js apenas dentro do spike.
  • Teste subscriptions manuais, timers, APIs de estabilidade, forms, overlays, charts, editors e mapas.
  • Cheque polyfills de build e teste.
  • Escreva uma recomendação antes de planejar rollout.

Fontes consultadas

Modern Angular Playbook

Este artigo é um play.

O Playbook do Angular Moderno reúne o diagnóstico, a matriz de adoção, onze jogadas e o plano de 30 dias. Grátis, em inglês e português.

Você recebe os dois PDFs por email, pela lista do Dojo IA.

Abrir playbook →

André Ramosdisponível para vagas remotas, UTC−3Entre em contato →

Leia também

Guia · 10 min

O código que quebra quando Angular fica zoneless

Um guia técnico para revisar timers, subscriptions, forms, callbacks de terceiros e testes antes de um spike zoneless no Angular.

Ler artigo →

Erro · 8 min

NG0100 ExpressionChangedAfterItHasBeenCheckedError: por que ele aparece no Angular zoneless

Por que o NG0100 ExpressionChangedAfterItHasBeenCheckedError aparece depois de ir pra zoneless ou Angular 22, o que ele significa agora, a armadilha do fixture.detectChanges() no teste, e os fixes conforme de onde veio a mudança.

Ler artigo →

Guia · 8 min

OnPush é o default no Angular 22: o que quebra e o que fazer

Por que o Angular 22 faz do OnPush o default, o que de fato quebra, os dois jeitos de corrigir, e como os Eager que a migração adicionou servem de backlog de limpeza.

Ler artigo →