Angular Signal Forms Config - Angular Experts

Angular 21 finally ships Signal Forms, marked as an experimental API — a feature the community has been asking for over a long period.

The direction is unambiguous by now: Signals sit at the foundation of modern Angular. Adoption has spread across Signal Inputs, Queries (viewChild, viewChildren, contentChild & contentChildren), inputs, and the list continues. Even third-party ecosystems such as NgRx are embracing the model accordingly. So the enthusiasm around extending this reactive approach to forms is easy to understand.

This post does not walk through creating Signal Forms, though. What we will cover is configuration, and we'll call out one specific behavioral shift around state classes that deserves your attention.

Prefer watching over reading? A full walkthrough of these concepts is available in the recording from our brand new Angular Signal Forms Workshop.

Where Did the CSS Classes Go?

With template-driven or reactive forms, Angular has always attached state classes directly onto form controls automatically.

These state classes — ng-valid, ng-invalid, and ng-touched among others — mirror the live state of each input. They are convenient because they let you style the interface according to user interaction without putting any extra logic in the template code. You may be using them, for instance, to display a red border whenever a field is invalid or a green checkmark once the field is valid.

Spin up a Signal Form and inspect the resulting HTML, though, and the classes are nowhere to be found. No ng-valid, no ng-dirty — nothing.

Signal Forms, unless told otherwise, skip attaching any such classes. For a legacy application this can become a real problem. If your global styles target .ng-invalid, your UI will not render as intended.

The Signal Forms Config exists precisely to address this situation.

Preserving Old Behavior with SignalFormsConfig

A new utility function, provideSignalFormsConfig, is provided by Angular for this purpose. If you want the familiar behavior back because of your current CSS dependencies, no manual class binding in the template is required.

Simply configure the global provider with the constant NG_STATUS_CLASSES:

import { provideSignalFormsConfig, NG_STATUS_CLASSES } from '@angular/forms';

export const appConfig: ApplicationConfig = {
  providers: [
    provideSignalFormsConfig({
      classes: NG_STATUS_CLASSES
    })
  ]
};

Once this is in place, your Signal Forms will attach the standard Angular state classes again, which makes migrating a notably smoother experience.

Custom Class Definitions

But the configuration object covers more than just the default constants. Dynamic definitions are possible as well — useful for instances where you need specialized CSS class names.

Within the configuration, you can map signal state properties directly to the class names you want:

provideSignalFormsConfig({
  classes: {
    'my-company-input-error': ({state}) => state().invalid(),
    'my-company-input-touched': ({state}) => state().touched(),
    'my-company-input-dirty': ({state}) => state().dirty(),
  }
}),

After applying this, every form control updates itself reactively with your custom classes:

Why the Config Uses an Object

It is worth noting: provideSignalFormsConfig accepts a configuration object, not a set of individual function arguments.

That is an intentional decision so the API can grow smoothly. Right now our focus is on CSS classes, but supplying a configuration object means future configuration options can be added by the Angular team without breaking the function signature.

Signal Forms may be experimental, but approaches like this make it evident that both a polished developer experience — e.g., a minimal, clean DOM — and workable migration strategies are high on the priority list.

TL;DR

• Signal Forms in Angular 21 no longer attach CSS state classes by default — no ng-valid, ng-invalid, ng-touched, or the like.
• Combine provideSignalFormsConfig with NG_STATUS_CLASSES for backward compatibility with pre-existing styles.
• To roll your own custom class names, add dynamic mappings that depend on signal state functions.
• Choosing a configuration object vs. multiple parameters makes the API possible to extend later without breaking changes.

Ready to take a deeper dive into Angular Signal Forms? Our full Angular Signal Forms Workshop is loaded with practical, hands-on labs to guide you further!