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

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#

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

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.