DEV Community: Brian Treese

The Angular @switch Upgrades You Should Know About

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

Angular's @switch block has become a lot more useful recently. With exhaustive type checking, Angular can now catch missing template states when a TypeScript union or enum changes. And with grouped cases, we can remove duplicate markup when multiple states render the same UI. In this post, I'll show both improvements using a real-world example.

The Problem: UI States Can Drift from Your Types

Let's start with a common pattern.

We have a support queue where each ticket has a status:

There are four possible statuses, and we’re modeling them with a TypeScript union:

type TicketStatus =
  | 'new'
  | 'in-progress'
  | 'resolved'
  | 'closed';

interface Ticket {
  id: number;
  title: string;
  customer: string;
  status: TicketStatus;
}

Then, we have a signal containing a list of tickets:

protected readonly tickets = signal<Ticket[]>([
  {
    id: 1024,
    title: 'User cannot reset password',
    customer: 'Acme Corp',
    status: 'new',
  },
  {
    id: 1025,
    title: 'Billing page shows incorrect total',
    customer: 'Northstar Health',
    status: 'in-progress',
  },
  {
    id: 1026,
    title: 'Exported report is missing rows',
    customer: 'Velocity Labs',
    status: 'resolved',
  },
  {
    id: 1027,
    title: 'Login button disabled after failed attempt',
    customer: 'Summit Bank',
    status: 'closed',
  },
  {
    id: 1028,
    title: 'Production checkout error for enterprise account',
    customer: 'Atlas Retail',
    status: 'new',
  }
]);

So far, this is simple enough.

The status is strongly typed, and every ticket has to use one of the values from the TicketStatus union.

Now let's look at the template.

A Basic Angular @switch Block

In the template, we're looping over the tickets with @for and rendering each one as a card.

Inside each card, we use an Angular @switch block to render the status badge:

@switch (ticket.status) {
  @case ('new') {
    <span class="badge active">Active</span>
  }
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved') {
    <span class="badge done">Done</span>
  }
  @case ('closed') {
    <span class="badge done">Done</span>
  }
}

Then, a little lower in the card, we have another @switch block for the status message:

@switch (ticket.status) {
  @case ('new') {
    <p class="status-message active">
      This ticket is new and needs to be triaged.
    </p>
  }
  @case ('in-progress') {
    <p class="status-message active">
      Someone is actively working on this issue.
    </p>
  }
  @case ('resolved') {
    <p class="status-message done">
      The issue has been resolved and is waiting for confirmation.
    </p>
  }
  @case ('closed') {
    <p class="status-message done">
      This ticket is closed and no further action is needed.
    </p>
  }
}

This works, but there's a subtle problem.

Neither @switch block has a default case.

That means if the status ever becomes something other than these four values, Angular won't render anything for that part of the UI.

No badge.

No message.

Just a quiet little bug.

And those are the worst kind.

Adding a New Union Value

Now let's say the product changes.

We need to support urgent tickets, so we add a new status called "escalated":

type TicketStatus =
  | 'new'
  | 'in-progress'
  | 'resolved'
  | 'closed'
  | 'escalated';

Then we update one of the tickets to use the new status:

{
  id: 1028,
  title: 'Production checkout error for enterprise account',
  customer: 'Atlas Retail',
  status: 'escalated',
}

TypeScript is happy.

The app still compiles.

And at first glance, everything looks fine.

But when the escalated ticket renders, the card is incomplete:

The ticket title and customer show up, but the badge and message are missing because neither @switch block handles the new value.

The type changed.

The data changed.

But the template didn't keep up.

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

Exhaustive @switch Checking with @default never

This is where the newer @switch behavior helps.

Instead of adding a normal fallback UI, we can add this:

@default never;

This tells Angular that if the @switch reaches the default case, there should be no possible value left to handle.

So the badge @switch becomes this:

@switch (ticket.status) {
  @case ('new') {
    <span class="badge active">Active</span>
  }
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved') {
    <span class="badge done">Done</span>
  }
  @case ('closed') {
    <span class="badge done">Done</span>
  }
  @default never;
}

Now Angular can type-check the @switch exhaustively.

Since TicketStatus includes escalated, but the template doesn't handle it yet, Angular reports an error:

That's the win.

Instead of silently rendering broken UI, Angular forces us to update the template when the union type changes.

This is especially useful for UI states like:

ticket statuses
order states
payment states
deployment states
user invite states
feature flag states

Any time a known set of values drives intentional UI, exhaustive checking is worth considering.

To fix the error, we just need to add the missing escalated case in both @switch blocks.

Cleaning Up Duplicate @case Blocks

Now that the @switch is safer, let's make it cleaner.

In the badge @switch, new and in-progress both render the same badge:

@case ('new') {
  <span class="badge active">Active</span>
}
@case ('in-progress') {
  <span class="badge active">Active</span>
}

And resolved and closed both render the same badge too:

@case ('resolved') {
  <span class="badge done">Done</span>
}
@case ('closed') {
  <span class="badge done">Done</span>
}

That duplication isn't terrible in a small example, but it gets annoying fast in real templates.

Modern Angular lets us combine consecutive cases that render the same block.

So we can rewrite the badge @switch like this:

@switch (ticket.status) {
  @case ('new')
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved')
  @case ('closed') {
    <span class="badge done">Done</span>
  }
  @case ('escalated') {
    <span class="badge escalated">Escalated</span>
  }
  @default never;
}

Angular treats those consecutive @case statements as multiple conditions for the same template block.

So new and in-progress both render the Active badge, while resolved and closed both render the Done badge.

We get the same UI, but without repeating the same markup in multiple cases.

Fewer places to forget something later.

Safer Templates, Cleaner Code

That’s the real upgrade.

The UI stays the same, but the template becomes safer, cleaner, and easier to maintain.

Exhaustive checking helps Angular catch missing states, and grouped cases help remove duplicate markup.

Small change, safer template.

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

Better Loading Buttons in Angular Material v22

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

Angular Material v22 adds a small but surprisingly useful improvement to buttons: built-in progress indicator support. Instead of manually swapping button text with a spinner and dealing with layout jumpiness, we can let the Material button directive manage the loading UI for us. In this post, I'll show you the old manual approach, why it creates a small UX issue, and how Angular Material v22 cleans it up.

A Simple Example

Let's start with a simple reports page:

We have a list of reports, and each report has a "Download" button using the matButton directive:

<section>
  <ul class="report-list">
    @for (report of reports(); track report.id) {
      <li class="report-row">
        <div class="report-info">
          <span class="report-name">{% raw %}{{ report.name }}{% endraw %}</span>
          <span class="report-meta">{% raw %}{{ report.date }} · {{ report.size }}{% endraw %}</span>
        </div>

        <button
          matButton="outlined"
          [disabled]="downloadingId() !== null"
          (click)="download(report)">
          Download
        </button>
      </li>
    }
  </ul>
</section>

Nothing unusual here.

But the loading UI is where this usually gets a little clunky.

The Old Way: Swap the Label for a Spinner

Before this new Angular Material v22 feature, a common approach was to conditionally replace the button label with a spinner.

First, we need to import the progress spinner in our component:

import { MatProgressSpinner } from '@angular/material/progress-spinner';

@Component({
  selector: 'app-report-list',
  templateUrl: './report-list.component.html',
  styleUrl: './report-list.component.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [MatButton, MatProgressSpinner],
})
export class ReportListComponent {
  // ...
}

Then we can update the button template to include the progress spinner conditionally when the report is downloading and the label when it isn't:

<button
  matButton="outlined"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  @if (downloadingId() === report.id) {
    <mat-progress-spinner
      mode="indeterminate"
      [diameter]="20"
      aria-label="Downloading"
    />
  } @else {
    Download
  }
</button>

Since this download doesn't expose a real percentage, mode="indeterminate" is the right fit here.

The diameter keeps the spinner small enough to fit inside the button, and the aria-label gives assistive technologies meaningful loading-state text since the visible label is being replaced.

And this works fine:

When the report is downloading, we show a spinner.

When it isn't, we show the label.

But there's still a UX issue.

The button shrinks when the label disappears and only the spinner remains.

That's because we're swapping the button's content entirely.

The text has one width, the spinner has another, and the button resizes to fit whatever is currently rendered.

It's not broken, but it feels a little janky.

And we had to write the conditional content logic ourselves.

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 Angular Material v22 Way: Use `showProgress` and `progressIndicator`

Angular Material v22 gives us another option.

Instead of swapping the label and spinner manually, both can live inside the button at the same time:

<button
  matButton="outlined"
  [showProgress]="downloadingId() === report.id"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  <mat-progress-spinner
    progressIndicator
    mode="indeterminate"
    [diameter]="20"
    aria-label="Downloading"
  />
  Download
</button>

There are two important pieces here.

First, the button gets the showProgress input, which is new in Angular Material v22:

[showProgress]="downloadingId() === report.id"

This tells the matButton directive when the progress UI should be shown.

In this case, we only want progress on the button for the report currently being downloaded.

Then, the spinner gets the progressIndicator attribute:

<mat-progress-spinner progressIndicator />

This marks the spinner as the button's projected progress indicator.

So instead of us writing an @if block to decide what appears, Angular Material controls that progress indicator slot for us.

Why This Feels Better

The important detail is that the normal button content stays in the layout, even when the progress indicator is visible.

So the button still knows how wide the "Download" label is, even while the spinner is being displayed.

That means we avoid the width jump caused by replacing the content completely.

The end result is a loading button that feels stable instead of jumpy.

This Does Not Have to Be a Material Spinner

One nice part of this API is that progressIndicator is a projection slot.

That means the projected content doesn't have to be mat-progress-spinner specifically.

You could use a custom loading element if that fits your design system better.

The main thing is to make sure the progress indicator still communicates meaningful loading-state information, especially when the visible button label is hidden or visually replaced.

Cleaner Loading Buttons in Angular Material

This is one of those Angular Material updates that isn't huge, but it's immediately useful.

The old approach works, but it usually means manually swapping content and accepting small layout issues.

With showProgress and progressIndicator, Angular Material gives us a built-in pattern for loading buttons that feels more polished with less template logic.

Want to Go Deeper With Modern Angular?

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 v22 WebMCP Tools Explained

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

Angular v22 is experimenting with a new way to expose your app’s real capabilities to AI. Instead of letting models guess what's happening by scraping the DOM, we can now provide explicit, state-backed tools directly to the browser. This post walks through setting up WebMCP tools to bridge the gap between your Angular state and AI models like Gemini.

The Problem: AI Is Blind to App State

Most AI interactions with web apps today are limited to what the model can “see” in the rendered page.

This is brittle, surface-level, and completely misses the rich business logic living inside our services and signals.

Here's an example of a basic Angular app with no WebMCP tools registered:

We're using the WebMCP Inspector to see what tools are available and in this case, there are none:

In this app, we have data that doesn’t always live in the DOM, like retention risk calculations and hidden account metrics, that could help an AI provide much better assistance.

Without a structured way to expose these capabilities, the AI is just left guessing.

The Solution: Angular Signal State

Before we can give the AI tools, we need a clean source of truth.

In this app, we're using a UserStore service to manage our customer data.

We're using the new @Service() decorator and signals to expose profile information and computed business rules.

import { computed, Service, signal } from '@angular/core';
import { USER_ACCOUNTS, type UserKey } from './user.mock-data';

@Service()
export class UserStore {
  private readonly selectedUserKeyState = signal<UserKey>('sarah');

  readonly users = [
    { key: 'sarah', user: USER_ACCOUNTS.sarah.user },
    { key: 'marcus', user: USER_ACCOUNTS.marcus.user },
  ] as const;

  readonly selectedUserKey = this.selectedUserKeyState.asReadonly();
  readonly currentUser = computed(() => USER_ACCOUNTS[this.selectedUserKey()].user);
  readonly account = computed(() => USER_ACCOUNTS[this.selectedUserKey()].account);
  readonly isHighRiskAccount = computed(() => {
    const account = this.account();

    return (
      account.daysSinceLastLogin > 14 ||
      account.paymentFailures > 0 ||
      account.unresolvedPriorityTickets > 0
    );
  });

  selectUser(userKey: UserKey): void {
    this.selectedUserKeyState.set(userKey);
  }
}

The isHighRiskAccount signal is exactly the kind of "hidden" logic that an AI wouldn't know about just by looking at the UI.

It provides a clear, computed state based on multiple factors.

Creating WebMCP Tools with provideWebMcpTools()

Angular v22 introduces provideWebMcpTools(), a new API that registers WebMCP tools through the provider system.

This is powerful because these tools run inside the Angular injection context, meaning they can use dependency injection to access our services and signals.

Since this is still experimental, I’d treat this as a preview of where Angular and browser-based AI tooling are heading rather than a production recommendation today.

In this case, we register our tools globally in app.config.ts, but you should also be able to use it in route providers too:

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

export const appConfig: ApplicationConfig = {
  providers: [
    provideWebMcpTools([])
  ]
};

Each tool needs a name, a description for the AI to understand when to use it, an inputSchema, and an execute function.

Tool 1: Summarize the Current Customer

This tool provides a basic summary of the currently selected user.

It's intentionally simple to demonstrate the core wiring: Gemini asks for a summary, and Angular returns the current signal state.

{
  name: 'get_current_user_summary',
  description: 'Returns a summary of the current user.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const user = inject(UserStore).currentUser();

    return {
      content: [
        {
          type: 'text',
          text: `Name: ${user.name}
            Email: ${user.email}
            Plan: ${user.plan}
            Status: ${user.status}
            Last login: ${user.lastLogin}
            Open tickets: ${user.openTickets}`,
        },
      ],
    };
  },
},

Notice how the execute function directly injects UserStore and reads the currentUser signal.

The AI isn't scraping the DOM, it's calling a tool that accesses real Angular application state.

Tool 2: Analyze Retention Risk

This tool analyzes the current account and explains its retention risk.

It leverages the isHighRiskAccount computed signal we defined earlier.

{
  name: 'get_retention_risk',
  description: 'Analyzes the current account and explains retention risk.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const store = inject(UserStore);
    const user = store.currentUser();
    const account = store.account();
    const isHighRisk = store.isHighRiskAccount();

    return {
      content: [
        {
          type: 'text',
          text: isHighRisk ?
            // Is high risk
            `${user.name} is currently considered high risk.

            Reasons:
            - ${account.daysSinceLastLogin} days since last login
            - ${account.paymentFailures} recent payment failures
            - ${account.unresolvedPriorityTickets} unresolved priority ticket

            Recommended next action:                  
            Have customer success schedule a live onboarding session.` :

            // Is low risk
            `${user.name} is currently considered low risk.

            No significant warning signs detected.

            Recommended next action:
            No immediate action needed.`
        },
      ],
    };
  },
},

This demonstrates how the AI can use app-defined business logic to determine a customer’s risk level, providing actionable insights based on our application's internal state.

Tool 3: Draft a Customer Success Note

The third tool drafts a customer success outreach note.

The message content dynamically changes based on whether the isHighRiskAccount signal is true or false.

{
  name: 'draft_customer_success_note',
  description: 'Drafts a customer success outreach note for the current account.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const store = inject(UserStore);
    const user = store.currentUser();
    const isHighRisk = store.isHighRiskAccount();

    return {
      content: [
        {
          type: 'text',
          text: isHighRisk ? 
            // Is high risk
            `Hi ${user.name},

            I noticed you may have run into a few issues recently, and I wanted to reach out personally to see if we can help.

            If you'd like, we can schedule a quick onboarding session to walk through the platform and help resolve any blockers.

            Thanks,
            Customer Success Team` : 

            // Is low risk
            `Hi ${user.name},

            Just wanted to check in and make sure everything is still going smoothly.

            Thanks for being a customer, and let us know if there’s anything we can help with.

            Thanks,
            Customer Success Team`
        },
      ],
    };
  },
}

This tool showcases how the same underlying Angular state can power multiple AI-callable capabilities, leading to context-aware and personalized AI responses.

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

Testing with the Inspector

Once registered, all three tools appear in the WebMCP Model Context Tool Inspector:

This allows the AI to see exactly what capabilities our app provides.

We can also see that Gemini already understands the tools available and has filled out the prompt for us:

When we ask Gemini questions like "Can you summarize this customer account?":

or "Is this customer at risk?":

or "Draft a follow-up message for this customer":

It doesn't try to scrape the page.

It calls the appropriate WebMCP tool, reads the signal state, and gives an accurate answer based on our actual business logic.

Why WebMCP Tools Matter for Angular Apps

By exposing app-defined capabilities, we turn the browser into a collaborative environment where the AI understands the context of our application.

The AI response changes as the underlying signal state changes.

This is the real value of WebMCP in Angular: safe, explicit, and reactive AI capabilities backed by your existing services and logic.

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’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

DEV Community: Brian Treese

The Angular @switch Upgrades You Should Know About

The Problem: UI States Can Drift from Your Types

A Basic Angular @switch Block

Adding a New Union Value

Exhaustive @switch Checking with @default never

Cleaning Up Duplicate @case Blocks

Safer Templates, Cleaner Code

Get Ahead of Angular's Next Shift

Additional Resources

Better Loading Buttons in Angular Material v22

A Simple Example

The Old Way: Swap the Label for a Spinner

The Angular Material v22 Way: Use showProgress and progressIndicator

Why This Feels Better

This Does Not Have to Be a Material Spinner

Cleaner Loading Buttons in Angular Material

Want to Go Deeper With Modern Angular?

Additional Resources

Angular v22 WebMCP Tools Explained

The Problem: AI Is Blind to App State

The Solution: Angular Signal State

Creating WebMCP Tools with provideWebMcpTools()

Tool 1: Summarize the Current Customer

Tool 2: Analyze Retention Risk

Tool 3: Draft a Customer Success Note

Testing with the Inspector

Why WebMCP Tools Matter for Angular Apps

Get Ahead of Angular's Next Shift

Additional Resources

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 Angular Material v22 Way: Use `showProgress` and `progressIndicator`

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