---
title: "Como eu adotaria Signal Forms agora que são estáveis no Angular 22"
description: "Um filtro de adoção para Signal Forms agora que são estáveis no Angular 22: use em forms novos, mantenha reactive forms onde já funcionam, e não migre nada por estética."
deck: "Signal Forms saíram de developer preview para [estável no Angular 22](https://angular.dev/events/v22), e o v22 trouxe as peças que faltavam: validators de data, validação async com debounce e `getError` com narrowing de tipo. Isso muda a pergunta de adoção de \"devo arriscar\" para \"onde isso merece o lugar.\" É o filtro que eu usaria."
author: "André Ramos"
url: "https://andreramos.dev/pt/angular/signal-forms-not-my-default-yet/"
lang: "pt-BR"
type: "article"
---

# Como eu adotaria Signal Forms agora que são estáveis no Angular 22

> Signal Forms saíram de developer preview para [estável no Angular 22](https://angular.dev/events/v22), e o v22 trouxe as peças que faltavam: validators de data, validação async com debounce e `getError` com narrowing de tipo. Isso muda a pergunta de adoção de "devo arriscar" para "onde isso merece o lugar." É o filtro que eu usaria.

## O status mudou, e isso muda a pergunta

Por dois releases Signal Forms foram developer preview, e a jogada certa era mantê-los fora de forms de receita. O Angular 22 os tornou estáveis, e isso não é rodapé. Uma API estável é uma em que você pode construir um form de verdade sem apostar numa assinatura que pode mudar embaixo de você.

O v22 também trouxe o que me fazia segurar: validators `minDate` e `maxDate`, validação async com debounce (`validateHttp(field, { debounce: 400 })`), uma opção `when` consistente entre validators, e `getError(kind)` com narrowing de tipo. As lacunas que mandavam um spike de volta pra reactive forms estão, na maior parte, fechadas.

Então a pergunta não é mais "é seguro mexer." É "onde Signal Forms merece o lugar sobre as reactive forms que você já tem."

## Onde cada caminho de forms entra agora

| Situação | Escolha padrão | Motivo |
|---|---|---|
| Um form novo, greenfield | Signal Forms | Estável, signal-native, e os validators do v22 cobrem os casos comuns. |
| Um reactive form que funciona | Deixe quieto | Estável e testado. Estética não é motivo de migração. |
| Um form de receita ou regulatório novo | Signal Forms, com o mesmo rigor | Estável agora; aplique a disciplina usual de validação e rollback. |
| Controles de form customizados | Signal Forms com Angular Aria | Erros de `ControlValueAccessor` agora propagam, e o Aria também é estável. |
| Time novo em Signals | Signals em estado local de UI primeiro | Forms ainda multiplicam conceitos; aprenda a primitiva antes. |

## Adote pro novo, não reescreva por estética

A disciplina que valia pro experimento ainda vale pra API estável, só apontada pro outro lado. Antes, a regra era "teste num lugar seguro." Agora a regra é "use em forms novos, e deixe reactive forms que funcionam quietas."

Uma migração de um reactive form existente pra Signal Forms deve passar na mesma régua de qualquer refactor: nomeie o que melhora (validação, controles customizados, type safety nessa base), não só "é o jeito novo." Se você não consegue nomear o ganho, o reactive form fica.

*Nota de adoção de Signal Forms*

```text
# Nota de adoção de Signal Forms

Form:
Form novo, ou migração de um existente:
O que Signal Forms melhora aqui:
Casos de validação cobertos:
Controles customizados e Aria:
Se migrando, o ganho nomeado sobre a versão reactive:
Decisão: adotar, ou manter o reactive form
```

## Meu default agora

O default virou com o status. Forms novos começam como Signal Forms, porque a API é estável e signal-native e os validators do v22 cobrem o terreno comum. Reactive forms existentes ficam até haver um motivo real pra mexer, e não há campanha de migração, porque uma API estável não exige uma.

Isso não é entusiasmo substituindo disciplina. É a mesma disciplina lendo um fato diferente: a API virou estável, então saiu da coluna de spike pra coluna de default-pra-código-novo.

## Artefato reaproveitável: Filtro de adoção de Signal Forms (Angular 22)

- Use Signal Forms em forms novos; são estáveis no Angular 22.
- Deixe reactive forms que funcionam no lugar; estética não é motivo de migração.
- Para uma migração, nomeie o ganho concreto (validação, controles customizados, type safety) ou mantenha o reactive form.
- Combine controles customizados com Angular Aria, que também é estável agora.

## Fontes consultadas

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

## Leia também

- [OnPush é o default no Angular 22: o que quebra e o que fazer](https://andreramos.dev/pt/angular/onpush-default-angular-22/)
- [Angular 22: o que mudou de verdade, e o que fazer num app em produção](https://andreramos.dev/pt/angular/angular-22-what-changed/)
- [Transformando Signal Forms em tools de agente de IA](https://andreramos.dev/pt/angular/signal-forms-as-ai-agent-tools/)