---
title: "Angular moderno para times em produção"
description: "Três documentos que o time concorda, as perguntas pra fazer antes de aprovar uma PR de modernização, e como dizer 'a gente não tá adotando isso ainda' sem soar conservador."
deck: "Modernização sem wait list é campanha. Com wait list, sequência. Cinco Angular majors em 30 meses entre v16 e v21. Os três documentos que tiram um time em produção do arrasto para a entrega, com um review gate que aguenta trinta segundos."
author: "André Ramos"
url: "https://andreramos.dev/pt/angular/modern-angular-production-teams/"
lang: "pt-BR"
type: "article"
---

# Angular moderno para times em produção

> Modernização sem wait list é campanha. Com wait list, sequência. Cinco Angular majors em 30 meses entre v16 e v21. Os três documentos que tiram um time em produção do arrasto para a entrega, com um review gate que aguenta trinta segundos.

## A decisão que você realmente toma no PR review

Cinco Angular majors caíram entre v16 (maio/2023) e v21 (novembro/2025), conforme a [referência oficial de releases](https://angular.dev/reference/releases). Essa cadência funciona quando o time tem referência escrita sobre o que adotar, testar em spike, ou explicitamente esperar. Sem essa referência, toda PR de modernização reabre o mesmo debate.

Você é quem aprova as PRs de modernização num time Angular 16-21 em produção (tech lead, arquiteto técnico, ou a sênior que o time consulta). Uma PR cai na sua fila: feature nova usando Signals pra estado local. Você tem trinta segundos. Aprova, devolve ou escala?

Boa parte do ruído de modernização vive nesses trinta segundos. O framework não para de soltar versão. O time não para de propor adoção. Você aprova ou empurra de volta sem referência escrita. Três trimestres depois, metade do código parece Angular 16 e a outra metade parece Angular 21, e ninguém sabe explicar o split.

Três documentos que o time concorda antes de qualquer proposta de modernização entrar em discussão absorvem boa parte dessa pressão. A lista de padrões aprovados como default. A lista de padrões em spike. A lista de padrões explicitamente esperando.

## Três listas que o time deve manter

Cada lista responde a uma pergunta de review diferente.

| Lista | Mora em | Revisar quando |
|---|---|---|
| Default pra código novo | Lint rules e style guide | Em todo Angular major |
| Candidatas a spike | ADR por feature | Quando o spike fecha |
| 'Explicitamente esperando' | Log trimestral de decisões | Trimestralmente, ou quando o status muda |

## O que entra em cada lista

A primeira lista é o 'sim'. Componentes novos vão [standalone](https://angular.dev/guide/components), estado local vai pra [Signals](https://angular.dev/guide/signals), control flow usa [`@if`/`@for`/`@switch`](https://angular.dev/guide/templates/control-flow), injeção de dependência usa [`inject`](https://angular.dev/api/core/inject). Codificado no linter pra PR review não re-discutir a decisão.

RxJS continua default pra streams genuinamente assíncronos (autocomplete com debounce, WebSocket, polling, cancelamento). Signals substitui estado local que antes vivia em BehaviorSubject. Os dois não competem; eles respondem perguntas diferentes.

A segunda lista é o 'talvez, em branch'. [Zoneless](https://angular.dev/guide/zoneless) em app existente (stable desde v20.2, default em projetos novos a partir da v21, mas remover Zone.js dum legacy ainda é spike). Vitest pra suite grande. SSR/hydration em rota pública. Cada uma ganha uma ADR escrita (contexto, hipótese, critério de validação, plano de rollback) antes de qualquer código tocar a main.

A terceira lista é a que a maioria dos times pula. Features que parecem modernas, soam modernas, e ainda não cabem em fluxo crítico de produção.

Em junho de 2026, a wait list acabou de provar o valor dela. [Signal Forms](https://angular.dev/guide/forms/signals/overview), as APIs [rxResource](https://angular.dev/api/core/rxjs-interop/rxResource) e resource, e o [Angular Aria](https://angular.dev/guide/aria/overview) estavam nela até a v21, e o [v22 (junho/2026)](https://angular.dev/events/v22) graduou os três pra estável, que é exatamente o trigger que a lista existe pra capturar: eles saem de 'esperando' pra 'adotar em código novo'. O que continua na lista agora é a superfície de runtime de IA, tipo o WebMCP, que ainda é experimental e não cabe em billing, compliance ou qualquer fluxo que você não consiga reverter fácil.

A wait list não é 'contra' essas features. É 'ainda não, e aqui está o trigger que tiraria da lista'. Recheque a cada Angular major.

*Template curto de ADR pra um spike*

```text
# ADR: spike Vitest no package de orders

Status: proposta
Contexto: suite de testes de orders (~280 specs) roda em 4m20s no Karma; time relata flaky failures em torno de fakeAsync.
Decisão: migrar 1 slice do módulo pra Vitest, medir runtime, estabilidade de CI e custo de migração. Nenhum código de produção tocado.
Escopo: orders/specs apenas. Outros packages intactos.
Fora de escopo: mudar padrões de teste de componente, substituir TestBed.
Riscos: dependências escondidas de Zone.js em helpers compartilhados; diferenças de paralelismo no CI.
Validação: runtime, taxa de flake (janela de 7 dias), revisão da diff de migração pelo time.
Rollback: reverter o package; manter ADR pra próxima tentativa.
```

## A lista 'explicitamente esperando' merece mais cuidado que as outras duas

Em três bases Angular que ajudei a modernizar entre 2023 e 2026, a lista que esses times nunca tinham era a terceira. Tinham defaults. Tinham spikes. Não tinham registro escrito do que tinham decidido não adotar ainda, nem o porquê.

Um time que documentou o que adota é um time que pensou em modernização. Um time que documentou o que está explicitamente esperando é um time que decidiu.

Sem essa terceira lista, toda PR de modernização vira debate do zero (pq ninguém sabe o que já foi decidido). Com ela, a pergunta de review fica específica: 'a PR propõe Signal Forms pro form de cobrança, mas a wait-list marcou Signal Forms como developer preview. O que mudou no status da API?'

A lista não precisa ser longa. Três a cinco features por vez basta. Cada entrada precisa de (1) o que a gente não tá adotando, (2) por quê (status, raio de impacto, custo de dependência), (3) o trigger que tiraria a feature da lista.

## Como comunicar 'a gente não tá adotando isso ainda' sem soar conservador

Liderança sênior frequentemente escuta 'a gente tá esperando Signal Forms' como 'a gente tá atrasado'. Isso é problema de tradução, não de estratégia.

O reframe: modernização sem wait list é campanha. Modernização com wait list é sequência. Sequência entrega; campanha se arrasta.

Frases específicas que funcionaram nas minhas reviews: 'A gente escalonou a adoção pra acompanhar o track record da API em produção.' 'A gente está adiando X até ver como interage com a arquitetura de forms.' 'A direção do framework é correta; o estado atual (experimental, developer preview) ainda não cabe nos nossos fluxos críticos.'

Essas frases nomeiam a disciplina e dão um lugar pra conversa upstream parar.

## Quando revisar cada lista

Review por calendário falha porque o framework não respeita calendário. Review por trigger funciona.

Quando o Angular team comunica adoção, tende a comunicar com dado de produção. No [anúncio do v20](https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301), Minko Gechev (líder do Angular team) destacou que o YouTube reduziu input latency em 35% no Living Room usando Angular Signals com Wiz. Um time que mantém a wait-list aprende a ler esse tipo de sinal antes de promover features para 'default'.

Triggers que vale ligar ao seu processo:

| Trigger | Lista pra revisar | Por que |
|---|---|---|
| Novo Angular major (v22, v23) | Todas as três | Defaults, status labels e deprecations podem mudar |
| Track record em produção (6+ meses numa API experimental) | Explicitamente esperando | Candidata direta a promoção |
| Mudança de capacidade do time | Candidatas a spike | Ajustar orçamento de experimento |
| Bug crítico em uma API 'default' | Default pra código novo | Rebaixar, documentar, comunicar |

## O ponto

Pra um time em produção, o que sobrevive a um Angular major são as decisões que você escreveu, onde elas moram, e como o time encontra essas decisões às 21h de uma sexta quando um release manager pergunta 'a gente tá usando Signal Forms em billing ou não?'.

## Artefato reaproveitável: Perguntas de review-gate pra uma PR de modernização

- A qual das três listas o padrão dessa PR pertence?
- Se reivindica 'default', isso tá no linter?
- Se é spike, onde tá a ADR com hipótese, validação e rollback?
- Se a API tá na lista 'explicitamente esperando', o que mudou no status dela?
- Se nenhum dos casos acima, qual lista essa PR deveria estar estabelecendo?

## Fontes consultadas

- 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/api/core/rxjs-interop/rxResource
- https://angular.dev/guide/aria/overview
- https://angular.dev/api/core/inject
- https://blog.angular.dev/announcing-angular-v21-57946c34f14b
- https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301
- https://github.com/angular/angular/discussions/49685
- https://github.com/angular/angular/discussions/50719

## Leia também

- [O que adotar, testar ou deixar para depois no Angular 21](https://andreramos.dev/pt/angular/adopt-spike-wait-angular-21/)
- [Standalone sem transformar NgModules em vilões](https://andreramos.dev/pt/angular/standalone-without-ngmodule-dogma/)
- [Facade Pattern no Angular: quando o componente sabe demais](https://andreramos.dev/pt/angular/facade-pattern-in-angular/)