¿Signal Forms o Reactive Forms? El árbol de decisión que te quita la duda

¿Qué son Signal Forms?

Signal Forms es el nuevo modelo de formularios de Angular basado en Signals. En lugar de FormControl y Observable, el estado del formulario — valor, validez, errores — vive en signals que el template lee directamente. El resultado es código más corto, sin subscribe, sin async pipe y sin ChangeDetectorRef.

// Reactive Forms (hoy)
const form = new FormGroup({
  email: new FormControl('', Validators.required),
});
form.valueChanges.subscribe(v => console.log(v));

// Signal Forms (nuevo)
const form = signalForm({
  email: signalInput('', required()),
});
form.value(); // signal — sin subscribe

Diferencias clave frente a Reactive Forms

• Estado síncrono y legible: form.value(), form.valid(), form.errors() son signals. Puedes leerlos en cualquier momento sin suscribirte a nada.
• Sin valueChanges ni statusChanges: Con Reactive Forms necesitas un Observable para reaccionar al valor. Con Signal Forms, computed() o effect() cubren ese caso con menos código.
• Integración nativa con el template: El template lee signals directamente: {{ form.value().email }}. Sin async pipe ni unwrap manual.
• Validadores como funciones puras: Los validadores son funciones simples que reciben el valor y devuelven errores, sin depender de AbstractControl.

Cuándo usar Signal Forms

• Formularios nuevos en proyectos con Signals: Si ya usas Signals en tu app, Signal Forms encaja de forma natural. El modelo mental es consistente y el código más corto.
• Formularios simples o medianos: Login, registro, filtros, preferencias de usuario. Cualquier formulario sin validadores asíncronos complejos ni integración con librerías de terceros.
• Cuando quieres eliminar subscribe del componente: Si tu componente actual tiene valueChanges.pipe(debounceTime, takeUntil) solo para reaccionar al valor, Signal Forms lo resuelve con effect() en dos líneas.

Cuándo quedarte con Reactive Forms

• Validadores asíncronos con lógica compleja: Si tu validador hace llamadas HTTP encadenadas, usa switchMap o necesita retry — esa lógica sigue siendo más cómoda en RxJS con asyncValidators.
• Integraciones con librerías de terceros: ng-select, Angular Material form fields y muchas otras librerías asumen FormControl. Migrar implica parchar la integración, no solo el formulario.
• Bases de código grandes ya establecidas: Migrar formularios complejos con 20+ controles, validación cruzada y lógica de negocio acoplada tiene un coste real. Evalúa el ROI antes de empezar.
• API aún en evolución: Aunque Signal Forms ya es estable en Angular v22, sigue siendo una API joven. En producción con SLA alto, migra primero formularios simples y deja los formularios críticos para una segunda fase.

Las 3 preguntas del árbol de decisión

• ¿Tienes validadores asíncronos con RxJS complejo?: Sí → quédate en Reactive Forms. No → sigue al paso 2.
• ¿Usas librerías de terceros que dependen de FormControl?: Sí → quédate en Reactive Forms o abstrae la integración. No → sigue al paso 3.
• ¿El proyecto ya usa Signals y puedes migrar por fases?: Sí → Signal Forms es tu opción. No → empieza por formularios nuevos antes de tocar código legacy.

Qué incluye exactamente la guía

La guía no intenta venderte una migración total. Está pensada para una revisión rápida antes de tocar un formulario: miras el tipo de validación, las dependencias del UI kit, el coste de convivencia y decides si migrar ahora, esperar o crear un adapter.

• Árbol de decisión imprimible: Tres preguntas para decidir si un formulario es candidato a Signal Forms, si debe quedarse en Reactive Forms o si necesita una capa de compatibilidad.
• Checklist de riesgo: Validadores async, FormArray complejo, librerías que esperan FormControl, lógica de negocio en valueChanges y pruebas que dependen de statusChanges.
• Plan de migración incremental: Empieza por formularios nuevos o pantallas internas, mide fricción del equipo y deja los formularios críticos para cuando el patrón esté probado.

Signal Forms vs Reactive Forms

• Signal Forms: Encaja mejor cuando el estado del formulario se lee directamente en el template, hay poca lógica RxJS y ya estás usando signals en el resto del componente.
• Reactive Forms: Sigue siendo la opción fuerte cuando tienes integraciones maduras, validadores async complejos, formularios dinámicos grandes o flujos ya estabilizados en producción.
• La regla práctica: No compares APIs por novedad. Compara el coste de migrar, el riesgo de integración y la claridad que gana el equipo después del cambio.

No migres todavía si...

• El formulario es crítico para ingresos: Checkout, pago, alta de clientes o formularios con SLA alto no deberían ser el primer experimento. Migra primero una pantalla de bajo impacto.
• Tu UI kit depende de AbstractControl: Si varios componentes esperan FormControl, la migración real no está en el formulario: está en adaptar todo el ecosistema alrededor.
• No tienes tests de comportamiento: Antes de cambiar la API del formulario, captura validaciones, mensajes de error, estados disabled y envíos. Sin esa red, cualquier migración se vuelve frágil.

El primer formulario candidato para migrar

El mejor candidato no es el más visible ni el más complejo. Es un formulario pequeño, con pocas dependencias externas, validación local y una pantalla que el equipo pueda revisar sin presión.

type MigrationCandidate = {
  controls: 'few' | 'many';
  asyncValidation: boolean;
  thirdPartyControls: boolean;
  businessCritical: boolean;
};

const canStartWithSignalForms = (form: MigrationCandidate) =>
  form.controls === 'few' &&
  !form.asyncValidation &&
  !form.thirdPartyControls &&
  !form.businessCritical;