DEV Community: Brian Treese

Angular’s New injectAsync() API Explained

Brian Treese — Fri, 08 May 2026 07:00:00 +0000

Angular v22 just made lazy-loading services much simpler. In this post, we'll explore how to leverage the new injectAsync() API to reduce your main bundle size and replace awkward lazy-loading workarounds. We’ll compare the older manual lazy-loading approach with Angular v22’s new injectAsync() API and see why the new pattern feels simpler and easier to reason about.

The Problem: Libraries Loading Too Early

When building Angular applications, it's common to include third-party libraries for various functionalities.

However, if these libraries are not loaded efficiently, they can increase your initial bundle size, leading to slower application startup times.

In our demo application, we're using highlight.js and Marked for markdown processing and syntax highlighting.

In this case, the post-editor component itself is needed immediately, but the markdown-processing dependency isn’t.

Even though the feature might not be immediately needed by the user, these libraries are loaded upfront, contributing to a 17.2kb main bundle:

This eager loading means users are paying for code they might never use, impacting performance.

Understanding the Markdown Service and its Eager Usage

Our demo application features a MarkdownService responsible for converting markdown content into HTML with syntax highlighting.

This service leverages marked, marked-highlight, and highlight.js to achieve this functionality:

import { Service } from '@angular/core';
import hljs from 'highlight.js/lib/common';
import { Marked } from 'marked';
import { markedHighlight } from 'marked-highlight';

@Service()
export class MarkdownService {
  private readonly marked = new Marked(
    markedHighlight({
      emptyLangClass: 'hljs',
      langPrefix: 'hljs language-',
      highlight(code, lang) {
        const language = hljs.getLanguage(lang) ? lang : 'plaintext';

        return hljs.highlight(code, { language }).value;
      },
    })
  );

  render(content: string): string {
    return this.marked.parse(content, { async: false });
  }
}

The core issue arises from how this service is consumed.

Initially, the post-editor component directly injects the MarkdownService:

import { Component, inject, signal } from '@angular/core';
import { MarkdownService } from '../markdown.service';

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');
  private markdownService = inject(MarkdownService);

  preview() {
    this.previewHtml.set(this.markdownService.render(this.content()));
  }
}

Because the MarkdownService is statically imported and injected into PostEditorComponent, Angular includes it and all its dependencies (marked, highlight.js) in the initial application bundle.

This happens regardless of whether the user has interacted with the markdown preview feature, leading to unnecessary upfront loading and a larger initial bundle size.

This is the "problem" we aim to solve with lazy loading.

The Old Way: Manually Lazy Loading an Angular Service

Historically, addressing eager loading for services involved a fair amount of manual setup.

To lazy load the MarkdownService and its dependencies, we would typically inject Angular's Injector and dynamically import the service.

It might look something like this:

import { Component, inject, Injector, signal } from '@angular/core';

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');
  private readonly injector = inject(Injector);
  private markdownServicePromise: Promise<MarkdownService> | null = null;

  async preview() {
    this.markdownServicePromise ??= import('../markdown.service').then(m =>
      this.injector.get(m.MarkdownService)
    );

    const markdownService = await this.markdownServicePromise;
    this.previewHtml.set(markdownService.render(this.content()));
  }
}

This approach solves the problem.

The bundle size is reduced, and highlight.js and marked are no longer part of the initial page load:

They are now dynamically loaded only when the preview() method is called:

However, this manual lazy loading introduces a lot of setup, making it less ergonomic and harder to maintain.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

The New Way: Replacing Boilerplate with injectAsync()

Angular v22 introduces injectAsync(), a new API that simplifies lazy loading services.

This function handles much of the orchestration we previously had to manage ourselves.

To refactor our post-editor component using injectAsync(), we can remove the Injector and the markdownServicePromise:

import { Component, injectAsync, onIdle, signal } from '@angular/core';

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');

  private markdownService = injectAsync(
    () => import('../markdown.service').then(m => m.MarkdownService)
  );

  async preview() {
    const svc = await this.markdownService();
    this.previewHtml.set(svc.render(this.content()));
  }
}

With injectAsync(), we pass a loader function that dynamically imports the service.

Angular automatically captures the current injection context, resolves the service through dependency injection, and caches the result.

This makes the implementation simpler and easier to reason about.

Prefetch Lazy Dependencies with onIdle

injectAsync() also offers a prefetch option, allowing us to load dependencies early, but without blocking the initial bundle:

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

private markdownService = injectAsync(
  () => import('../markdown.service').then(m => m.MarkdownService),
  { prefetch: onIdle }
);

By setting prefetch: onIdle, Angular will begin loading the dependency quietly in the background once the browser becomes idle.

This means the feature stays out of the initial bundle, but the user might never notice a loading delay because the service is already prefetched by the time they need it.

The Final Result

The application continues to function exactly as before, but with an optimized loading strategy.

The initial bundle size is smaller, and the markdown libraries are lazy-loaded, either on demand or prefetched during browser idle time.

This makes the pattern much more practical for real-world applications.

Get Ahead of Angular's Next Shift

Angular’s newest APIs are changing the way we build.

If you’re ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course
👉 Get it with YouTube membership

Additional Resources

Angular 22 @Service vs @Injectable (What You Need to Know)"

Brian Treese — Fri, 01 May 2026 07:00:00 +0000

Every Angular developer is familiar with @Injectable({ providedIn: 'root' }) for declaring services. While powerful, the @Injectable decorator supports many advanced configurations that are rarely used in typical application services. Angular 22 introduces a new @Service decorator designed to simplify service declaration for the most common use cases. This post will explore how it streamlines service creation and even enforces modern dependency injection patterns.

Version Disclaimer

This API is currently in pre-release, so some details may change before the final Angular 22 release.

The Problem: Overly Complex Service Declaration

For many years, declaring a service in Angular meant using the @Injectable decorator, often with the providedIn: 'root' option.

This pattern, while effective, includes configuration options that are seldom needed for straightforward application services.

Let's look at a very simple example of a service that fetches user data and posts from an API:

import { Injectable, signal } from '@angular/core';
import { HttpClient, httpResource } from '@angular/common/http';
import { Post, User } from './models';

const BASE = 'https://jsonplaceholder.typicode.com';

@Injectable({ providedIn: 'root' })
export class PostsService {
  selectedUserId = signal<number | null>(null);

  users = httpResource<User[]>(() => `${BASE}/users`, { defaultValue: [] });

  posts = httpResource<Post[]>(() => {
    const id = this.selectedUserId();
    if (!id) {
      return undefined;
    }
    return `${BASE}/posts?userId=${id}`;
  }, { defaultValue: [] });
}

This code works perfectly fine in current Angular versions.

The @Injectable decorator registers the service as a singleton in Angular's dependency injection system, making the same instance available wherever PostsService is injected.

The New Way: Angular 22 `@Service()` and `inject()`

Angular 22 introduces the @Service() decorator as a simpler, more opinionated alternative to @Injectable for common service patterns.

It’s intended for most app-level services, not a full replacement for every use case.

It assumes the most frequent scenario: a root-provided singleton service.

Step 1: Replacing `@Injectable` with `@Service`

Swapping from @Injectable to @Service is straightforward.

We simply replace the decorator and remove the providedIn: 'root' option, as it's the default behavior for @Service():

import { Service, signal } from '@angular/core'; // Note: Injectable is removed
import { HttpClient, httpResource } from '@angular/common/http';
import { Post, User } from './models';

const BASE = 'https://jsonplaceholder.typicode.com';

@Service() // ← providedIn: 'root' by default, no config needed
export class PostsService {
  selectedUserId = signal<number | null>(null);

  users = httpResource<User[]>(() => `${BASE}/users`, { defaultValue: [] });

  posts = httpResource<Post[]>(() => {
    const id = this.selectedUserId();
    if (!id) {
      return undefined;
    }
    return `${BASE}/posts?userId=${id}`;
  }, { defaultValue: [] });
}

With this change, the PostsService continues to function identically.

So, @Service() provides the same root-level singleton behavior without the explicit configuration.

Step 2: Enforcing `inject()` for Dependencies

One of the significant changes with @Service() is that it does not allow constructor injection.

If you attempt to inject a dependency via the constructor while using @Service(), Angular will throw an error.

This is an intentional guardrail, pushing developers towards the modern inject() function for dependency resolution.

Consider our PostsService with HttpClient injected in the constructor:

import { Service, signal } from '@angular/core';
import { HttpClient, httpResource } from '@angular/common/http';
// ...

@Service()
export class PostsService {
  // ...

  constructor(private http: HttpClient) { // This will cause an error with @Service()
  }
}

Attempting to run this will result in a compilation error:

The solution is to use the inject() function:

import { Service, signal, inject } from '@angular/core'; // Note: inject is imported
import { HttpClient, httpResource } from '@angular/common/http';
// ...

@Service()
export class PostsService {
  // ...

  private http = inject(HttpClient); // Using inject() for dependency
}

This pushes services toward a more functional and consistent dependency injection style, aligning with how modern Angular APIs are designed.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 3: Component-Scoped Services with `autoProvided: false`

While @Service() defaults to root-level provision, it also offers a powerful option for explicit service scoping: autoProvided: false.

This is particularly useful for services that manage UI-specific state and should have their lifetime tied to a particular component.

Let's look at a DraftPostService that manages the state for a draft form:

import { Service, signal, computed } from '@angular/core';

@Service({ autoProvided: false })  // I'll manage where this lives
export class DraftPostService {
  title = signal('');
  body = signal('');
  isValid = computed(() => this.title().length > 3 && this.body().length > 10);

  reset() {
    this.title.set('');
    this.body.set('');
  }
}

By setting autoProvided: false, we explicitly state that this service should not be automatically provided in the root injector.

Instead, its provision becomes the responsibility of the consumer.

This is ideal for UI state that should not persist across navigation or be globally accessible.

If we try to use this service in a component without providing it, we'll encounter a NullInjectorError:

This occurs because Angular's DI system cannot find a provider for DraftPostService in the injector tree.

To fix this, we need to explicitly provide the service at the component level:

import { Component, inject } from '@angular/core';
import { DraftPostService } from './draft-post.service';

@Component({
  selector: 'app-draft-panel',
  templateUrl: './draft-panel.component.html',
  styleUrl: './draft-panel.component.css',
  providers: [DraftPostService], // Service provided here
})
export class DraftPanelComponent {
  protected draft = inject(DraftPostService);
}

Now, the DraftPostService's lifetime is directly tied to the DraftPanelComponent.

When the component is created, the service is instantiated.

When it’s destroyed, the service is destroyed as well.

This makes the intent of the service's scope explicit and clear.

The Final Result

The @Service() decorator in Angular 22 offers a more streamlined and opinionated way to declare services, especially for the most common use cases.

It simplifies things, encourages the use of the inject() function for dependencies, and provides a clear mechanism for defining component-scoped services with autoProvided: false.

This isn't just about new syntax, it's about making the intent of your services more explicit and guiding developers toward modern Angular patterns.

By embracing @Service(), you can write cleaner, more maintainable code and better communicate the intended lifecycle and scope of your application's services.

Get Ahead of Angular's Next Shift

And speaking of modern patterns, if you’re trying to go deeper on those, especially things like signals and modern forms, I’ve got a new course available on Signal Forms that walks through how all of this fits together in real apps.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

This completely changed my Angular development workflow

Brian Treese — Fri, 24 Apr 2026 07:00:00 +0000

You ever use AI to generate Angular code that's almost right, but not quite? You end up renaming things, swapping decorators for signals, and rewriting *ngIf to @if every single time. Well, in this post, I'll show you how to use Cursor Skills to encode those fixes once and automate your Angular workflow for the whole team.

The Problem: Fixing "Almost Right" Code

When we use AI to generate Angular code, it often defaults to generic patterns.

We end up spending time manually refactoring it to match our specific architecture or modern Angular conventions like signals and standalone components.

Instead of repeating these manual fixes every time, we can use Cursor Skills to tell the AI exactly how we want our code built.

The Old Way: Manual Refactoring

Before Cursor Skills, we'd ask the AI for a component and get back something that maybe looked like this:

import { Component, Input, Output, EventEmitter } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-hello-world',
  standalone: true,
  imports: [CommonModule],
  template: `
    <section class="hello-world">
      <h2>Hello, world</h2>
      <p *ngIf="todayDate">{{ todayDate }}</p>
      <button type="button" (click)="onClick()">Update time</button>
    </section>
  `,
})
export class HelloWorldComponent {
  @Input() todayDate!: string;
  @Output() updateTime = new EventEmitter<string>();

  onClick() {
    this.updateTime.emit(new Date().toISOString());
  }
}

That's almost right, but every single line needs a touch-up:

Drop standalone: true (it's the default now)
Remove CommonModule
Swap @Input() / @Output() for input() / output()
And replace *ngIf with @if
And add OnPush change detection

Doing that by hand every time is slow, inconsistent, and worst of all, a guaranteed source of drift across a team.

Of course we can continue running the old component generation schematic but it's not as flexible as using AI.

The New Way: Project-Level Cursor Skills

Cursor Skills allow us to define reusable workflows that are committed directly into our source code.

This ensures every developer on the team follows the same standards.

Step 1: Setting Up the Skills Directory

We create a .cursor/skills directory in our project root.

Inside, we add a folder for each skill.

In this case we'll create an angular-component-generator folder.

Inside this folder, we then need to add a SKILL.md file inside it.

It's important to note that the name "SKILL" in this file must be capitalized for Cursor to recognize it as a skill.

This file is just Markdown with a bit of frontmatter.

The frontmatter tells Cursor when to use the skill, and the body is the "training material", the conventions, a template, and an example.

Here's the shape of our component-generator skill (with the full template omitted for brevity):

---
name: angular-component-generator
description: "Generates a modern Angular standalone component using signals, OnPush change detection, native control flow, and the latest Angular conventions. Use when the user asks to create, scaffold, or generate an Angular component."
---

# Angular Component Generator

Creates a single, modern Angular component file that follows current Angular (v20+) conventions.

## Conventions to Follow

- **Standalone** — do NOT set `standalone: true` (it's the default in v20+)
- **Change detection** — always set `changeDetection: ChangeDetectionStrategy.OnPush`
- **Inputs / outputs** — use `input()` and `output()` functions, not decorators
- **State** — use `signal()` for local state, `computed()` for derived state
- **Templates** — prefer inline `template`; use `@if` / `@for` / `@switch`
- **Injection** — use the `inject()` function, not constructor injection
- **Selector** — kebab-case with an `app-` prefix
- **Class name** — PascalCase ending in `Component`

## Workflow

1. Confirm the component name with the user (if not provided).
2. Generate the file using the template below.
3. Only split into separate `.html` / `.css` files if they're large enough to justify it.

## Template

// ... a reference template the AI uses as a starting point ...

## Don'ts

- Don't add `standalone: true`
- Don't use `NgModule`
- Don't use `@Input()` / `@Output()` decorators
- Don't use `*ngIf` / `*ngFor` / `*ngSwitch`
- Don't import `CommonModule` just to use control flow

The full version is in the project repo, but notice the pattern:

Describe the conventions
Provide a template
And list the things you never want to see

That last section is the one that makes the biggest difference in practice.

It directly counters the AI's default habits.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 2: Running the Skill

To use the skill, we open a new chat and invoke it by typing a forward slash followed by the skill name:

Cursor reads our SKILL.md and asks for anything missing.

In this case it looks like we need to provide some more information:

So here's what I added:

Then, after it does its work, we've got a new component:

Here's what the generated code looks like:

import { ChangeDetectionStrategy, Component, input, output } from '@angular/core';

@Component({
  selector: 'app-hello-world',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <section class="hello-world">
      <h2>Hello, world</h2>
      <p class="hello-world__date">{% raw %}{{ todayDate() }}{% endraw %}</p>
      <button type="button" (click)="emitUpdateTime()">Update time</button>
    </section>
  `,
  styles: `
    .hello-world {
      display: block;
    }

    .hello-world__date {
      margin: 0.5rem 0;
    }
  `,
})
export class HelloWorldComponent {
  readonly todayDate = input.required<string>();
  readonly updateTime = output<string>();

  protected emitUpdateTime(): void {
    this.updateTime.emit(new Date().toISOString());
  }
}

Compare that to the generic version from earlier:

No standalone: true
No CommonModule
No decorators
And no *ngIf

Exactly the code we would have spent time hand-editing, or following up with AI, generated for us in one shot.

Automating Unit Tests

And skills compose nicely.

Once we have one for generating components, the obvious next move is a matching skill for generating their tests.

For this we create a second folder, add-component-unit-tests, with its own SKILL.md that encodes how our team writes specs:

And here's what the code for that skill might look like (the spec template is abbreviated below for brevity):

---
name: add-component-unit-tests
description: Evaluates an Angular standalone component and generates unit tests that cover its inputs, outputs, signals, computed values, methods, and template behavior following unit-testing best practices. Use when the user asks to add, generate, scaffold, or write unit tests for an Angular component.
---

# Add Angular Component Unit Tests

Creates a `.component.spec.ts` file next to an Angular component that covers its public API and rendered behavior using Angular's `TestBed` and Jasmine.

## Assumptions

- Angular v20+ standalone components (no `NgModule`, no `standalone: true`).
- Inputs/outputs declared with `input()` / `input.required()` / `output()`.
- State with `signal()` and derived state with `computed()`.
- Native control flow (`@if`, `@for`, `@switch`) in templates.
- Host bindings/listeners declared via the `host` object.
- `ChangeDetectionStrategy.OnPush`.

## Workflow

1. **Read the component file** to build an inventory of inputs, outputs, signals, computed values, methods, host bindings, template elements, and injected dependencies.
2. **Derive the test plan** using the Test Plan Heuristics below. Briefly list the cases you will cover before writing code.
3. **Write the spec file** at `<folder>/<name>.component.spec.ts` using the Spec Template.
4. **Follow the Best Practices** — one behavior per test, arrange-act-assert, no snapshot tests for signals, no testing of private implementation details.
5. **Do not modify the component** to make it testable unless the user asks. If something is genuinely untestable, flag it instead of refactoring silently.

## Test Plan Heuristics

For each component, generate tests from this checklist. Skip categories that don't apply.

- **Creation**: component compiles and renders with required inputs set.
- **Inputs**: required inputs render the provided value; optional inputs use defaults; input changes propagate via `componentRef.setInput(...)` + `detectChanges()`.
- **Outputs**: each `output()` emits with the expected payload when its trigger fires.
- **Signals / computed**: initial value, updates when dependencies change, edge cases (empty, null, boundary).
- **Methods**: each method produces its documented side effect.
- **Template**: `@if` both branches, `@for` empty / one / many, `@switch` each case, event bindings, class/style bindings.
- **Host**: host classes, attributes, and listeners behave correctly.
- **Dependencies**: injected services replaced with fakes/spies via `providers`.

## Spec Template

// ... a reference spec template with TestBed setup, setInput for required inputs,
//     and sections for inputs / outputs / signals / template ...

## Best Practices

- **One behavior per test.** Each `it` asserts a single observable outcome.
- **Arrange / Act / Assert** — keep the three phases visually separated.
- **Test public behavior, not implementation.** Drive the component through inputs and DOM events; assert on outputs, rendered DOM, and public signals. Never test `private` members directly.
- **Use `setInput`, not field assignment.** Signal inputs must be set via `fixture.componentRef.setInput(name, value)`.
- **Call `fixture.detectChanges()`** after every state change that should affect the view.
- **Query the DOM with `By.css`** and assert against `textContent`, attributes, or element presence — not on stringified HTML.
- **Stub dependencies.** Replace injected services with jasmine spy objects via `{ provide: X, useValue: ... }` in `providers`.
- **Async.** Use `fakeAsync` + `tick` for timers, `await fixture.whenStable()` for promises.
- **No snapshot tests** for templates — write explicit assertions.
- **Deterministic.** No reliance on real dates, random values, or network. Inject or freeze those.
- **Descriptive names.** `it('emits selected with the row id when the row is clicked')`, not `it('works')`.

## Don'ts

- Don't assign signal inputs directly (`component.foo = ...`) — use `setInput`.
- Don't use `TestBed.overrideComponent` just to swap a template.
- Don't test `private` or `protected` members by casting to `any`.
- Don't assert on CSS selectors that include Angular-generated attributes (`_ngcontent-...`)
- Don't write a single giant `it` that exercises every behavior.
- Don't re-test framework behavior (that `@Input` works, that `output()` emits at all) — test your component's use of it.
- Don't modify the component under test to make it easier to test without asking first.

The full version, including the complete spec template and a worked example, is in the project repo.

Notice the same pattern as before:

Assumptions
A workflow
A template
Best practices
And a list of don'ts.

The don'ts are what stop the AI from falling back to legacy patterns like assigning signal inputs with component.foo = ... or casting to any to poke at private members.

With that in place, we run /add-component-unit-tests against our HelloWorldComponent and get a full spec file that seeds the required signal input, exercises the output with a payload assertion, and verifies the rendered template:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { By } from '@angular/platform-browser';
import { HelloWorldComponent } from './hello-world.component';

describe('HelloWorldComponent', () => {
  let fixture: ComponentFixture<HelloWorldComponent>;
  let component: HelloWorldComponent;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [HelloWorldComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(HelloWorldComponent);
    component = fixture.componentInstance;
    fixture.componentRef.setInput('todayDate', 'Monday, April 20, 2026');
    fixture.detectChanges();
  });

  it('creates', () => {
    expect(component).toBeTruthy();
  });

  describe('inputs', () => {
    it('renders the provided todayDate value', () => {
      const el = fixture.debugElement.query(By.css('.hello-world__date')).nativeElement;
      expect(el.textContent).toContain('Monday, April 20, 2026');
    });

    it('reflects updates to todayDate', () => {
      fixture.componentRef.setInput('todayDate', 'Tuesday, April 21, 2026');
      fixture.detectChanges();

      const el = fixture.debugElement.query(By.css('.hello-world__date')).nativeElement;
      expect(el.textContent).toContain('Tuesday, April 21, 2026');
    });
  });

  describe('outputs', () => {
    it('emits updateTime exactly once when the button is clicked', () => {
      const emitSpy = spyOn(component.updateTime, 'emit');
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;

      button.click();

      expect(emitSpy).toHaveBeenCalledTimes(1);
    });

    it('emits an ISO-formatted string as the updateTime payload', () => {
      const emitSpy = spyOn(component.updateTime, 'emit');
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;

      button.click();

      expect(emitSpy).toHaveBeenCalledWith(
        jasmine.stringMatching(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/),
      );
    });
  });

  describe('template', () => {
    it('renders the heading', () => {
      const heading = fixture.debugElement.query(By.css('h2')).nativeElement;
      expect(heading.textContent).toContain('Hello, world');
    });

    it('renders the date inside the .hello-world__date element', () => {
      const date = fixture.debugElement.query(By.css('.hello-world__date'));
      expect(date).not.toBeNull();
    });

    it('renders a button with the correct type and label', () => {
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;
      expect(button.type).toBe('button');
      expect(button.textContent).toContain('Update time');
    });
  });
});

A lot of the skill's rules are baked into this output:

The hardcoded date isn't magic, it comes from the setInput call in beforeEach. The skill enforces seeding required signal inputs before the first detectChanges, so the template has the data it needs to render.
The inputs block covers both the initial render and how the component responds to setInput updates, not just "does it work once?" but "does it react to change?"
The outputs block goes beyond "was it called?" and also asserts on the payload shape with jasmine.stringMatching(...).
The template block queries the rendered DOM for each meaningful element, heading, date container, button, rather than stringifying HTML or relying on snapshots.

All of that comes out of the box because we told the AI once, in the skill, how we expect our team's specs to look.

And then, we can run npm test to see the tests pass:

Skills vs. Rules: When to Use Which

If you're already using Cursor Rules (.cursor/rules/) or AGENTS.md, you might be wondering where Skills fit in.

The short version:

Rules are always-on guidance. They apply automatically to every request that matches their scope.
Skills are on-demand workflows. You invoke them explicitly when you want that specific behavior.

Rules are great for baseline conventions ("we use signals in this repo").

Skills are great for repeatable, parameterized tasks ("scaffold a new component", "generate tests for this file") where you want a guided, interactive workflow instead of passive nudging.

Final Thoughts: Automating Angular Workflows with Cursor Skills

Here’s the real takeaway: with skills, Cursor isn’t just generating code, it’s letting you encode how your team builds software.

And this is just the beginning.

Because next, we could apply something like this to migrate an existing reactive form over to signal forms, which gets way more interesting!

Get Ahead of Angular's Next Shift

And speaking of signal forms, they’re still pretty 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.

You can access it either directly or through YouTube membership, depending on what works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Better Numeric Inputs in Angular (Signal Forms + Angular 22)

Brian Treese — Fri, 17 Apr 2026 13:00:00 +0000

Signal Forms just fixed a subtle, but important, issue you’ve likely shipped without realizing. If you’re using <input type="number">, it's likely that you're introducing UX issues that only show up during real interaction. In this example, I'll show you a better approach that will be available in Angular v22.

Why Number Inputs Break UX in Angular Forms

Let's start with a typical setup.

We have a typed form model where age is a number and can be null:

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

Then we have a signal-backed model to store the form data where the age field is initialized to null:

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

After this, we have the form configuration created with the form() function from the Signal Forms API and our model signal:

protected signupForm = form(this.model, s => {
  required(s.username, { message: 'Username is required' });
  required(s.email, { message: 'Email is required' });
  required(s.age, { message: 'Age is required' });
});

This form is already setup with basic required() validators for the username, email, and age fields.

So this is what we're starting with.

Now let's finish adding the logic for the age field.

First, we want to prevent folks from joining if they're under 18, so let's add a min() validator.

min(s.age, 18, { message: 'You must be at least 18' });

Then, we want to ensure the age entered is valid.

If it's greater than 120, it's probably not valid, so let's add a max() validator:

max(s.age, 120, { message: 'Please enter a valid age' });

That’s all we need here.

Now let’s switch over to the template and add the field itself.

Since age will always be a number, we should use a number input, right?

Let's try it!

We'll add a number type input and bind it to the age field using the formField directive.

<input 
  type="number" 
  [formField]="signupForm.age" />

Now, this probably looks correct, but it really isn’t.

This is one of those cases where the default looks right but causes subtle issues in real use.

For one, the browser will automatically add a spinner control to the input:

These are rarely useful except in cases where you actually have an incremental number.

Which maybe you could argue we have here, but who wants to enter their age this way?

Also, if you use your mousewheel over the input, it will change the value too.

In our case this isn't too bad but think of something like a postal code or credit card CVV number.

It just wouldn't make sense.

And this isn't just something I'm making up, MDN explicitly recommends avoiding number inputs in many cases.

So, let's switch over to the recommended approach.

Step 1: Switch to a Text Input

For this, all we need to do is replace this:

<input 
  type="number" 
  [formField]="signupForm.age" />

With this:

<input 
  type="text" 
  inputmode="numeric" 
  [formField]="signupForm.age" />

This removes browser-controlled behavior while still triggering the numeric keyboard on mobile thanks to the inputmode attribute.

At this point (pre-Angular 22), this breaks typing:

Step 2: Angular 22 Fix: Number ↔ Text Binding

Previously, with Signal Forms:

Text input → string
Model expects → number | null
Result → type mismatch

Angular 22 fixes this.

After upgrading, Signal Forms:

Accept text inputs for numeric fields
Convert values to number
Map empty input to null (not '')

This is the key improvement.

Step 3: Keep Validation in the Schema

If we want to strictly adhere to the MDN guidance we would add attributes like these:

<input 
  pattern="[0-9]*" 
  min="18" 
  max="120" />

But these aren’t needed here.

With Signal Forms:

Validation belongs in the schema
Template stays declarative

So we'll keep the validation where we have it, and we'll remove these attributes.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 4: Restrict Input via Keyboard Handling

According to MDN, browsers are inconsistent at enforcing numeric input, even with the correct inputmode.

So we need to enforce it ourselves.

To do this, we'll add a (keydown) event handler to the input.

We'll call it onAgeKeydown and it will take a KeyboardEvent parameter.

<input
  type="text"
  inputmode="numeric"
  [formField]="signupForm.age"
  (keydown)="onAgeKeydown($event)"
/>

Then, we'll switch over to the component TypeScript and add this new method:

protected onAgeKeydown(event: KeyboardEvent) {
  const allowedKeys = [
    'Backspace',
    'Delete',
    'Tab',
    'Escape',
    'Enter',
    'ArrowLeft',
    'ArrowRight'
  ];

  if (allowedKeys.includes(event.key)) {
    return;
  }

  if (!/^\d$/.test(event.key)) {
    event.preventDefault();
  }
}

This ensures:

Only digits are entered
Navigation keys still work

The Final Result

So now, we no longer have the spinner UI or scroll-wheel side effects:

We still can't add any non-numeric characters.

If we add invalid age values, we'll get the validation errors we added earlier:

Then, when we clear the field, we'll get the correct null value:

Previously, a text field would give you an empty string, but Angular now handles the conversion to null for us perfectly!

Clean, Typed Numeric Input in Angular 22

<input type="number"> looks correct but introduces avoidable UX issues.

Angular 22 removes the main blocker:

You can bind numeric models to text inputs cleanly
You retain strict typing and schema validation

For real applications, this is the better default (in many cases):

type="text"
inputmode="numeric"
Schema validation
Explicit keyboard handling

It’s a small change that eliminates a class of subtle UX bugs that often slip through reviews.

Taking This Further with Signal Forms

This example is just one piece of what Signal Forms are starting to simplify.

If you want to go deeper, I put together a full course that walks through building real-world forms step by step.

You can access it either directly or through YouTube membership, depending on what works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

How to Get Specific Validation Errors with Angular Signal Forms

Brian Treese — Fri, 10 Apr 2026 07: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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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

Brian Treese — Fri, 03 Apr 2026 07: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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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

Brian Treese — Fri, 27 Mar 2026 07: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!

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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

Brian Treese — Fri, 20 Mar 2026 07: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!

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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?

Brian Treese — Fri, 13 Mar 2026 07: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 { ..., 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 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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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

Brian Treese — Fri, 06 Mar 2026 08: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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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.

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 Signal Forms: Number Inputs Finally Fixed in Angular 21.2

Brian Treese — Fri, 27 Feb 2026 08: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.

The Starting Point: A Simple Signup Form

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>{{ error.message }}</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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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.

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 Signal Forms: The New formRoot Directive Explained

Brian Treese — Fri, 20 Feb 2026 08: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.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

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.

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

DEV Community: Brian Treese

Angular’s New injectAsync() API Explained

The Problem: Libraries Loading Too Early

Understanding the Markdown Service and its Eager Usage

The Old Way: Manually Lazy Loading an Angular Service

The New Way: Replacing Boilerplate with injectAsync()

Prefetch Lazy Dependencies with onIdle

The Final Result

Get Ahead of Angular's Next Shift

Additional Resources

Angular 22 @Service vs @Injectable (What You Need to Know)"

Version Disclaimer

The Problem: Overly Complex Service Declaration

The New Way: Angular 22 @Service() and inject()

Step 1: Replacing @Injectable with @Service

Step 2: Enforcing inject() for Dependencies

Step 3: Component-Scoped Services with autoProvided: false

The Final Result

Get Ahead of Angular's Next Shift

Additional Resources

This completely changed my Angular development workflow

The Problem: Fixing "Almost Right" Code

The Old Way: Manual Refactoring

The New Way: Project-Level Cursor Skills

Step 1: Setting Up the Skills Directory

Step 2: Running the Skill

Automating Unit Tests

Skills vs. Rules: When to Use Which

Final Thoughts: Automating Angular Workflows with Cursor Skills

Get Ahead of Angular's Next Shift

Additional Resources

Better Numeric Inputs in Angular (Signal Forms + Angular 22)

Why Number Inputs Break UX in Angular Forms

Step 1: Switch to a Text Input

Step 2: Angular 22 Fix: Number ↔ Text Binding

Step 3: Keep Validation in the Schema

Step 4: Restrict Input via Keyboard Handling

The Final Result

Clean, Typed Numeric Input in Angular 22

Taking This Further with Signal Forms

Additional Resources

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

The New Way: Angular 22 `@Service()` and `inject()`

Step 1: Replacing `@Injectable` with `@Service`

Step 2: Enforcing `inject()` for Dependencies

Step 3: Component-Scoped Services with `autoProvided: false`

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