Modern Angular
O que adotar, testar ou deixar para depois no Angular 21
Angular 21 (lançado em novembro/2025) traz padrões sólidos para projetos novos. Apps existentes em produção pedem outro critério, especialmente com a v22 já no calendário oficial de releases pra junho/2026.
Adotar
Se eu entrasse em um projeto Angular amanhã, não começaria mudando o app inteiro. Em código novo ou em trechos que já vão mudar, eu adotaria componentes standalone-first, control flow moderno, Signals locais para estado atual de UI, computed para derivação síncrona e takeUntilDestroyed para subscriptions manuais.
Essas mudanças deixam a base mais parecida com o Angular atual sem pedir que o time aposte o produto em uma onda de migração.
Use um filtro de decisão
Este post não deveria repetir o guia amplo de modernização. A função dele é dar ao reviewer um filtro rápido antes que uma release note vire ticket de migração.
Eu faria estas perguntas antes de transformar qualquer ideia em default do time.
| Critério | Adotar | Testar | Esperar ou isolar |
|---|---|---|---|
| Impacto em runtime | Local e previsível | Muda timing ou renderização do app | Toca fluxos críticos com comportamento instável |
| Impacto no CI | Sem runner ou build model novo | Precisa de dados comparativos | Tornaria falhas mais difíceis de confiar |
| Maturidade da API | Estável e documentada | Estável, mas sensível à arquitetura | Experimental ou developer preview |
| Custo de rollback | Diff pequeno em código já tocado | Branch pode ser abandonada | Rollback afetaria escopo de release |
| Evidência necessária | Code review e smoke test | Timebox, responsável, métricas e falhas | Mudança de status oficial ou prova local mais forte |
Testar
Teste zoneless em app existente, migração para Vitest em suíte grande de Karma/Jasmine, mudanças de SSR/hydration e tooling de IA com ng mcp. Nada disso deveria nascer como ticket genérico de limpeza. Cada frente precisa de hipótese, timebox, responsável, caminho de rollback e evidência no app real: fluxos quebrados, delta no CI, specs instáveis ou achados de review.
Se esse filtro virar política do time, registre em ADR ou ticket: item, status, evidência, responsável e próxima revisão. Isso é registro de decisão, não código de aplicação.
| Item | Status | Evidência necessária |
|---|---|---|
| Control flow em templates já alterados | Adotar | Diff revisado com @if, @for e uso correto de track. |
| Estado local de componente com Signals | Adotar | Menos boilerplate sem substituir contratos assíncronos. |
| Zoneless em app existente | Testar | Relatório de smoke test para timers, subscriptions, forms, overlays e UI de terceiros. |
| Migração de suíte grande para Vitest | Testar | Comparação no CI para specs migradas, fake timers, mocks e testes dependentes de browser. |
| Signal Forms ou Angular Aria em fluxos críticos | Esperar ou isolar | Status da API checado na documentação oficial e sem dependência em fluxo crítico de release. |
Esperar ou isolar
Mantenha Signal Forms e Angular Aria longe de fluxos críticos até o time ganhar confiança suficiente na superfície atual da API. Signal Forms está marcada como experimental na documentação oficial: 'The API may change in future releases. Avoid using experimental APIs in production applications without understanding the risks.' Angular Aria está em developer preview no roadmap.
Minko Gechev (líder do Angular team) esboçou a direção de interop no post Angular 2025 Strategy: forms existentes continuam funcionando enquanto Signal Forms é gradualmente recomendado como best practice. Esse 'gradualmente' é a porteira. O risco não é serem ideias ruins. O risco é mudança de API, complexidade de forms, responsabilidade de acessibilidade e telas críticas virando laboratório de adoção precoce.
Artefato para reaproveitar
Adotar / testar / esperar
- Adotar: padrões estáveis que melhoram código novo ou trechos que já vão mudar.
- Testar: mudanças que afetam runtime, CI, renderização, workflow ou custo de rollback.
- Esperar: APIs experimentais ou developer preview em fluxos críticos.
- Promova um spike só depois de existir responsável, timebox, evidência e caminho de rollback.
Fontes consultadas
- https://angular.dev/roadmap
- https://angular.dev/reference/releases
- https://angular.dev/guide/components
- https://angular.dev/guide/signals
- https://angular.dev/guide/templates/control-flow
- https://angular.dev/guide/zoneless
- https://angular.dev/guide/forms/signals/overview
- https://angular.dev/guide/aria/overview
- https://angular.dev/api/core/computed
- https://angular.dev/api/core/rxjs-interop/takeUntilDestroyed
- https://blog.angular.dev/announcing-angular-v21-57946c34f14b
- https://blog.angular.dev/angular-2025-strategy-9ca333dfc334
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.
André Ramosdisponível para vagas remotas, UTC−3Entre em contato →