Brian Treese

How to Get Specific Validation Errors with Angular Signal Forms

Thu, 09 Apr 2026 00:00:00 +0000

If you’ve ever tried to build something like a password checklist in Signal Forms, you’ve probably run into a frustrating limitation. You need to know if a specific validation rule failed, but the errors API doesn’t make that easy. And if you try to rely on error indexes, things can break pretty quickly as errors come and go. This post walks through how Angular v22 gives us a simple fix for this with the new getError() function.

A Password Checklist with Angular Signal Forms

Here we have a simple sign-up form with a username and password field:

For the password field, we have a list of requirements:

One uppercase letter
One number
One special character
And at least 8 characters

As we add each required piece to the password, the UI updates letting us know each requirement has been met:

We’re going to implement this specific functionality using the Signal Forms API.

The tricky part here is that this UI isn’t just showing errors, we need to track each rule individually.

Why Error Indexes Break in Angular Signal Forms

The validators on this form look like this:

protected form = form(this.model, s => {
  // ...
  minLength(s.password, 8);

  // Password must include at least one number
  validate(s.password, ({ value }) => {
  	if (!/\d/.test(value())) {
  	  return { kind: 'missingNumber' };
  	}
  	return null;
  });

  // Password must include at least one uppercase letter
  validate(s.password, ({ value }) => {
    if (!/[A-Z]/.test(value())) {
      return { kind: 'missingUppercase' };
    }
    return null;
  });

  // Password must include at least one special character
  validate(s.password, ({ value }) => {
    if (!/[^A-Za-z0-9]/.test(value())) {
      return { kind: 'missingSpecialChar' };
    }
    return null;
  });
});

There are four validators on the password field:

The first is the minLength validator
The second is a custom validator that checks for a number
The third is a custom validator that checks for an uppercase letter
And the fourth is a custom validator that checks for a special character

To make this concept work, we need to bind a valid class on each list item when its specific validation error does not exist.

One way we might try to do this is by accessing the form field, then using the errors array to get the validator by index:

<ol>
  <li [class.valid]="!form.password().errors()[2]">
    One uppercase letter
  </li>
  <!-- ... -->
</ol>

We’ll access the password field from the form, then use the errors array to grab a validator by index.

In this case, the minlength was first, the missing number was second, and this error was third

Arrays are zero-based, so we’ll go with an index of 2.

If we save and look at this in the browser, already we can see we have a problem:

Notice the minLength error isn’t showing up yet.

That’s because the field is currently empty, and minLength only triggers when there’s actually a value.

This means that the index of 2 that we used for our uppercase error is already incorrect.

If I click into the password field and add an uppercase character, watch what happens:

The uppercase error is removed from the array, and the minLength error is added.

The order of the array completely changes!

The problem is that the errors array isn’t stable.

It changes based on which validators are currently failing.

So not only is this fragile, it’s fundamentally the wrong way to model this UI.

But, luckily we’ve got more options!

Using errors().find() to Check Validation Rules

At this point, you might think “okay, I’ll just search the array.”

Let’s switch to the find() method instead where the kind equals missingUppercase.

<ol>
  <li [class.valid]="!form.password().errors().find(e => e.kind === 'missingUppercase')">
    One uppercase letter
  </li>
  <!-- ... -->
</ol>

Now this explicitly looks for the error with the kind we care about, regardless of its position in the array.

After saving, if I click into the field and type an uppercase letter, you can see this worked correctly:

The uppercase letter requirement is properly colored and checked.

So this works, but now we’re scanning the entire error array every time we want to check a single rule.

It gets repetitive, and it doesn’t really match what we’re trying to do.

Well, in Angular 22, there’s going to be an even better way!

Angular 22: Using getError() for Clean Validation Checks

Now, with reactive forms, we had a feature that allowed us to do this pretty easily.

We would set this up using the hasError() function:

<ol>
  <li [class.valid]="!signUpForm.controls.password.hasError('missingUppercase')">
    One uppercase letter
  </li>
  <!-- ... -->
</ol>

It’s pretty clean, readable, and it explicitly checks for the error we want.

Well, in Angular 22, we’re getting something very similar for signal forms.

Instead of scanning the entire array every time, Angular 22 introduces a new getError() function.

Now we can directly ask: “does this specific error exist?”

Which is exactly what this UI needs.

<ol [class.dirty]="form.password().dirty()">
  <li [class.valid]="!form.password().getError('missingUppercase')">
    One uppercase letter
  </li>
  <li [class.valid]="!form.password().getError('missingNumber')">
    One number
  </li>
  <li [class.valid]="!form.password().getError('missingSpecialChar')">
    One special character
  </li>
  <li [class.valid]="!form.password().getError('minLength') && form.password().value()">
    At least 8 characters
  </li>
</ol>

Much cleaner, right?

One important detail, Signal Forms can have multiple errors with the same kind, and getError() will only return the first one.

Also, for the minLength requirement, this rule is a little different.

We only want to evaluate it once the user has actually entered something.

If we leave that off, we could add an 8-character value, then completely delete it, and the requirement would still show as satisfied.

The Final Result

Let’s try it out:

And there we go! Each item is now properly checked off as each requirement is met.

This is the key idea: instead of working with the entire error list, we’re working with individual validation states.

Why getError() Makes Signal Forms Easier to Use

So getError() brings Signal Forms much closer to the ergonomics we had with hasError() in reactive forms, but with a more flexible error model.

And when you’re building UIs like this, where each validation rule matters individually, it makes a big difference.

Get Ahead of Angular’s Next Shift

Most Angular apps today still rely on the old reactive or template-driven forms, but that’s starting to shift.

Signal Forms are new, and not widely adopted yet, which makes this a good time to get ahead of the curve.

I created a course that walks through everything in a real-world context if you want to get up to speed early: 👉 Angular Signal Forms: Build Modern Forms with Signals

Additional Resources

Angular 22's New Built-in Debounce for Async Validation Explained

Thu, 02 Apr 2026 00:00:00 +0000

If you're using Signal Forms with async validation, you've probably run into a frustrating issue. You either debounce every validator with the debounce() function, or you end up hitting your API on every keystroke. Neither is great, but Angular 22 fixes this in a really clean way. This post walks through how the new built-in debounce works and why it makes Signal Forms even better.

The Problem: Debouncing Delays All Validators

When building forms with async validation, we want to wait for the user to stop typing before hitting the API.

Here we can type really slowly without triggering any validation or pending messages while validators are running:

We’re waiting for the user to stop typing before we run our validation.

Once we stop, the validator fires and shows us a pending message:

But in this case, the username “test” already exists, so now we see our error message:

The email field works the exact same way:

We get a pending message while validation is running, followed by an error message if the email is registered.

The Old Way: Field-Level Debounce

Here is how this form is currently wired up using Angular’s Signal Forms API.

We have a model signal holding the state for our sign up form, and a form declaration.

protected model = signal<SignUpForm>({
  username: '',
  email: '',
});

protected form = form(this.model, s => {
  required(s.username, {message: 'A username is required'});
  required(s.email, {message: 'An email address is required'});
  email(s.email, {message: 'Please enter a valid email address'});

  validateAsync(s.username, {
    ...
  });
  debounce(s.username, 2000);

  ...
}

But here’s the catch, this standalone debounce function applies to the entire field.

That means it debounces all validators, even synchronous ones like required() or minLength().

And this is an issue because it can delay instant feedback for simple checks just to accommodate our async call.

The same applies to validateHttp() on the email field:

protected form = form(this.model, s => {
  ...

  validateHttp(s.email, {
    ...
  });
  debounce(s.email, 2000);
}

We define our request and handlers, and then we have to tack on the debounce function at the end.

The New Way: Validator-Level Debounce

With Angular 22, we have a better approach available.

The Angular team added a new debounce option directly into the validation functions.

Angular 22 Fix: Built-in Debounce for Async Validators

So, we can delete the old debounce function call from and instead, inside validateAsync() and validateHttp(), we can just add the debounce property directly:

protected form = form(this.model, s => {
  ...
  validateAsync(s.username, {
    debounce: 2000,
    ...
  });
  // debounce(s.username, 2000);

  validateHttp(s.email, {
    debounce: 2000,
    ...
  });
  // debounce(s.email, 2000);
}

That’s it!

Before, debounce was applied at the field level.

Now it’s applied at the validator level.

This is important because async validation is fundamentally different from synchronous validation.

It’s network-bound, not CPU-bound.

So it should be controlled independently.

The Final Result

Now, synchronous validators can fire instantly, but our async check waits for the debounce just like the original example:

We see the pending message just like we used to, and then we get our validation error message.

Our async logic works the same, but we’re no longer holding up the rest of the validators tied to this control.

Why This Makes Signal Forms Better

So the key shift here is simple, debounce is no longer a field-level concern, it’s a validator-level concern.

That means better UX, cleaner code, and no more tradeoffs between responsiveness and API calls.

If you’re building complex forms in large enterprise apps, this small change reduces boilerplate and keeps your validation logic co-located with the validator where it belongs.

Get Ahead of Angular’s Next Shift

Most Angular apps today still rely on the old reactive or template-driven forms, but that’s starting to shift.

Signal Forms are new, and not widely adopted yet, which makes this a good time to get ahead of the curve.

I created a course that walks through everything in a real-world context if you want to get up to speed early: 👉 Angular Signal Forms: Build Modern Forms with Signals

Additional Resources

Angular 22: Mix Signal Forms and Reactive Forms Seamlessly

Thu, 26 Mar 2026 00:00:00 +0000

What if you could start using Signal Forms today without touching your existing Reactive or Template-driven forms at all? In Angular 22, you'll be able to build Signal-based custom form controls that drop right into your existing forms with no massive rewrites required. This post walks through how to migrate a custom control from ControlValueAccessor to FormValueControl while keeping the parent form completely intact.

Reactive Forms Setup with a Custom Control

Here, we have a simple cart form with a quantity control, a coupon code, an email field, and a gift wrap checkbox.

This form is currently built using standard Reactive Forms.

The quantity control is actually a custom form control built using ControlValueAccessor.

If we click the plus and minus buttons, the value of our form updates correctly:

And if we go under 1 item, it triggers our validation and we see the error message appear:

Everything works, but the underlying ControlValueAccessor implementation is incredibly verbose.

Let’s look at the code so you can see what I mean.

The Old Way: How ControlValueAccessor Works in Angular

Let’s start with the code for the parent form component.

In the template, we have a formGroup directive that wraps all of our form controls:

<form class="cart-form" novalidate [formGroup]="form">
    ...
</form>

Within this form group, our custom app-quantity-stepper component is wired up using the standard formControlName directive as well:

<app-quantity-stepper id="qty" formControlName="quantity" />

All the other fieds use the same formControlName directive too.

Now let’s switch and look at the component TypeScript.

First, we have the interface for our form, strongly typing everything with FormControls:

import { ..., FormControl } from '@angular/forms';

interface CartForm {
    quantity: FormControl<number>;
    couponCode: FormControl<string>;
    email: FormControl<string>;
    giftWrap: FormControl<boolean>;
}

Then we have the FormGroup itself:

import { FormControl, FormGroup, ReactiveFormsModule, Validators } from '@angular/forms';

protected form = new FormGroup<CartForm>({
    quantity: new FormControl(1, {
        nonNullable: true,
        validators: [Validators.min(1)],
    }),
    couponCode: new FormControl('', { nonNullable: true }),
    email: new FormControl('', {
        nonNullable: true,
        validators: [Validators.required, Validators.email],
    }),
    giftWrap: new FormControl(false, { nonNullable: true }),
});

The quantity form control is initialized to 1 and set as non-nullable with a minimum value validator of 1.

That’s why, once we went below a quantity of one, we saw our validation error.

This is a pretty standard Reactive Forms setup.

The complexity is actually hiding inside that custom stepper component.

Why ControlValueAccessor Is So Verbose

First, we have this providers array:

import { ..., forwardRef } from '@angular/core';
import { ..., NG_VALUE_ACCESSOR } from '@angular/forms';

providers: [{
    provide: NG_VALUE_ACCESSOR,
    useExisting: forwardRef(() => QuantityStepperComponent),
    multi: true
}],

We have to provide NG_VALUE_ACCESSOR and use forwardRef just to tell Angular that this component can act as a form control.

Our class then implements the ControlValueAccessor interface:

import { ..., ControlValueAccessor } from '@angular/forms';

export class QuantityStepperComponent implements ControlValueAccessor {
    // ...
}

Inside the class we have a private value signal to hold the state, a public value property to expose it for use in the form, and an isDisabled Boolean property too:

private _value = signal(1);
value = this._value;
isDisabled = false;

After this, we implement empty onChange and onTouched callbacks, and wire up writeValue, registerOnChange, registerOnTouched, and setDisabledState:

private onChange: (v:number)=>void = () => {};

private onTouched: ()=>void = () => {};

writeValue(v: number | null): void {
    this._value.set(v ?? 1);
}

registerOnChange(fn: (v:number)=>void) { 
    this.onChange = fn; 
}

registerOnTouched(fn: ()=>void): void { 
    this.onTouched = fn; 
}

setDisabledState(disabled: boolean): void { 
    this.isDisabled = disabled; 
}

Pretty much none of this is your actual business logic.

It’s mostly all just needed due to the fact that this is a custom control built with ControlValueAccessor.

Finally, in our increment and decrement functions, we update our internal signal.

But we also have to manually call onChange so the parent form knows about it:

protected increment() { 
    this._value.update(v => { 
        const n = v + 1; this.onChange(n); return n;
    });
}

protected decrement() { 
    this._value.update(v => { 
        const n = v - 1; this.onChange(n); return n; 
    });
}

That’s a lot of stuff, right?

And this is a fairly simple example, I’ve certainly seen much more complex custom controls in my experience working with Angular.

Replace ControlValueAccessor with FormValueControl

Now, imagine we are tasked with updating this quantity stepper component to use Signal Forms.

We don’t want to rewrite the parent cart component yet, because maybe it’s a massive, complicated form.

Well, with the upcoming release of Angular v22, we will be able to do exactly that!

With Signal Forms, migrating this component is incredibly easy.

We can completely delete the providers array, the private value signal, and all of those ControlValueAccessor methods.

Instead of ControlValueAccessor, we’ll implement the new FormValueControl interface, and we’ll type it to a number.

import { ChangeDetectionStrategy, Component, input, model } from '@angular/core';
import { FormValueControl } from '@angular/forms/signals';

@Component({
    selector: 'app-quantity-stepper',
    templateUrl: './quantity-stepper.component.html',
    styleUrl: './quantity-stepper.component.scss',
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export class QuantityStepperComponent implements FormValueControl<number> {
    value = model(1);
    isDisabled = input(false);

    protected increment() { 
        this.value.update(v => v + 1);
    }

    protected decrement() { 
        this.value.update(v => v - 1); 
    }
}

When you implement this interface, instead of requiring a bunch of methods, Angular now expects a single “value” model() signal for the value of the control.

We also changed our isDisabled property to an input initialized to false.

We don’t need to call onChange anymore, so all we need to do now is update the signal value in our increment and decrement functions.

That’s the entire component class now!

Next, we need to switch over to the parent cart component and make some massive, complicated changes to the parent form so it can talk to this new signal-based control…

Just kidding!

Yeah, we’re not doing that.

In Angular 22, we won’t have to make any changes to intermix custom FormValueControls with classic Reactive Forms or Template-Driven Forms.

Let’s save and test it out!

The Final Result

To start, our form looks exactly the same, so that’s good:

And after adjusting the quantity, the value of our Reactive Form is updating correctly in real time, now driven by our Signal-based child control:

Then if I go under 1 item again, it triggers the Reactive Forms validation, and our error message still works perfectly:

So, this is still a Reactive Form, but the control itself is now fully signal-based.

Key Takeaway: Migrate to Signal Forms Without Rewriting Everything

Angular 22 allows Signal-based custom controls to work seamlessly with existing Reactive and Template-Driven Forms, no parent form changes required.

We simply continue to use our existing parent form with FormGroup, FormControl, and the formControlName directive, and it just works.

Angular automatically bridges Signal Forms and Reactive Forms for you, meaning you can modernize your large applications one component at a time!

Get Ahead of Angular’s Next Shift

Most Angular apps today still rely on ControlValueAccessor for custom form controls, but that’s starting to shift.

Signal Forms are new, and not widely adopted yet, which makes this a good time to get ahead of the curve.

I created a course that walks through everything in a real-world context if you want to get up to speed early: 👉 Angular Signal Forms: Build Modern Forms with Signals

Additional Resources

Angular’s New debounced() Signal Explained

Thu, 19 Mar 2026 00:00:00 +0000

Every Angular developer has faced it, an input that spams the backend with every single keystroke. The classic solution involves pulling in RxJS and using debounceTime, but it requires converting signals to observables and thinking in streams. As of Angular v22, there’s a new, cleaner way. The new experimental debounced() signal primitive lets you solve this problem in a more declarative, signal-native way. This post walks through the old way and then refactors it to the new, showing you exactly how to simplify your async data-fetching logic.

The Problem: Too Many API Requests

Let’s start with a simple product search app:

It looks fine on the surface, but the real story is in the Network tab:

As you type a search term you can see a new HTTP request firing for each character typed.

In a real-world application, this is a ton of unnecessary load on your backend and can create a jumpy, unpleasant user experience.

This is the classic problem we need to solve.

The Old Way: Debouncing with RxJS `debounceTime`

Our initial component uses a mix of signals and RxJS.

We have a query signal that holds the search term, which is converted to an observable using toObservable.

The products are then loaded inside a toSignal block that pipes the query observable through several RxJS operators:

private http = inject(HttpClient);
protected readonly query = signal('');
private readonly $query = toObservable(this.query);

protected readonly products = toSignal(
  this.$query.pipe(
    distinctUntilChanged(),
    switchMap(query =>
      query
        ? this.http.get(/* ... */).pipe(
            map(res => ({ status: 'data' as const, data: res.products })),
            startWith({ status: 'loading' as const, data: [] as Product[] }),
            catchError(() => of({ status: 'error' as const, data: [] as Product[] }))
          )
        : of({ status: 'idle' as const, data: [] as Product[] })
    )
  ),
  { initialValue: { status: 'idle' as const, data: [] as Product[] } }
);

The traditional fix is to add the debounceTime operator to the pipe.

It’s a one-line change that tells RxJS to wait for a pause in emissions (e.g., 1000ms) before letting the value proceed:

this.$query.pipe(
  debounceTime(1000), // Wait for 1 second of silence
  distinctUntilChanged(),
  switchMap(query => /* ... */)
)

This works perfectly:

The network spam stops, and only one request is sent after the user stops typing.

But it forces us into the RxJS world of observables and pipes, even if the rest of our app is signal-first.

What if we could stay in the world of signals?

Well, as of Angular v22, we will be able to!

The New Way: `debounced()` and `resource()` in Angular v22

The Angular team has introduced a new experimental primitive, debounced, and it can work together with resource to solve this exact problem elegantly.

Step 1: Create a Debounced Signal

First, we’ll create a new signal that is a debounced version of our original query signal.

The debounced() function from @angular/core makes this trivial.

import { ..., debounced } from '@angular/core';

// ...
protected readonly query = signal('');
protected readonly debouncedQuery = debounced(this.query, 1000);

That’s it. debouncedQuery is now a read-only signal that will only update its value when the query signal has been stable for 1000 milliseconds.

Step 2: Refactor to Use `resource()`

Next, we’ll completely replace our toSignal implementation with the new resource() primitive.

resource is purpose-built for loading asynchronous data from a signal.

We can delete the entire products signal and its toSignal block and replace it with this:

import { ..., resource } from '@angular/core';

// ...
protected readonly products = resource({
  params: () => this.debouncedQuery.value() || undefined,
  loader: ({ params }) => 
    firstValueFrom(
      this.http.get<{ products: Product[] }>(/* ... */)
    ).then(res => res.products),
});

Let’s break this down:

params: A function that returns the current search query from the debounced signal (this.debouncedQuery.value()), or undefined if the query is empty. When this value changes, the resource automatically re-fetches.
loader: A function that receives the resolved params and fetches data using Angular’s HttpClient. Because HttpClient returns an Observable, firstValueFrom() is used to convert it to a Promise. The result is then unwrapped to return just the products array.

The resource primitive automatically manages the loading, error, and data states for us based on the params signal and the loader function’s execution.

Updating the Template for the `resource` API

The new resource primitive has a different template API than our old status-based object.

Instead of checking a status property, we use methods like isLoading() and value().

Our old @switch block gets replaced with a set of @if conditions:

@if (query()) {
  <!-- If there's a search query -->
  @if (products.isLoading()) {
    <!-- Show loading spinner -->
    <div class="state loading">
      <span class="spinner"></span>
      <span>Fetching products…</span>
    </div>
  } @else {
    <!-- Show results -->
    <ul class="results-list">
      @for (product of products.value(); track product) {
        <li class="result-item">
          <div><strong>{{ product.title }}</strong></div>
          <div>{{ product.price | currency }}</div>
        </li>
      }
    </ul>
  }
} @else {
  <!-- If there's no query, show idle state -->
  <div class="state idle">
    Start typing to search products
  </div>
}

We first check if the base query() signal has a value. If not, we show the idle message.
If it does, we then check products.isLoading(). If true, we show the spinner.
Finally, if it’s not loading, we can safely access the data via products.value() and render the results.

The Final Result

With these changes, the application behaves identically to the optimized RxJS version:

Typing in the search box only fires a single API request after the user has stopped typing for a second.

The difference is that our component logic is now almost 100% signal-based.

No toObservable, no .pipe(), no manual subscriptions.

This is a huge step forward for reactivity in Angular, giving us a more declarative, signal-native way to handle one of the most common patterns in web development.

Get Ahead of Angular’s Next Shift

Most Angular apps today still rely on reactive forms, but that’s starting to shift.

Signal Forms are new, and not widely adopted yet, which makes this a good time to get ahead of the curve.

I created a course that walks through everything in a real-world context if you want to get up to speed early: 👉 Angular Signal Forms Course

Additional Resources

Angular Signal Forms: Is FormValueControl Better for Large Forms?

Thu, 12 Mar 2026 00:00:00 +0000

In a recent guide I showed a pattern for building large Angular Signal Forms using reusable form sections. But a common follow-up question kept coming up: Why not just use FormValueControl instead? It sounded like a great idea, so I tried it. In this post you'll see how it works and why I'm not completely convinced it's actually the better approach for this scenario.

The Original Approach

Structuring Large Forms - The field tree approach this post compares against

Angular Signal Forms Demo: Reusable Form Sections

Here’s the form we’re working with:

At the top we have an Account Information section, below that is a Shipping Address section, and finally there’s a Preferences section at the bottom.

The important thing to note is that each of these form sections is its own Angular component.

This makes large forms easier to maintain because each section owns its own UI and logic.

If you’ve ever worked on a giant form component with 300 lines of inputs, you know why this matters.

It also makes these form sections reusable elsewhere in the app as needed.

We also have a debug panel showing the real-time value and status of the form:

Typing in the first name updates the form value immediately:

Now, let’s look at how the original implementation worked.

Building Reusable Angular Signal Forms with Field Tree

In the template for the profile form component, the parent that wires the separate form sections into a single form, we see the three section components:

<form (submit)="onSubmit($event)">
    <app-account-form [form]="form.account" />
    <app-address-form [form]="form.shippingAddress" />
    <app-preferences-form [form]="form.preferences" />
</form>

Each component receives a slice of the form’s field tree through an input called form.

The parent form owns the entire form structure and passes individual sections down to each component.

In the component TypeScript, we first define the interface for our profile form:

import { ..., Account } from '../../account/account-form/account-form.model';
import { ..., Address } from '../../shipping/address-form/address-form.model';
import { ..., Preferences } from '../../account/preferences-form/preferences-form.model';

interface Profile {
    account: Account;
    shippingAddress: Address;
    preferences: Preferences;
}

Each section is typed with an interface exported from the individual components themselves.

Below this, we have our form model signal that holds the state of the entire form:

import { ..., AccountModel } from '../../account/account-form/account-form.model';
import { ..., AddressModel  } from '../../shipping/address-form/address-form.model';
import { ..., PreferencesModel } from '../../account/preferences-form/preferences-form.model';

@Component({
  selector: 'app-profile-form',
    ...,
})
export class ProfileFormComponent {
    readonly model = signal<Profile>({
        account: AccountModel,
        shippingAddress: AddressModel,
        preferences: PreferencesModel
    });

    //...
}

Each section uses a variable to set the initial value.

Since each form is its own reusable component, we store the interface and the initial model value with that component so we can access and maintain it near the component rather than wire it up uniquely in every form it’s used in.

This was one of the key concepts from the previous example.

Below the model signal we create the form itself:

import { ..., buildAccountSection } from '../../account/account-form/account-form.model';
import { ..., buildAddressSection } from '../../shipping/address-form/address-form.model';
import { ..., buildPreferencesSection } from '../../account/preferences-form/preferences-form.model';

@Component({
    selector: 'app-profile-form',
    ...,
})
export class ProfileFormComponent {
    readonly form = form(this.model, s => {
        buildAccountSection(s.account);
        buildAddressSection(s.shippingAddress);
        buildPreferencesSection(s.preferences);
    });

    //...
}

And here’s the other main concept, each section exports a function that defines its validation.

These live with the components themselves, just like the interface and initial values.

That way the parent form can compose them easily without redefining them everywhere the components are used.

Inside a Reusable Angular Form Section Component

In the original implementation, the account form component had an input to take in the account field tree from the parent:

@Component({
    selector: 'app-account-form',
    ...
})
export class AccountFormComponent {
    readonly form = input.required<FieldTree<Account>>();
}

The component expects the parent to pass in the account portion of the form.

In the template, each input is bound using the FormField directive accessing the appropriate field from the input:

<label>
    First Name
    <input type="text" [formField]="form().firstName" />
    <app-validation-errors [fieldState]="form().firstName()" />
</label>
<label>
    Last Name
    <input type="text" [formField]="form().lastName" />
    <app-validation-errors [fieldState]="form().lastName()" />
</label>

Validation errors are shown by passing the control state to a custom validation errors component.

Within each form section component we have a model file that contains three things:

The interface - used to strictly type this section of the form
The initial value object - used when this section is added to the parent form model signal
A validation builder function - takes a schema path tree typed with the section interface and defines required fields, patterns, etc.

For example, the account form model file looks like this:

import { required, SchemaPathTree } from '@angular/forms/signals';

export interface Account {
    firstName: string;
    lastName: string;
}

export const AccountModel: Account = {
    firstName: '',
    lastName: ''
};

export function buildAccountSection(a: SchemaPathTree<Account>) {
    required(a.firstName, { message: 'First name is required' });
    required(a.lastName, { message: 'Last name is required' });
}

The main idea is as much of the form logic as possible lives with the component itself.

Anything needed to wire up the form in the parent is exported from the component so it doesn’t have to be manually recreated everywhere it’s used.

The address and preferences form components are set up the same way.

That was the whole concept.

But now we’re going to try something different.

Refactoring to Angular FormValueControl

Instead of passing field trees into the section components, we can turn each section into a custom form control.

Angular provides an interface for this called FormValueControl.

Let’s start with the account section.

First, we add the interface to the component and type it with our Account interface:

import { FormValueControl } from '@angular/forms/signals';

@Component({...})
export class AccountFormComponent implements FormValueControl<Account> {
    // ...
}

When you implement this interface, Angular expects the component to expose a value model input.

So we replace the old input with a new model input that represents the entire value of the account section:

import { ..., model } from '@angular/core';

@Component({...})
export class AccountFormComponent implements FormValueControl<Account> {
    value = model<Account>(AccountModel);
}

Next, we’ll create a local form using the form() function from the Signal Forms API and move the validation from the model file into this form:

protected form = form(this.value, a => {
    required(a.firstName, { message: 'First name is required' });
    required(a.lastName, { message: 'Last name is required' });
});

At this point the component owns its own validation completely which sounds nice, because the parent form doesn’t have to know anything about the internal fields.

The validation moves out of the model file and into the component.

In the template, we just need to update the bindings to use the local form property instead of the input signal:

Before:

<input type="text" [formField]="form().firstName" />

After:

<input type="text" [formField]="form.firstName" />

The address and preferences form components follow the same pattern.

The address form implements FormValueControl, switches to the value model input, and creates a local form with its validation:

@Component({
    selector: 'app-address-form',
    ...,
})
export class AddressFormComponent implements FormValueControl<Address> {
    value = model<Address>(AddressModel);

    protected form = form(this.value, s => {
        required(s.street, { message: 'Street is required' });
        required(s.city, { message: 'City is required' });
        required(s.state, { message: 'State is required' });
        required(s.zip, { message: 'ZIP code is required' });
        pattern(s.zip, /^\d{5}$/, { message: 'ZIP code must be 5 digits' });
    });
}

The preferences form is simpler because it has no validation:

import { Component, model } from '@angular/core';
import { form, FormField, FormValueControl } from '@angular/forms/signals';
import { Preferences, PreferencesModel } from './preferences-form.model';

@Component({
    selector: 'app-preferences-form',
    ...,
})
export class PreferencesFormComponent implements FormValueControl<Preferences> {
    value = model<Preferences>(PreferencesModel);

    protected form = form(this.value);
}

Once all section components are converted to custom controls, we update the parent form to use them as such.

Connecting FormValueControl to the Parent Signal Form

Since the child components now own their validation, the parent no longer needs to call the build functions.

We can remove those from the form definition.

Before:

protected readonly form = form(this.model, s => {
    buildAccountSection(s.account);
    buildAddressSection(s.shippingAddress);
    buildPreferencesSection(s.preferences);
});

After:

protected readonly form = form(this.model);

Then we need to import the new FormField directive so that we can use it in the template:

import { ..., FormField } from '@angular/forms/signals';

@Component({
    selector: 'app-profile-form',
    ...,
    imports: [
        ...,
        FormField
    ],
})

Then we can update the template to use the FormField directive instead of the old input:

Before:

<form [formRoot]="form">
    <app-account-form [form]="form().account" />
    <app-address-form [form]="form().shippingAddress" />
    <app-preferences-form [form]="form().preferences" />
</form>

After:

<form [formRoot]="form">
    <app-account-form [formField]="form.account" />
    <app-address-form [formField]="form.shippingAddress" />
    <app-preferences-form [formField]="form.preferences" />
</form>

Now, after we save, everything still looks the same:

The debug panel form object is unchanged.

Typing in the first name updates the value, so the custom control is working:

But here’s the problem.

When I click in and blur the last name field, we see the validation error inside the component which is correct:

But in the debug panel, the parent form still says valid:

The parent form has no idea those fields are required.

The validation only exists inside the child form, so the parent doesn’t see it.

In my opinion, this is the biggest drawback of this approach.

The only fix I’ve found isn’t great.

Why Parent Form Validation Breaks with FormValueControl

I had to add validation back within the parent’s builder functions:

export function buildAccountSection(a: SchemaPathTree<Account>) {
    required(a.firstName);
    required(a.lastName);
}

We don’t need the error messages there because they already exist in the form section where they’re displayed.

But now things get awkward, we’re duplicating validation logic.

In the address form it’s worse:

export function buildAddressSection(a: SchemaPathTree<Address>) {
    required(a.street);
    required(a.city);
    required(a.state);
    required(a.zip);
    pattern(a.zip, /^\d{5}$/);
}

We have a regular expression duplicated in two places.

We also need to add the builder functions back into the parent form to wire up this validation:

protected readonly form = form(this.model, s => {
    buildAccountSection(s.account);
    buildAddressSection(s.shippingAddress);
    buildPreferencesSection(s.preferences);
});

After doing that, the form starts out invalid correctly now:

Validation errors show when we blur required fields:

And the form status becomes valid once all data is filled in:

Everything works, but we’ve duplicated validation logic to get there.

Should You Use FormValueControl for Angular Signal Form Sections?

You can absolutely build reusable form sections using FormValueControl, and technically it works.

But for this specific scenario it doesn’t actually simplify things.

We ended up duplicating validation logic so the parent form could still understand the overall validity.

The original approach, passing field tree slices into section components, might still be the cleaner architecture for large forms.

If you’ve found a better way to solve this with FormValueControl, I’d genuinely love to hear it.

Learn Angular Signal Forms in depth

If you’d like to go deeper, I created a full course that walks through building a real Signal Form from scratch.

It covers:

validation patterns
async validation
dynamic forms
custom controls
submission and server errors

You can check it out here: 👉 Angular Signal Forms Course

Additional Resources

Angular 21 Signal Forms: ignoreValidators Explained

Thu, 05 Mar 2026 00:00:00 +0000

What happens if a user clicks submit while your async validator is still checking the server? Do you submit bad data? Block the user? Silently fail? Angular Signal Forms now gives you explicit control over that behavior with the ignoreValidators option. In this guide, we'll walk through all three modes so you can choose the right strategy for your real-world Angular applications.

Angular Signal Forms: Default Submission Behavior with Async Validators

Here we have a simple sign-up form with a username field:

If you type something short, you get a minlength validation error:

When you type something longer, a “checking availability” message appears:

This message comes from an async validator that checks whether the username is already taken.

Here’s the key behavior to understand: If you click the submit button while the async validator is still running, the submit action runs immediately:

You can see this because we log the form value on submission:

It does not wait for the async validator to complete.

Once the async check finishes, we get a validation error letting us know the name is already taken but by then, submission has already happened:

This is the default behavior we’ll modify in this tutorial.

But first, let’s see how the form is configured.

How the Signal Form Is Configured (Template + Submission Logic)

The template uses the new FormRoot directive on the <form> element to connect the native form to the Signal Form model:

<form [formRoot]="form">
    ...
</form>

The text input uses the FormField directive to bind to the username field:

<input
    id="username"
    type="text"
    [formField]="form.username" />

Below the input, we show a “checking availability” message when form.username().pending() is true:

@if (form.username().pending()) {
    <p class="info">Checking availability...</p>
}

This happens while the async validator is running.

We then loop through errors when the field has been touched to show validation errors:

 @if (form.username().touched() && form.username().invalid()) {
    <ul class="error-list">
        @for (err of form.username().errors(); track $index) {
            <li>{{ err.message }}</li>
        }
    </ul>
}

The submit button is disabled during submission and its label changes to “Creating…”:

<button type="submit" [disabled]="form().submitting()"> 
    {{ form().submitting() ? 'Creating…' : 'Create account' }}
</button>

The TypeScript: Model and Validation

In the component, we first define the form model for the form:

interface SignupModel {
	username: string;
}

protected readonly model = signal<SignupModel>({
    username: ''
});

Then we create the form using the form() function and pass in the model.

We also add a required, minlength, and async validators to the username field:

protected readonly form = form(
    this.model, 
    s => {
        required(s.username, { message: 'Please enter a username' });
        minLength(s.username, 3, 
            { message: 'Your username must be at least 3 characters' });
        validateAsync(s.username, {
            params: ({ value }) => {
                const val = value();
                if (!val || val.length < 3) {
                    return undefined;
                }
                return val;
            },
            factory: params =>
                resource({
                    params,
                    loader: async ({ params }) => {
                        const username = params;
                        const available = await this.checkUsernameAvailability(username);
                        return available;
                    }
                }),
            onSuccess: (result: boolean) => {
                if (result === false) {
                    return {
                        kind: 'username_taken',
                        message: 'This username is already taken'
                    }
                }
                return null;
            },
            onError: (error: unknown) => {
                console.error('Validation error:', error);
                return null;
            }
        });
        debounce(s.username, 300);
    },
    ...
);

And then, the third parameter to this form is an options object where we handle submission:

{
    submission: {
        action: async form => {
            console.log('Form Value:', form().value());
            await new Promise(resolve => setTimeout(resolve, 1500));
        }
    }
}

This submission object defines an action that runs when submission is allowed.

This action only runs if the form permits it, and by default, it runs even when async validators are still pending.

Validation errors can appear after submission has already happened.

Is that what you want in a real application? Sometimes yes, if you want a responsive feel and you’re okay validating after submission.

Often you need stricter behavior, and until now there was no control over this.

But now, the ignoreValidators option changes that.

ignoreValidators: ‘pending’ - Default Async Submission Behavior Explained

The new ignoreValidators option determines how validator state affects whether submission is allowed.

Inside the submission configuration is where you control how validator state affects whether submission is allowed.

The three possible values are pending, none, and all.

With ignoreValidators: 'pending', you can still submit while async validators are running.

{
    submission({
        ignoreValidators: 'pending',
        ...
    });
}

After saving, you’ll notice that the form still submits while the async validator is still running:

This is because pending is the default behavior.

Adding it explicitly doesn’t change behavior, but it can make the intent clear in your codebase.

Use this when: You want a fast, responsive experience and don’t want to block on async checks.

ignoreValidators: ‘none’ - Block Submission Until Validation Completes

When we switch to ignoreValidators: 'none' we get more strict, production-safe behavior:

{
    submission({
        ignoreValidators: 'none',
        ...
    });
}

After saving, you’ll notice that the form does not submit while the async validator is still running anymore:

And it won’t submit once validation finishes if the form is still invalid:

With none, the form respects all validator states.

If a validator is pending, submission waits.

If the form is invalid, submission is blocked.

The user cannot submit until all validation (including async) has completed and the form is valid.

Using onInvalid to Auto-Focus the First Invalid Field

When submission is blocked because the form is invalid, you can improve UX by focusing the first invalid field.

You can add an onInvalid callback to do this:

{
    submission({
        ignoreValidators: 'none',
        onInvalid: (field, detail) => {
            const first = detail.root().errorSummary()?.[0];
            first?.fieldTree()?.focusBoundControl?.();
        }
        ...
    });
}

Now, when the user clicks submit and the form is invalid, onInvalid runs.

We use errorSummary() to get a flat list of fields with errors, grab the first one, and use focusBoundControl() to move focus to it:

This gives users clear feedback about what needs to be fixed.

Use this when: You need strict, production-safe validation and want to prevent invalid or partially validated data from being submitted.

ignoreValidators: ‘all’ - Submit Even When Invalid or Pending

With ignoreValidators: 'all', the form submits regardless of validation state:

{
    submission({
        ignoreValidators: 'all',
        ...
    });
}

In this mode, you can submit with an empty required field, or while an async validator is still running, it essentially ignores the validator state:

Validation still runs and errors still appear, but submission has already occurred.

Use this when: You’re building features like saving drafts, auto-saving, or partial data persistence, not for forms that require full validation before submission.

Choosing the Right ignoreValidators Mode for Real-World Angular Apps

Mode	Behavior	Best For
`pending`	Submit while async validators run; block only on invalid sync state	Fast UX when you’re okay validating after submit
`none`	Block until all validation (sync + async) completes	Production forms that must not submit invalid data
`all`	Submit regardless of validation state	Drafts, auto-save, partial persistence

ignoreValidators gives you precise control over what happens when users submit while validation is still running.

If you’re building real-world Angular applications with Signal Forms, this is an option you should understand deeply.

If this helped you, be sure to subscribe for more deep dives into modern Angular features.

Additional Resources

Angular Signal Forms: Number Inputs Finally Fixed in Angular 21.2

Thu, 26 Feb 2026 00:00:00 +0000

Number inputs in Angular Signal Forms had a subtle but frustrating problem, there was no clean way to represent an empty numeric field. But, as of v21.2.0, this issue has been quietly fixed. Let me show you exactly what this looked like before, and then follow it up with how it works now.

To demonstrate the problem, let’s start with a basic signup form that has a username and email field:

At the bottom of the form, we’re outputting the form model value so we can see exactly what’s happening in real time as we interact with the form:

Now let’s say we need to add an age field.

Seems simple enough, just add a number input, right?

But this is where things get interesting.

The Obvious Solution (zero)

In the component TypeScript, we have a SignupModel interface that defines the shape of our form data:

interface SignupModel {
	username: string;
	email: string;
}

Now, we want to add a new property for age.

Since this is a number field, I’ll type it as a number:

interface SignupModel {
	username: string;
	email: string;
	age: number;
}

Now, we need to initialize the form model signal with a default value for the age field.

Since age is a number, the most obvious default value is zero:

protected readonly model = signal<SignupModel>({
    username: '',
    email: '',
    age: 0,
});

We also need validation.

Inside the form configuration function, we need to add a required validator for this new age field:

protected readonly form = form(
    this.model, 
    s => {
        ...
        required(s.age, { message: 'Please enter an age' });
    }
);

This ensures that the user must provide a value for this field.

Adding a Number Input Using Angular Signal Forms

In the template, the age field follows the same pattern as the other inputs:

<div class="field">
    @let age = form.age();
    @let showAgeError = age.touched() && age.invalid();
    <label for="age">Age</label>
    <input
        id="age"
        type="number"
        [formField]="form.age" />
    @if (showAgeError) {
        <ul class="error-list">
            @for (error of age.errors(); track error.kind) {
                <li></li>
            }
        </ul>
    }
</div>

We create an age template variable to reference the age field signal, and then a showAgeError variable to check if the field has been touched and is invalid.

Then, we add a label and number input for the age field.

The formField directive connects the input to the Signal Form control, just like the other fields.

Finally, we add a conditional error message loop that displays validation errors once the field has been touched and is invalid.

The Problem with Zero

This works, but there’s an immediate issue: The age field renders with 0 pre-filled:

The form model output also shows age: 0:

But zero is probably not the user’s actual age.

It’s a placeholder value that creates ambiguity.

We can’t distinguish between the user intentionally entering zero and the user not entering anything at all.

Clearing the field does trigger the required validation error:

And the model value becomes null:

But starting with zero isn’t ideal for most real-world forms.

The Type-Safety Compromise: Using a Union Type (string | number)

One workaround is to loosen the type so that age can be either a number or a string:

export interface SignupModel {
    username: string;
    email: string;
    age: number | string;
}

Then initialize it with an empty string instead of zero:

protected readonly model = signal<SignupModel>({
    username: '',
    email: '',
    age: '',
});

Now the field starts empty:

And the model shows an empty string:

Typing a value works correctly:

But we’ve introduced a different problem: from TypeScript’s perspective, age might be a string.

We’ve lost type safety, and in a real application, this can lead to bugs and extra conversion logic.

The Hack Developers Used (NaN)

Another approach developers used was NaN.

So we revert the interface back to number:

export interface SignupModel {
    username: string;
    email: string;
    age: number;
}

Then we initialize it with NaN instead of an empty string or zero:

protected readonly model = signal<SignupModel>({
    username: '',
    email: '',
    age: NaN,
});

The field starts empty again:

And the model shows null this time, which looks correct:

But NaN is semantically misleading.

It literally means “not a number” while being typed as a number.

It worked because Angular maps empty number inputs to null, but Signal Forms didn’t originally support null as a valid model value for number fields.

NaN was a workaround, not a real solution.

The Correct Approach: Using null for Number Inputs in Angular Signal Forms

As of Angular 21.2.0, Signal Forms officially support null for number inputs.

This aligns Signal Forms with how Reactive Forms and most backend systems represent optional numeric values.

We just need to update the interface to allow null:

export interface SignupModel {
    username: string;
    email: string;
    age: number | null;
}

Then initialize with null:

protected readonly model = signal<SignupModel>({
    username: '',
    email: '',
    age: null,
});

That’s it!

Now the field still starts empty:

And the model value is still null to start:

There are no more hacks, no ambiguity, and no loss of type safety.

null clearly represents the absence of a value, which is exactly how most databases and APIs model optional numeric fields.

Your form state now aligns directly with your data layer.

In Summary

Angular 21.2.0 quietly shipped a small but meaningful improvement for Signal Forms: proper null support for number inputs.

It eliminates the need for workarounds and gives you a clean, type-safe way to represent the absence of a numeric value.

If this helped you, be sure to subscribe for more deep dives into modern Angular features.

Additional Resources

Angular Signal Forms: The New formRoot Directive Explained

Thu, 19 Feb 2026 00:00:00 +0000

Form submission in Angular Signal Forms has always required a bit of manual wiring: a submit handler, preventDefault, and an explicit call to submit(). It works, but it doesn't feel fully Angular. Starting in Angular 21.2-next.3, the new formRoot directive changes that. It makes form submission completely declarative, moves submission logic into the form itself, and eliminates the remaining boilerplate. This post walks through exactly how it works and how to migrate an existing Signal Form in about 60 seconds.

Signal Forms Submission Before formRoot

Here’s the starting point, a simple signup form with a username and email field:

The submit button is disabled until the form is valid:

Once both fields are filled in with valid values, the button enables:

After we submit the form, in the console, we can see the dirty status, form value, and the model signal value:

Everything works, but the amount of manual wiring required just to submit the form isn’t ideal.

Manual Form Submission in Signal Forms (The Old Way)

In the template, form submission requires two manual pieces:

<form (submit)="onSubmit($event)" novalidate>
    ...
</form>

The (submit) binding wires up a custom method and passes along the event.

The novalidate attribute disables the browser’s built-in validation so Signal Forms can handle it instead.

Without it, the browser could show its own popup messages that would conflict with our form validation logic.

This is what we’ll be changing in this tutorial.

But just to make sure we understand all aspects of this form before changing it, each input uses the formField directive to connect to the Signal Form:

<input
    id="username"
    type="text"
    [formField]="form.username" />
...
<input
    id="email"
    type="email"
    [formField]="form.email" />

And the submit button triggers submission:

<button type="submit" [disabled]="form().invalid() || form().submitting()"> 
    @if (form().submitting()) {
        Creating… 
    } @else { 
        Create account
    }
</button>

Pretty straightforward stuff.

Now let’s look at the TypeScript for this component.

Component TypeScript

In the component class, the form is constructed with a model signal and validation rules:

export interface SignupModel {
	username: string;
	email: string;
}

const INITIAL_VALUES: SignupModel = {
	username: '',
	email: '',
};

protected readonly model = signal<SignupModel>(INITIAL_VALUES);

protected readonly form = form(
    this.model, 
    s => {
        required(s.username, { message: 'Please enter a username' });
        minLength(s.username, 3, 
            { message: 'Your username must be at least 3 characters' });
        required(s.email, { message: 'Please enter an email address' });
    }
);

This is the key piece driving everything we just saw in the browser.

Then the submit handler wires everything together:

protected onSubmit(event: Event) {
    event.preventDefault();

    submit(this.form, async f => {
        const value = f().value();
        const result = await this.signupService.signup(value);

        if (result.status === 'error') {
            const errors: ValidationError.WithOptionalFieldTree[] = [];

            if (result.fieldErrors.username) {
                errors.push({
                    fieldTree: f.username,
                    kind: 'server',
                    message: result.fieldErrors.username,
                });
            }

            if (result.fieldErrors.email) {
                errors.push({
                    fieldTree: f.email,
                    kind: 'server',
                    message: result.fieldErrors.email,
                });
            }

            return errors.length ? errors : undefined;
        }

        console.log('Form Dirty:', this.form().dirty());
        console.log('Form Value:', this.form().value());
        console.log('Form Model:', this.model());
        return undefined;
    });
}

preventDefault stops the browser from refreshing the page.

If we didn’t include this, the browser would perform a full page refresh which would wipe out our app state.

The submit() call from the Signal Forms API marks fields as touched, runs validation, and executes the submission logic.

If everything succeeds, we log the dirty status, form value, and model signal value to the console.

It works, but there are several pieces that require manual wiring just to submit the form.

The new formRoot directive eliminates some of it.

Angular formRoot Directive Explained (Signal Forms)

Starting in Angular 21.2-next.3, the FormRoot directive is now available from @angular/forms/signals.

Step 1: Add FormRoot to the Component Imports

import { ..., FormRoot } from '@angular/forms/signals';

@Component({
    selector: 'app-form',
    imports: [..., FormRoot],
    ...
})

Step 2: Update the Template

Here we remove the (submit) binding and novalidate attribute and replace them with the formRoot directive:

<form [formRoot]="form">
    ...
</form>

This directive handles both of these automatically.

That’s the only template change needed.

Angular now handles submission automatically.

formRoot prevents default browser submission behavior internally and connects the DOM form to the Signal Form model.

Step 3: Move Submission Logic Into the Form

The key shift is that submission logic now lives directly inside the form definition instead of in a separate event handler.

This makes the form self-contained and removes the need for manual submission wiring in the template.

This is done with a third argument on the form() function containing a submission property.

We can essentially move everything from the submit() function in the onSubmit() method here:

protected readonly form = form(
    this.model, 
    s => { ... },
    {
        submission: {
            action: async f => {
                const value = f().value();
                const result = await this.signupService.signup(value);

                if (result.status === 'error') {
                    const errors: ValidationError.WithOptionalFieldTree[] = [];

                    if (result.fieldErrors.username) {
                        errors.push({
                            fieldTree: f.username,
                            kind: 'server',
                            message: result.fieldErrors.username,
                        });
                    }

                    if (result.fieldErrors.email) {
                        errors.push({
                            fieldTree: f.email,
                            kind: 'server',
                            message: result.fieldErrors.email,
                        });
                    }

                    return errors.length ? errors : undefined;
                }

                console.log('Form Dirty:', this.form().dirty());
                console.log('Form Value:', this.form().value());
                console.log('Form Model:', this.model());
                return undefined;
            }
        }
    }
);

The old onSubmit() method can now be removed entirely.

The formRoot directive connects the DOM <form> element to the Signal Form model declaratively.

When the form is submitted, Angular automatically calls the configured submission.action callback.

This mirrors how formGroup connects a DOM <form> to a FormGroup in Reactive Forms.

formRoot in Action: Same Result, Less Code

After saving, the form looks exactly the same:

And when we submit the form, we see the same console output:

Everything works exactly the same, but with a little less code now.

At this point, I think there’s one more improvement we can make.

Resetting Signal Forms After Submission

After submission, the form keeps its values by default.

To clear the fields and reset form state, we’ll call reset() inside the submission action:

protected readonly form = form(
    this.model, 
    s => { ... },
    {
        submission: {
            action: async f => {
                ...

                console.log('Form Dirty:', this.form().dirty());
                console.log('Form Value:', this.form().value());
                console.log('Form Model:', this.model());

                f().reset();

                console.log('Form Dirty:', this.form().dirty());
                console.log('Form Value:', this.form().value());
                console.log('Form Model:', this.model());

                return undefined;
            }
        }
    }
);

This resets the form to its initial state.

We’ve also added more logs to see the final state of the form and model signals after it’s been reset.

Now, after we save the form and submit again, it almost looks like nothing changed.

But if we look closely at the console, we can see that the dirty status actually changed from true to false:

What if we also want to reset the form and model value?

Well, this is pretty easy to do now.

How to Reset Form State AND Model Signal

According to the Signal Forms docs, reset() does several things.

First, it says that this resets the touched and dirty states of the field and its descendants.

And then, optionally we can pass a value to reset the value of the form, which we didn’t and that’s why the value remained the same:

It also mentions that it does not change the data model, it needs to be reset directly, meaning that we need to manually reset the model signal back to its initial value

Kinda clunky… but ok.

So calling reset() alone will correctly reset dirty to false, but the form fields will still show their submitted values.

To reset the actual field values, we need to pass the initial data to reset():

protected readonly form = form(
    this.model, 
    s => { ... },
    {
        submission: {
            action: async f => {
                ...
                f().reset(INITIAL_VALUES);
                ...
            }
        }
    }
);

Passing a value to reset() resets both the form fields back to their initial values.

Now, what I found during testing is that this appears to handle the model signal automatically now too.

No need to reset the model signal separately.

This appears to be an intentional improvement in recent Angular releases.

And now after submitting, the fields clear out and both the form value and model signal return to their initial empty state:

Why formRoot Is Probably the New Recommended Pattern

The formRoot directive removes the last piece of manual boilerplate from Signal Forms submission.

Declaring submission logic inside the form rather than in a separate method keeps everything in one place, which is easier to read and easier to test.

You can still use the submit() function directly when you need fine-grained control, but for most forms, formRoot is the cleaner path forward.

It also aligns Signal Forms more closely with Angular’s existing Reactive Forms mental model, where directives like formGroup declaratively connect the DOM to the form model.

formRoot follows the same idea.

If this helped you, be sure to subscribe for more deep dives into modern Angular features.

Additional Resources

Bridge Signal Forms and Reactive Forms in Angular 21.2

Thu, 12 Feb 2026 00:00:00 +0000

What if you could start using Angular Signal Forms inside an existing Reactive Form without rewriting the entire thing? Well, in Angular 21.2-next, you can! The new SignalFormControl class acts as a compatibility bridge, letting you mix signal-backed fields into a traditional FormGroup while keeping your existing form structure intact. This post walks through how it works, how to add it to an existing form, and what changes in the template.

This approach allows Angular developers to use SignalFormControl for Reactive Forms compatibility without a full migration.

Current Angular Reactive Form Example (Baseline Setup)

In this example, we’ll work with a profile form built entirely with the Reactive Forms module.

The form has three sections: Account Information, Shipping Address, and Preferences:

Interacting with the controls in this form updates the debug panel in real time:

As soon as everything required is filled in, the form becomes valid and the submit button enables:

This is a standard Angular Reactive Form.

Let’s look at how it’s built.

How This Reactive Form Is Built (FormGroup + FormControl)

In the component TypeScript, we have a ProfileForm interface:

interface ProfileForm {
  account: FormGroup<{
    firstName: FormControl<string>;
    lastName: FormControl<string>;
  }>;
  shippingAddress: FormGroup<{
    street: FormControl<string>;
  }>;
  preferences: FormGroup<{
    marketingOptIn: FormControl<boolean>;
  }>;
}

The form is constructed using FormGroup for each section and FormControl for each field:

export class ProfileFormComponent {
  readonly form = new FormGroup<ProfileForm>({
    account: new FormGroup({
      firstName: new FormControl('', {
        validators: [Validators.required],
        nonNullable: true
      }),
      lastName: new FormControl('', {
        validators: [Validators.required],
        nonNullable: true
      })
    }),
    shippingAddress: new FormGroup({
      street: new FormControl('', {
        validators: [Validators.required],
        nonNullable: true
      }),
    }),
    preferences: new FormGroup({
      marketingOptIn: new FormControl(false, { nonNullable: true })
    })
  });
}

The first name, last name, and street address fields are required.

The marketing opt-in field is not.

That’s the form configuration, now let’s look at the template.

How formGroup and formControlName Work in Angular

In the template, the formGroup directive binds the DOM form to the FormGroup instance:

<form [formGroup]="form" (submit)="onSubmit($event)">
  ...
</form>

The formGroupName directive targets the nested “account” section:

<div class="field-group" formGroupName="account">
  ...
</div>

and within it, formControlName wires each input to its FormControl:

<input type="text" formControlName="firstName" />

A template variable holds the control for reuse, then we check touched and errors to display validation messages:

@let firstNameControl = form.controls.account.controls.firstName;
@if (firstNameControl.touched && firstNameControl.errors) {
  <span class="error">First name is required</span>
}

The same pattern repeats for the street field and the preferences section.

Classic Reactive Forms.

Nothing new, nothing fancy, totally predictable.

Why Migrating Large Reactive Forms to Signal Forms Is Hard

This form is moderately complex, but imagine it’s much larger.

Imagine it has many fields, nested groups, and custom components everywhere.

Fully migrating to Signal Forms would be painful and, potentially, not feasible in the short term.

Yet you want to start using Signal Forms for new features.

Until Angular 21.2, there wasn’t a clean way to mix the two.

The new SignalFormControl class solves that.

It’s a compatibility wrapper that allows a signal-backed field to behave like a standard FormControl inside a FormGroup.

If you’re adding new fields to an existing form, that’s the perfect place to try it.

Using SignalFormControl to Bridge Signal Forms and Reactive Forms

Suppose we need to add three new fields to the shipping address section: city, state, and zip, and we want these to be signal-backed controls.

Step 1: Add SignalFormControl to the FormGroup Interface

First, we need to update the form interface to include the new fields.

Instead of FormControl we’ll use SignalFormControl from the Signal Forms compat API:

import { SignalFormControl } from '@angular/forms/signals/compat';

interface ProfileForm {
  account: FormGroup<{ ... }>;
  shippingAddress: FormGroup<{
    street: FormControl<string>;
    city: SignalFormControl<string>;
    state: SignalFormControl<string>;
    zip: SignalFormControl<string>;
  }>;
  preferences: FormGroup<{ ... }>;
}

The group now mixes FormControl and SignalFormControl, that’s the whole point of the bridge.

Step 2: Creating SignalFormControl with Signal-Based Validation

Now let’s create the new signal-backed controls.

The first parameter is the initial value, the second is the schema callback familiar from Signal Forms where we can add validation:

readonly city = new SignalFormControl('', s => {
  required(s, { message: 'City is required' });
});

Now we’ll do the same for the state field:

readonly state = new SignalFormControl('', s => {
  required(s, { message: 'State is required' });
});

And one more for the zip field:

readonly zip = new SignalFormControl('', s => {
  required(s, { message: 'ZIP code is required' });
  pattern(s, /^\d{5}$/, { message: 'ZIP code must be 5 digits' });
});

This field also has a pattern validator to ensure the format is 5 digits.

Step 3: Mixing SignalFormControl Inside an Existing FormGroup

Now we have our signal-based form controls.

All that’s left is to add them to the form.

This is pretty easy, we just add them to the shipping address group using these new properties:

readonly form = new FormGroup<ProfileForm>({
    account: new FormGroup({ ... }),
    shippingAddress: new FormGroup({
        street: new FormControl('', Validators.required),
        city: this.city,
        state: this.state,
        zip: this.zip,
    }),
    preferences: new FormGroup({ ... }),
});

Notice the FormGroup type, submit handler, and root-level structure stay the same.

We’ve officially mixed signal-backed controls into a Reactive FormGroup without changing the form itself.

Using the formField Directive with SignalFormControl

Now we need to render these fields in our template.

We can’t use formControlName for these new fields because they’re not plain FormControl instances.

They expose a fieldTree, which is the signal-based representation of the control’s state (value, touched, errors, etc.).

Instead, we need to use the FormField directive from the Signal Forms API.

So let’s add FormField to the component imports:

import { ..., FormField} from '@angular/forms/signals';

@Component({
  selector: 'app-profile-form',
  ...,
  imports: [ReactiveFormsModule, FormField]
})

Then over in the template, inside the shipping address section, we’ll use the formField directive to connect the input to the signal field tree:

<label>
  City
  <input type="text" [formField]="city.fieldTree" />
</label>

This properly wires up the signal-backed control to the input.

Then, we’ll use a template variable to check touched and errors and iterate over error messages to handle validation:

<label>
  City
  <input type="text" [formField]="city.fieldTree" />
  @let cityControl = city.fieldTree();
  @if (cityControl.touched() && cityControl.errors(); as errors) {
    @for (error of errors; track error) {
      <span class="error"></span>
    }
  }
</label>

And that’s it, the City field is now signal-backed inside a Reactive Form.

Then, we do the same for the State field:

<label>
  State
  <input type="text" [formField]="state.fieldTree" />
  @let stateControl = state.fieldTree();
  @if (stateControl.touched() && stateControl.errors(); as errors) {
    @for (error of errors; track error) {
      <span class="error"></span>
    }
  }
</label>

And one more time for the Zip Code field:

<label>
  Zip Code
  <input type="text" [formField]="zip.fieldTree" />
  @let zipControl = zip.fieldTree();
  @if (zipControl.touched() && zipControl.errors(); as errors) {
    @for (error of errors; track error) {
      <span class="error"></span>
    }
  }
</label>

Alright, this is all we need now to intermingle signal form controls with reactive forms.

Let’s save and try it out!

Testing SignalFormControl Inside a Reactive Form

Now we have our new fields in the address section:

We also have these new properties displaying within our form group object:

When we add a value in the City field, the debug panel still reflects everything correctly:

From Angular’s perspective, this behaves like a normal FormControl.

But under the hood, this field is powered by signals.

And when we clear out the value:

A validation error shows, so our validation is working too!

And once we fill out all of the required fields properly, the form becomes valid and the submit button enables:

How SignalFormControl Enables Incremental Migration

In this example we did not:

Rewrite the entire form
Replace the FormGroup
Break existing template bindings
Change the submit handler

We adopted Signal Forms incrementally.

For teams maintaining large Reactive Forms codebases, this is a major unlock.

It’s the kind of feature that makes gradual migration possible instead of painful.

If you’re planning a Signal Forms strategy for your app, this is where you start.

If this helped you, be sure to subscribe for more deep dives into modern Angular features.

Additional Resources

Angular 21.2 New Feature: Arrow Functions in Templates (With Gotchas)

Thu, 05 Feb 2026 00:00:00 +0000

If you've ever created a method just to call update() on a signal, this one's for you. Writing signal updates directly in component templates used to be impossible, but as of Angular 21.2-next, arrow functions are now allowed in Angular templates! This change lets you write signal transitions exactly where they happen, making templates more expressive and eliminating unnecessary wrapper methods. But while it's incredibly powerful, there are a few caveats you absolutely need to understand.

Order Summary Demo Built with Angular Signals

Here’s a basic order summary application that we’ll be using throughout this example:

We have a quantity control to adjust the quantity, a button to add a discount coupon, and another button to increase the tax rate.

When we use any of these buttons, we can see the totals at the bottom adjust in real-time:

Pretty basic stuff, all handled with signals.

Now let’s look at the code behind all of this.

The Old Way: Before Arrow Functions in Templates

Let’s start with the template for this component.

The buttons used to adjust the quantity look like this:

<button type="button" (click)="decrementQty()">−</button>
<strong>{{ qty() }}</strong>
<button type="button" (click)="incrementQty()">+</button>

For the decrement button we have a decrementQty() function, and for the increment button we have an incrementQty() function.

Then, for the coupon button, same thing, we have a toggleCoupon() function:

<button type="button" (click)="toggleCoupon()">
  {{ couponOn() ? 'Remove 20% coupon' : 'Apply 20% coupon' }}
</button>

And, same thing with the tax rate button:

<button type="button" (click)="increaseTax()">+1%</button>

So each button has its own function.

Now let’s switch over to the TypeScript to see what these functions do.

Here are all four of these functions:

protected incrementQty() {
  this.qty.update(n => n + 1);
}

protected decrementQty() {
  this.qty.update(n => (n > 0 ? n - 1 : 0));
}

protected toggleCoupon() {
  this.couponOn.update(v => !v);
}

protected increaseTax() {
  this.taxRate.update(r => r + 0.01);
}

Each of them simply updates a signal value using the update() method.

Essentially, they exist for one reason: because we aren’t able to use arrow functions in templates.

If we were just calling set(), but update() requires a function.

However, now as of Angular 21.2-next.0, we can actually use arrow functions in the template!

So let’s modernize this!

Angular 21.2: Using Arrow Functions Directly in Templates

First, we can delete all of those wrapper functions since they’re not needed anymore.

Then, back in the HTML, let’s update these buttons.

Let’s start with the decrement button.

Instead of the old function, I’m going to add the signal update() method right here in the template.

Before:

<button type="button" (click)="decrementQty()">−</button>

After:

<button type="button" (click)="qty.update(n => n > 0 ? n - 1 : 0)">−</button>

We’re passing a function to the update() method, and that function receives the previous value.

That’s what n is. It’s the current quantity.

Then, we’re returning the new value.

Now let’s do the increment button.

Before:

<button type="button" (click)="incrementQty()">+</button> 

After:

<button type="button" (click)="qty.update(n => n + 1)">+</button>

That’s it. No wrapper method needed.

Now let’s convert the coupon button.

Before:

<button type="button" (click)="toggleCoupon()">
  {{ couponOn() ? 'Remove 20% coupon' : 'Apply 20% coupon' }}
</button>

After:

<button type="button" (click)="couponOn.update(v => !v)">
  {{ couponOn() ? 'Remove 20% coupon' : 'Apply 20% coupon' }}
</button>

Instead of the old method, we use the signal and the update() method directly.

Same idea here, v is the previous boolean value. We just flip it when the button is clicked.

Now we just need to update the increase tax button.

Before:

<button type="button" (click)="increaseTax()">+1%</button>

After:

<button type="button" (click)="taxRate.update(r => r + 0.01)">+1%</button>

Instead of the old method again, we just use the update() method.

Alright, let’s save and make sure everything still works:

Okay, it all looks the same to start, and when I change the quantity, discount, and tax rate, everything still works.

Pretty cool right?

The fact that the only way I could use the update() function was in the TypeScript has definitely bothered me in the past, so I’m pretty stoked on this update.

This is the real power here.

That’s four methods deleted, four fewer things to name, four fewer things to test, and four fewer places for bugs to hide.

Now, while this is awesome, arrow functions in templates do have some constraints.

Let’s look at one.

Angular Template Mistake: Accidentally Returning a Function

This will probably be a rare mistake to make, but you need to be careful not to accidentally return a function in your event handler like this:

<!-- ❌ Wrong: This compiles but does nothing -->
<button type="button" (click)="() => qty.update(n => n + 1)">+</button>

This compiles… but it does nothing because we’re just returning a function.

An easy way to avoid this is to only use simple arrow functions in the template.

If it’s more than 5 to 7-ish lines, it probably belongs in the TypeScript.

Okay, now let’s look at something you’re more likely to encounter.

Angular Error: Object Literals Must Be Wrapped in Parentheses

Here, I’ve now changed this example around a little so that the tax rate is now part of a settings object instead of its own signal:

protected readonly settings = signal<SummarySettings>({
  taxRate: 0.08,
  // ... other settings
});

And our “total” computed signal now uses this in its calculation too:

protected readonly total = computed(() =>
  this.discounted() * (1 + this.settings().taxRate)
);

So now let’s update the tax rate in the template using this settings object signal.

Right now, our event handler is empty:

<button type="button" (click)="">+1%</button>

So let’s update the settings signal using the update() method:

<button type="button" (click)="settings.update(s => { taxRate: s.taxRate + 0.01 })">+1%</button> 

The tax rate will be set using the current tax rate value and adding 0.01 to it.

Okay that should be it right?

Let’s save and try it out:

Oops, looks like we have an error.

And if we read it closely we can see that it’s telling us exactly what the problem is.

If we’re using an object literal, we need to wrap it with parentheses.

This is because in JavaScript, curly braces after an arrow indicate a function body, not an object literal.

Angular templates only allow implicit returns.

That means the arrow function must evaluate to a single expression.

So Angular thinks you’re writing a block and blocks aren’t supported here.

So the fix is simple, we just need to add parentheses.

Before (Error):

<button type="button" (click)="settings.update(s => { taxRate: s.taxRate + 0.01 })">+1%</button> 

After (Fixed):

<button type="button" (click)="settings.update(s => ({ taxRate: s.taxRate + 0.01 }))">+1%</button> 

Now let’s look at another constraint.

Angular Pipes and Arrow Functions: What Works and What Breaks

We have to be careful when using pipes with arrow functions.

We’re going to calculate shipping cost based on distance.

Let’s add a new row:

<div class="row">
  <span>Shipping (100 miles)</span>
</div>

I’ll give it a label denoting that it’s based on 100 miles.

We’ll just need to imagine that this 100 mile distance would be a dynamic value that could be anything.

It could be 5 miles, 500 miles, 2000 miles, it could be anything but here we’ll just be using a static value of 100.

Okay, now I’ll add an arrow function to calculate this value:

<div class="row">
  <span>Shipping (100 miles)</span>
  <span>{{ ((dist, rate) => dist * rate | currency)(100, 0.05) }}</span>
</div>

We have a distance (dist) and rate parameter.

Then we return the distance times the rate.

We also use the currency pipe to format the value.

Next, we immediately call this function passing it our static 100 mile value and a rate of 0.05.

Okay, now let’s save and try this out:

Oops, we’ve got an error again now. But why?

Well, this time it’s because pipes are Angular template syntax, not JavaScript.

The arrow function body must be valid JavaScript, and the pipe operator isn’t JavaScript.

So the rule is you cannot use pipes inside arrow bodies.

You must instead apply the pipe to the result of the arrow function.

This means, we just need to move it outside:

Before (Error):

<span>{{ ((dist, rate) => dist * rate | currency)(100, 0.05) }}</span>

After (Fixed):

<span>{{ ((dist, rate) => dist * rate)(100, 0.05) | currency }}</span>

So…

We can only have implicit returns with arrow functions in the template.
Object literals must be wrapped in parentheses
Pipes cannot live inside arrow function bodies

When to Use Arrow Functions in Angular Templates

This is one of those changes that seems small until you start removing code.

It lets us write signal transitions exactly where they happen.

It makes our templates more expressive and our overall logic simpler.

But it also forces us to understand the difference between Angular template syntax and JavaScript expressions.

If you’re building modern Angular apps using signals, this change definitely matters.

If this helped you, be sure to subscribe and leave a comment, it really helps other Angular developers find this content.

Brian Treese

How to Get Specific Validation Errors with Angular Signal Forms

A Password Checklist with Angular Signal Forms

Why Error Indexes Break in Angular Signal Forms

Using errors().find() to Check Validation Rules

Angular 22: Using getError() for Clean Validation Checks

The Final Result

Why getError() Makes Signal Forms Easier to Use

Get Ahead of Angular’s Next Shift

Additional Resources

Angular 22's New Built-in Debounce for Async Validation Explained

The Problem: Debouncing Delays All Validators

The Old Way: Field-Level Debounce

The New Way: Validator-Level Debounce

Angular 22 Fix: Built-in Debounce for Async Validators

The Final Result

Why This Makes Signal Forms Better

Get Ahead of Angular’s Next Shift

Additional Resources

Angular 22: Mix Signal Forms and Reactive Forms Seamlessly

Reactive Forms Setup with a Custom Control

The Old Way: How ControlValueAccessor Works in Angular

Why ControlValueAccessor Is So Verbose

Replace ControlValueAccessor with FormValueControl

The Final Result

Key Takeaway: Migrate to Signal Forms Without Rewriting Everything

Get Ahead of Angular’s Next Shift

Additional Resources

Angular’s New debounced() Signal Explained

The Problem: Too Many API Requests

The Old Way: Debouncing with RxJS debounceTime

The New Way: debounced() and resource() in Angular v22

Step 1: Create a Debounced Signal

Step 2: Refactor to Use resource()

Updating the Template for the resource API

The Final Result

Get Ahead of Angular’s Next Shift

Additional Resources

Angular Signal Forms: Is FormValueControl Better for Large Forms?

The Original Approach

Angular Signal Forms Demo: Reusable Form Sections

Building Reusable Angular Signal Forms with Field Tree

Inside a Reusable Angular Form Section Component

Refactoring to Angular FormValueControl

Before:

After:

Connecting FormValueControl to the Parent Signal Form

Before:

After:

Before:

After:

Why Parent Form Validation Breaks with FormValueControl

Should You Use FormValueControl for Angular Signal Form Sections?

Learn Angular Signal Forms in depth

Additional Resources

Angular 21 Signal Forms: ignoreValidators Explained

Angular Signal Forms: Default Submission Behavior with Async Validators

How the Signal Form Is Configured (Template + Submission Logic)

The TypeScript: Model and Validation

ignoreValidators: ‘pending’ - Default Async Submission Behavior Explained

ignoreValidators: ‘none’ - Block Submission Until Validation Completes

Using onInvalid to Auto-Focus the First Invalid Field

ignoreValidators: ‘all’ - Submit Even When Invalid or Pending

Choosing the Right ignoreValidators Mode for Real-World Angular Apps

Additional Resources

Angular Signal Forms: Number Inputs Finally Fixed in Angular 21.2

The Starting Point: A Simple Signup Form

The Obvious Solution (zero)

Adding a Number Input Using Angular Signal Forms

The Problem with Zero

The Type-Safety Compromise: Using a Union Type (string | number)

The Hack Developers Used (NaN)

The Correct Approach: Using null for Number Inputs in Angular Signal Forms

In Summary

Additional Resources

Angular Signal Forms: The New formRoot Directive Explained

Signal Forms Submission Before formRoot

Manual Form Submission in Signal Forms (The Old Way)

Component TypeScript

Angular formRoot Directive Explained (Signal Forms)

The Old Way: Debouncing with RxJS `debounceTime`

The New Way: `debounced()` and `resource()` in Angular v22

Step 2: Refactor to Use `resource()`

Updating the Template for the `resource` API