Reactive Forms — the FormGroup / FormControl / FormBuilder API — were the right answer for non-trivial Angular forms from v2 through v22. Signal forms (lesson 4.1) are now the right answer for new code. But Reactive Forms are not going away, and tens of thousands of production applications use them. This lesson catalogs Reactive Forms in 2026: when they still fit, what they look like, and the cleanest path to interop with the rest of the modern signal world.

This is lesson 4.2, following lesson 4.1 on signal forms. If you have never seen Reactive Forms, read this for context. If you maintain a codebase that uses them heavily, this lesson is your migration guide.

The shape #

import { Component, inject } from '@angular/core';
import { FormBuilder, FormGroup, Validators, ReactiveFormsModule } from '@angular/forms';

@Component({
  selector: 'app-login',
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="loginForm" (ngSubmit)="submit()">
      <input formControlName="email" />
      @if (loginForm.controls.email.errors?.['required']) { <p>Required</p> }
      @if (loginForm.controls.email.errors?.['email']) { <p>Invalid email</p> }

      <input formControlName="password" type="password" />
      @if (loginForm.controls.password.errors?.['minlength']) { <p>Min 8 characters</p> }

      <button type="submit" [disabled]="loginForm.invalid">Sign in</button>
    </form>
  `,
})
export class LoginComponent {
  private fb = inject(FormBuilder);

  loginForm = this.fb.group({
    email: ['', [Validators.required, Validators.email]],
    password: ['', [Validators.required, Validators.minLength(8)]],
  });

  submit() {
    if (this.loginForm.valid) {
      console.log('Login:', this.loginForm.value);
    }
  }
}

Three core mechanics:

1. FormBuilder.group({...}) creates a typed FormGroup. Keys become control names; values are [initial, validators] tuples.
2. formControlName="email" in the template binds an input to the named control.
3. loginForm.controls.email.errors reads validation state. Always optional-chain (errors?.['required']) because errors is null when valid.

When Reactive Forms still fit #

Four real cases:

1. Legacy codebases (the common case) #

If 90% of your forms are already Reactive, the cost of a wholesale migration is rarely justified. Reactive Forms continue to work, ship in every Angular release, and the API has been stable for years. Maintain them; migrate piece-by-piece when you touch a file.

2. Forms with imperative orchestration #

Reactive Forms have valueChanges and statusChanges Observables that emit on every change. For complex stream-based orchestration — cascading dropdowns where each level depends on the previous, debounced sub-form sync, multi-step transitions — RxJS operators are natural:

this.form.controls.country.valueChanges.pipe(
  switchMap(country => this.http.get<State[]>(`/api/states?country=${country}`)),
  takeUntilDestroyed(this.destroyRef),
).subscribe(states => this.states.set(states));

Signal forms can do this via effects, but the RxJS shape often reads more naturally for stream-shaped logic.

3. Third-party form libraries #

Most form-related Angular libraries (Material's form-field components, ngx-formly, jsonforms-angular) target the Reactive Forms API. Using a signal-form alongside a third-party Reactive-aware library means more glue code than just staying with Reactive Forms.

4. Dynamic forms generated from schemas #

Reactive Forms have addControl, removeControl, setControl for runtime mutation. Signal forms cover this too, but the patterns are more mature on the Reactive side. JSON-schema-driven forms typically use Reactive.

The API surface #

Three primitives:

Built via constructors or via FormBuilder (preferred for terser syntax):

// Constructor style
this.form = new FormGroup({
  email: new FormControl('', { validators: [Validators.required] }),
});

// FormBuilder style — same result, less typing
this.form = this.fb.group({
  email: ['', [Validators.required]],
});

For brand-new code that has to use Reactive Forms (matching a legacy codebase), prefer the FormBuilder style and use the nonNullable flag for stronger typing (lesson 4.6).

Reading values and state #

this.form.value;                      // { email: 'x', password: 'y' } — only enabled controls
this.form.getRawValue();              // includes disabled controls
this.form.controls.email.value;       // single control value
this.form.controls.email.errors;      // null OR { required: true, email: true }
this.form.valid;                      // boolean
this.form.invalid;                    // boolean
this.form.dirty;                      // boolean
this.form.touched;                    // boolean
this.form.pristine;                   // boolean
this.form.statusChanges;              // Observable<'VALID'|'INVALID'|'PENDING'|'DISABLED'>
this.form.valueChanges;               // Observable<{ email, password }>

Writing values #

this.form.setValue({ email: 'a@b.c', password: 'pw' });   // must include ALL fields
this.form.patchValue({ email: 'a@b.c' });                   // partial — leaves others alone
this.form.reset();                                          // back to initial
this.form.reset({ email: 'default@x.com', password: '' });   // reset to specific values
this.form.controls.email.setValue('new@x.com');             // single control

The setValue vs patchValue distinction is a frequent bug source — setValue requires every field, patchValue accepts a subset. Use patchValue for partial updates.

Validators — built-in and custom #

import { Validators } from '@angular/forms';

// Built-in
Validators.required
Validators.email
Validators.minLength(8)
Validators.maxLength(80)
Validators.min(0)
Validators.max(120)
Validators.pattern(/^[A-Z]{2}$/)

// Compose multiple
Validators.compose([Validators.required, Validators.minLength(8)])

Custom validators are functions that take a FormControl and return { errorKey: any } | null:

function asciiOnly(c: AbstractControl): { ascii: boolean } | null {
  return /^[\x00-\x7f]*$/.test(c.value) ? null : { ascii: true };
}

email = new FormControl('', [Validators.required, asciiOnly]);

Cross-field validators #

Applied at the group level:

function passwordsMatch(g: AbstractControl): { mismatch: boolean } | null {
  const pw = g.get('password')?.value;
  const confirm = g.get('confirmPassword')?.value;
  return pw === confirm ? null : { mismatch: true };
}

this.form = this.fb.group({
  password: [''],
  confirmPassword: [''],
}, { validators: passwordsMatch });

The error lands on this.form.errors?.['mismatch'], not on individual controls.

Async validators #

For server-side validation:

import { AsyncValidatorFn } from '@angular/forms';

uniqueUsername: AsyncValidatorFn = (c: AbstractControl) =>
  this.http.get<{ taken: boolean }>(`/api/check?name=${c.value}`).pipe(
    map(r => r.taken ? { taken: true } : null),
  );

username = new FormControl('', {
  validators: [Validators.required],
  asyncValidators: [uniqueUsername],
});

The control's pending status is true while the async validator runs. UI shows a spinner:

@if (form.controls.username.pending) { <p>Checking...</p> }

Unlike signal forms, async validators do NOT auto-debounce. You typically wrap with debounce from the RxJS pipeline, OR check valueChanges.pipe(debounceTime(300)) before validation.

Reading reactive forms as signals — toSignal #

The cleanest bridge to the signal world is toSignal(form.valueChanges):

import { toSignal } from '@angular/core/rxjs-interop';

formValue = toSignal(this.form.valueChanges, { initialValue: this.form.value });
formValid = toSignal(this.form.statusChanges.pipe(map(s => s === 'VALID')), { initialValue: this.form.valid });

Now template bindings can read formValid() instead of form.valid, and computeds/effects can react to form changes. Tests can read the signal directly.

This bridge works in either direction — Reactive Forms power the existing UI, signals power the new derived state.

Migrating Reactive Forms to Signal Forms #

Three-step process per form:

1. Replace FormBuilder.group({...}) with form({...}) — same shape, just a different builder
2. Replace Validators.X with X() — Validators.required → required(), Validators.minLength(n) → minLength(n)
3. Replace formControlName="x" template syntax with [value]="f.x().value()" (input)="f.x().value.set(...)" — the most verbose part of the migration

The verbosity of step 3 is real. Most migrating teams write a small <sig-input> wrapper directive once and use it everywhere — turns step 3 into a one-line per field.

Common gotchas #

What's next #

Lesson 4.3 covers template-driven forms — the simplest era, still useful for prototypes. Lesson 4.4 covers validation patterns in depth (sync, async, cross-field). Lesson 4.5 walks file uploads with progress. Lesson 4.6 closes Module 4 with typed reactive forms (the FormGroup<T> strict mode).

Try it yourself #

A reactive form with toSignal bridge:

import { Component, inject, computed } from '@angular/core';
import { FormBuilder, Validators, ReactiveFormsModule } from '@angular/forms';
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-search-form',
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="form">
      <input formControlName="q" placeholder="Search" />
    </form>
    <p>Searching for: "{{ query() }}" ({{ query().length }} chars)</p>
  `,
})
export class SearchFormComponent {
  private fb = inject(FormBuilder);
  form = this.fb.group({ q: ['', Validators.required] });
  query = toSignal(this.form.controls.q.valueChanges, { initialValue: '' });
}

Reactive form drives the UI; the toSignal bridge gives you signal-shaped consumption everywhere else.

Lesson 4.3 picks up template-driven forms — the simplest era, useful for one-off prototypes.