---
title: "Angular 22: o que mudou de verdade, e o que fazer num app em produção"
description: "Um guia sênior, com olhar de produção, sobre o Angular 22: o padrão OnPush, a estabilização de Signal Forms e das APIs de async signal, as migrações de teste, as mudanças de default menores que te pegam no upgrade, e um plano com critério pra adotar."
deck: "O Angular 22 saiu em [3 de junho de 2026](https://angular.dev/events/v22). No fundo é um release de amadurecimento: Signal Forms, as APIs assíncronas `resource` e `httpResource` e o Angular Aria saíram do experimental e viraram estáveis. Mas tem uma mudança de default que mexe com todo componente do seu app: OnPush agora é o padrão de change detection. Vou destrinchar o que mudou e o que eu faria na prática."
author: "André Ramos"
url: "https://andreramos.dev/pt/angular/angular-22-what-changed/"
lang: "pt-BR"
type: "article"
---

# Angular 22: o que mudou de verdade, e o que fazer num app em produção

> O Angular 22 saiu em [3 de junho de 2026](https://angular.dev/events/v22). No fundo é um release de amadurecimento: Signal Forms, as APIs assíncronas `resource` e `httpResource` e o Angular Aria saíram do experimental e viraram estáveis. Mas tem uma mudança de default que mexe com todo componente do seu app: OnPush agora é o padrão de change detection. Vou destrinchar o que mudou e o que eu faria na prática.

## O que o Angular 22 é de verdade

O Angular 22 chegou em 3 de junho de 2026. Bate o olho na lista de features e parece coisa demais. Mas olha com cabeça de tech lead que tem app em produção e tudo se separa em dois grupos: o que era experimento e virou estável, e os defaults que mudaram.

O que virou estável é opcional. Signal Forms, as APIs assíncronas `resource` e `httpResource` e o Angular Aria agora são estáveis, mas ninguém te obriga a usar. Já as mudanças de default, não: OnPush, `strictTemplates`, o backend Fetch do HttpClient e o incremental hydration passam a valer a não ser que você diga o contrário, e o `ng update` escreve migrações no seu código pra segurar o comportamento antigo.

Então a pergunta que importa no upgrade não é "o que tem de novo". É "quais migrações a CLI acabou de escrever no meu app, e quais eu quero mesmo manter". O resto do guia é responder isso, área por área.

## A mudança que mexe com todo componente: OnPush por padrão

Pra um app que já existe, o que pega é uma linha no changelog: a estratégia padrão de change detection agora é OnPush. Um componente que nunca definiu `changeDetection` rodava eager, checando a cada tick. No v22 esse mesmo componente é OnPush.

O `ng update` não te deixa na mão. Ele escreve `changeDetection: ChangeDetectionStrategy.Eager` nos seus componentes pra nada mudar em runtime. É a jogada segura, e também uma lista de tarefas: cada `Eager` que ele adiciona é um componente que dependia da checagem eager, e um candidato a virar OnPush de verdade com calma.

O que eu faria: deixa os componentes novos serem OnPush, porque o padrão novo é o certo, e trata os `Eager` que a migração adicionou como backlog, não como veredito. Os componentes que quebram quando você tira o `Eager` são os que mudam estado do template sem avisar o Angular, o mesmo tipo de código que aparece quando um app vira [zoneless](/pt/angular/code-that-breaks-when-angular-goes-zoneless). O v22 só deixou a pergunta inevitável.

*O novo default, e o que a migração escreve no código antigo*

```ts
// v22: agora este componente é OnPush por padrão. Sem linha de strategy.
@Component({ selector: 'app-badge', template: '{{ count() }}' })
export class BadgeComponent {
  count = signal(0);   // a escrita do signal marca a view OnPush como suja, então beleza
}

// O que o ng update põe nos seus componentes ANTIGOS pra preservar o eager:
@Component({
  selector: 'app-legacy',
  changeDetection: ChangeDetectionStrategy.Eager,   // adicionado pela migração
  template: '...',
})
export class LegacyComponent {}
```

## As estabilizações: o que virou estável, e se vale adotar

Três coisas saíram do experimental no v22, e a resposta honesta pra "devo adotar" muda de uma pra outra.

Signal Forms é o destaque. Era developer preview no v21, e ser estável muda a conta: código novo já pode usar, e o v22 fechou as lacunas que me deixavam cauteloso antes (validators de data, validação async com debounce, `getError` com narrowing de tipo). Eu mostro [como eu adotaria hoje](/pt/angular/signal-forms-not-my-default-yet), e o resumo é: usa num form novo, mas não sai reescrevendo reactive form que funciona só por isso.

As APIs `resource` e `httpResource` são a camada de dados dos async signals, e também são estáveis. Isso encerra a cautela do [Estado HTTP sem transformar tudo em Signals](/pt/angular/http-state-without-signals-everywhere): o `httpResource` não é mais um experimento pra isolar, é ferramenta que você pode pôr numa leitura de verdade. O Angular Aria também virou estável junto, e agora funciona com Signal Forms, o que faz controle de form acessível deixar de ser um trabalho de construir na mão.

| Feature | Status v21 | Status v22 | O que eu faria |
|---|---|---|---|
| Signal Forms | Developer preview | Estável | Use em forms novos; não reescreva reactive forms que funcionam |
| `resource` / `httpResource` | Experimental | Estável | Use em leituras remotas novas; mantenha RxJS onde streams compõem |
| Angular Aria (`@angular/aria`) | Developer preview | Estável (GA) | Adote pra controles acessíveis customizados |

## Os testes também andaram, e a maior parte a seu favor

Se você migrou testes pro Vitest, o v22 transformou dois workarounds em features suportadas. O `zone.js/plugins/vitest-patch` que mantém o `fakeAsync` vivo agora é o caminho documentado, não um truque. E há schematics novos: uma migração `migrate-karma-to-vitest` faz a troca de runner, e o `refactor-jasmine-vitest` ganhou um flag `--fake-async` que reescreve testes de tempo pra timers nativos do Vitest por você.

Isso não aposenta o trabalho, só muda o formato. O schematic converte os casos mecânicos, mas os [testes com Promise na cadeia ainda precisam de review](/pt/angular/angular-vitest-async-validator-pending), e você ainda tem que decidir [se vale migrar uma suíte](/pt/angular/move-angular-test-suite-to-vitest). O piso ficou mais alto do que estava um release atrás.

*Os schematics de teste do v22*

```bash
# Converte specs Jasmine pra Vitest, com timers nativos pros testes de fakeAsync:
ng generate @schematics/angular:refactor-jasmine-vitest --fake-async --include=src/app
```

## As viradas de default menores que pegam no upgrade

Um punhado de mudanças mais discretas aparece como surpresa se você não souber delas. O HttpClient agora usa o backend Fetch por padrão e o `withFetch()` está deprecado, com a migração tirando ele. O `strictTemplates` vem ligado, então templates que passavam no type-check de forma frouxa podem começar a falhar o build. Incremental hydration é o padrão pra apps SSR. E a toolchain andou: TypeScript 6 é obrigatório, o Node 20 saiu e o Node 26 entrou.

Nenhuma é difícil, mas cada uma é um ponto onde um `ng update` limpo ainda te deixa uma decisão manual. O router tem uma sem migração nenhuma: `paramsInheritanceStrategy` agora tem default `'always'`, o que pode mudar o que uma rota filha lê dos params.

## O que eu faria essa semana

O upgrade em si é `ng update @angular/core @angular/cli`, e aí o trabalho real é ler o que ele escreveu. Rode as migrações, e revise o diff com duas perguntas: quais adições de `Eager` no change detection eu quero manter, e quais remoções de deprecação eu aceito.

Depois do upgrade mecânico, as decisões de adoção são a parte interessante, e são o mesmo filtro disciplinado de sempre: [adote o que é seguro, teste o que não é, deixe código estável quieto](/pt/angular/adopt-spike-wait-angular-21). Signal Forms e `httpResource` estáveis os movem da coluna de spike pra coluna de adotar-em-código-novo, que é exatamente o tipo de mudança que [um plano de modernização](/pt/angular/angular-30-day-modernization-plan) deve absorver sem virar reescrita.

O v22 recompensa quem já estava migrando pra signals aos poucos, e o padrão OnPush sobe sem alarde a régua de higiene de change detection pro resto. É um release pra encarar com calma e critério.

## Artefato reaproveitável: Checklist de upgrade pro Angular 22

- Rode `ng update @angular/core @angular/cli` e deixe os schematics aplicarem as migrações.
- Confirme a toolchain: TypeScript 6, Node 22.22+, 24 ou 26 (Node 20 saiu).
- Revise cada `changeDetection: Eager` que a migração adicionou: cada um é candidato a OnPush, não conclusão.
- Decida sobre o backend Fetch (`withFetch()` foi removido) e sobre as falhas de `strictTemplates` que o build agora mostra.
- Anote o default do router: `paramsInheritanceStrategy` agora é `'always'`, sem migração.
- Trate Signal Forms e `httpResource` como adotar-em-código-novo agora que são estáveis; não reescreva código que funciona por isso.

## Perguntas frequentes

### Quando o Angular 22 foi lançado, e o que ele exige?

O Angular 22 foi lançado em 3 de junho de 2026. Exige TypeScript 6 e Node 22.22+, 24 ou 26; o suporte ao Node 20 foi removido. RxJS 7.4+ continua suportado.

### Qual a maior mudança do Angular 22 pra um app existente?

A estratégia default de change detection agora é OnPush. Um componente sem `changeDetection` explícito é OnPush no v22. O `ng update` preserva o comportamento antigo adicionando `ChangeDetectionStrategy.Eager` nos seus componentes existentes, mas componentes novos são OnPush por default.

### Signal Forms estão estáveis no Angular 22?

Sim. Signal Forms saíram de developer preview pra estável no v22, junto com as APIs de async signal `resource` e `httpResource` e o pacote `@angular/aria`. Estão prontos pra produção, embora adotar siga sendo opcional.

### O Angular 22 mudou algo sobre testes com Vitest?

Sim, a seu favor. O `zone.js/plugins/vitest-patch` que mantém o `fakeAsync` funcionando agora é o caminho documentado, e o v22 adiciona um schematic `migrate-karma-to-vitest` mais um flag `--fake-async` no `refactor-jasmine-vitest` que reescreve testes de tempo pra timers nativos do Vitest.

### Subir pro Angular 22 é arriscado?

A parte mecânica é um `ng update` com migrações automáticas. As decisões são revisar as adições de `Eager` no change detection e as remoções de deprecação como o `withFetch()`. Nada te força a adotar as APIs recém-estáveis, então o risco está mais no que você escolhe mudar depois do upgrade do que no upgrade em si.

## Fontes consultadas

- https://angular.dev/events/v22
- https://angular.dev/reference/versions
- https://angular.dev/guide/forms/signals/overview
- https://angular.dev/guide/signals/resource
- https://angular.dev/guide/zoneless
- https://angular.dev/guide/testing/migrating-to-vitest
- https://blog.ninja-squad.com/2026/06/03/what-is-new-angular-22.0

## Leia também

- [O que adotar, testar ou deixar para depois no Angular 21](https://andreramos.dev/pt/angular/adopt-spike-wait-angular-21/)
- [Como eu adotaria Signal Forms agora que são estáveis no Angular 22](https://andreramos.dev/pt/angular/signal-forms-not-my-default-yet/)
- [Quando migrar uma suíte Angular para Vitest](https://andreramos.dev/pt/angular/move-angular-test-suite-to-vitest/)