--- title: "O que adotar, testar ou deixar para depois no Angular 21" description: "Uma matriz curta de adoção para recursos modernos do Angular, escrita para times com apps existentes e risco real de release." deck: "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](https://angular.dev/reference/releases) pra junho/2026." author: "André Ramos" url: "https://andreramos.dev/pt/angular/adopt-spike-wait-angular-21/" lang: "pt-BR" type: "article" --- # 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](https://angular.dev/reference/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](https://angular.dev/guide/components), [control flow moderno](https://angular.dev/guide/templates/control-flow), [Signals locais](https://angular.dev/guide/signals) para estado atual de UI, [`computed`](https://angular.dev/api/core/computed) para derivação síncrona e [`takeUntilDestroyed`](https://angular.dev/api/core/rxjs-interop/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](https://angular.dev/guide/forms/signals/overview) e [Angular Aria](https://angular.dev/guide/aria/overview) longe de fluxos críticos até o time ganhar confiança suficiente na superfície atual da API. Signal Forms está [marcada como experimental](https://angular.dev/guide/forms/signals/overview) 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](https://angular.dev/roadmap). Minko Gechev (líder do Angular team) esboçou a direção de interop no post [Angular 2025 Strategy](https://blog.angular.dev/angular-2025-strategy-9ca333dfc334): 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 reaproveitável: 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 ## Leia também - [Angular moderno para times em produção](https://andreramos.dev/pt/angular/modern-angular-production-teams/) - [Signals sem briga com RxJS](https://andreramos.dev/pt/angular/signals-without-rxjs-war/) - [Um checklist curto antes de testar zoneless](https://andreramos.dev/pt/angular/zoneless-checklist/)