DEV Community: Rajat

Angular Is Preparing for AI Agents: WebMCP, MCP Tooling, and Agent Skills in Angular 22 - - What Changes in NG 22 (Part 10)

Rajat — Tue, 08 Sep 2026 13:30:00 +0000

How Angular 22 lets AI coding agents build your app faster, debug it live, and — with WebMCP — actually call it like a tool

What if an AI agent didn't just help you write your Angular app, but could also use it directly once it's running — clicking through a form, listing your users, creating a record — the same way it would call an API? That's not a hypothetical anymore. Angular 22 ships real, if early, plumbing for exactly that, alongside a quieter but more immediately useful set of tools that make AI coding agents genuinely better at writing Angular code today.

This is a genuinely confusing area of the release if you only skim the changelog, because "AI features" in Angular 22 actually means two very different things bundled together. One half is about agents that help you build and debug your app. The other half — WebMCP — is about your app becoming something an agent can operate on its own. We're going to untangle both, with working code for each. By the end you'll know:

What Agent Skills are and how they change what your coding agent does when it generates Angular code
How the Angular CLI's MCP server plugs your agent into your actual project instead of its training data
How Angular exposes a live signal graph and dependency injection graph for AI-assisted debugging
What WebMCP is, and how to declare a tool an agent can call directly from a component
How to auto-generate a WebMCP tool straight from a Signal Form
How to unit test the logic behind a WebMCP tool like you would any other method

If you've been following this series on Angular 22 — the stable Resource API, the router changes, the template improvements — this is the odd one out, and arguably the one worth paying closest attention to if you think agentic tooling is going to matter for frontend work over the next couple of years.

Quick ask before we get into it: this is a fast-moving corner of the framework, and I'll be writing more as WebMCP matures past experimental status. Follow along here if you'd rather not have to go digging for the next update yourself.

Before we dive into the examples, a quick note: the code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular versions, and a few APIs covered here are explicitly experimental as of this writing. Always refer to the official documentation for the most current API and syntax.

Two different problems, both labeled "AI"

Worth being precise about this before any code, because the two halves of Angular's AI story solve genuinely different problems:

Agents that build and debug your app. This is the Angular CLI's MCP server, the new Agent Skills, and in-browser debugging tools exposed through Chrome DevTools. None of this ships in your production bundle — it's tooling that makes Claude, or whichever coding agent you use, better at working inside an Angular codebase.
Your app as something an agent can operate. This is WebMCP. It ships in your application code, and it's about exposing specific capabilities — "list users," "create a booking" — that an agent visiting your site can call directly, instead of having to simulate clicks on your UI.

Let's take them in that order.

Agent Skills: teaching your coding agent how Angular actually works

The Angular CLI has shipped an MCP server since v20.1, giving coding agents a way to interact with your project directly rather than guessing from general training data. Angular 22 adds Agent Skills on top of that — a packaged set of guidelines that teach an agent how to generate idiomatic, current Angular code and provide architectural guidance, rather than falling back on outdated patterns it may have picked up from older tutorials.

npx skills add https://github.com/angular/skills

That command installs two skills: one focused on scaffolding new Angular projects correctly, and a second, broader one covering code generation and architecture guidance across the framework. Once installed, an agent working in your repository picks up the relevant skill automatically when you ask it to generate Angular code — you don't have to reference it explicitly in every prompt.

One side effect worth knowing about: with skills now handling code-generation guidance, the CLI's MCP server dropped its find_examples and modernize tools, since the skill covers that ground more thoroughly than a lookup tool could. If you had scripts or workflows depending on those specific tools, that's worth double-checking after upgrading.

Debugging with AI: exposing the signal graph and the DI graph

Angular 22 also registers two debugging tools that a development build exposes for tooling to consume: a signal graph and a dependency injection graph, the same data Angular DevTools already visualizes. These are registered in Chrome DevTools as third-party tools, which means an agent connected through chrome-devtools-mcp can query your application's actual runtime state — which signals exist, how they're connected, what's injected where — instead of trying to infer it from source code alone.

This does need a bit of setup, since third-party DevTools tools require enabling specific MCP flags, but once wired up, an agent debugging a signal that isn't updating the way you expect can look at the real dependency graph rather than guessing from a stack trace.

WebMCP: your app as a tool an agent can call

Here's the part that's genuinely new territory. WebMCP is a proposed web standard — not an Angular-specific idea — that lets a website expose Model Context Protocol capabilities directly from the page itself. Instead of an agent needing a separate MCP server running somewhere on your machine or in the cloud, the website becomes the tool: an agent visiting your app can call a capability you've explicitly exposed, the same way it would call any other MCP tool.

As of this release it's early: WebMCP is only available behind a flag in Chrome Beta, and the Angular APIs built around it are explicitly marked experimental. That said, the shape of the API is worth understanding now, because it's a genuinely different way to think about what a component exposes.

Declaring a tool imperatively

declareExperimentalWebMcpTool(), available in @angular/core, lets you register a callable tool directly inside a component.

import { Component, inject } from '@angular/core';
import { declareExperimentalWebMcpTool } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-users',
  template: `<p>User management is available to connected agents.</p>`,
})
export class Users {
  constructor() {
    declareExperimentalWebMcpTool({
      name: 'list_users',
      description: 'List users with a specific status',
      inputSchema: {
        type: 'object',
        properties: {
          status: { type: 'string', enum: ['ADMINS', 'STUDENTS'] },
        },
        required: ['status'],
        additionalProperties: false,
      },
      execute: ({ status }) => {
        return inject(UserService).list(status);
      },
    });
  }
}

Two things worth calling out. First, inject() works inside the tool's execute function, so the tool can lean on Angular's dependency injection exactly like any other piece of component logic — you're not reaching outside the framework to wire this up. Second, Angular destroys the tool automatically when the component is destroyed, so a tool scoped to a page that's no longer active stops being callable without any manual cleanup on your part.

If you'd rather register a tool at the application level instead of tying it to a specific component's lifecycle, provideExperimentalWebMcpTool() does that from your app config.

import { ApplicationConfig } from '@angular/core';
import { provideExperimentalWebMcpTool } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideExperimentalWebMcpTool([
      {
        name: 'list_users',
        description: 'List users with a specific status',
        inputSchema: {
          type: 'object',
          properties: {
            status: { type: 'string', enum: ['ADMINS', 'STUDENTS'] },
          },
          required: ['status'],
          additionalProperties: false,
        },
        execute: ({ status }) => {
          return inject(UserService).list(status);
        },
      },
    ]),
  ],
};

Would you actually expose write operations — creating or deleting records — through something like this today, or only read-only capabilities until the standard and the tooling around it mature? I lean toward read-only for now, but I'm curious where other people draw that line.

The declarative path: auto-registering tools from Signal Forms

The second half of WebMCP's proposal is a declarative API, where a plain HTML form gets marked up with toolname and tooldescription attributes to become agent-callable automatically. Angular's Signal Forms integrate with this directly, so if your form is already built with form(), you don't need to hand-write a schema at all.

Enable it once, at the application level:

import { ApplicationConfig } from '@angular/core';
import { provideExperimentalWebMcpForms } from '@angular/forms/signal';

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

Then describe the tool as part of the form definition itself:

import { Component, signal } from '@angular/core';
import { form, required } from '@angular/forms/signals';

interface NewUser {
  name: string;
  email: string;
}

@Component({
  selector: 'app-user-creation',
  template: `
    <form>
      <input [formField]="userForm.name" placeholder="Name" />
      <input [formField]="userForm.email" placeholder="Email" />
    </form>
  `,
})
export class UserCreation {
  protected readonly model = signal<NewUser>({ name: '', email: '' });

  protected readonly userForm = form(
    this.model,
    (path) => {
      required(path.name);
      required(path.email);
    },
    {
      experimentalWebMcpTool: {
        name: 'user_creation',
        description: 'Form to create a new user',
      },
    },
  );
}

Angular takes care of the rest: it generates the tool's input schema from the form fields themselves, and when an agent calls the tool, it fills the form with the provided input and submits it — the same validation your human users go through applies to the agent too. That last part matters more than it might seem: an agent can't bypass your required() and other validators just because it's calling the form programmatically instead of clicking through it.

Testing the logic behind a WebMCP tool

You don't need anything WebMCP-specific to test this — the execute function of a tool is just a function, and the interesting behavior almost always lives in the service it delegates to. Test that directly.

import { TestBed } from '@angular/core/testing';
import { UserService } from './user.service';

describe('UserService list()', () => {
  it('returns only users matching the requested status', () => {
    TestBed.configureTestingModule({
      providers: [UserService],
    });

    const service = TestBed.inject(UserService);
    const admins = service.list('ADMINS');

    expect(admins.every((user) => user.status === 'ADMINS')).toBe(true);
  });
});

For the Signal Forms version, the thing actually worth testing is that the form's own validation still runs correctly — since that's exactly what protects you when an agent submits the form instead of a person.

import { TestBed } from '@angular/core/testing';
import { UserCreation } from './user-creation';

describe('UserCreation form', () => {
  it('is invalid when required fields are empty', () => {
    const fixture = TestBed.createComponent(UserCreation);
    fixture.detectChanges();

    const formState = fixture.componentInstance'userForm';
    expect(formState.invalid()).toBe(true);
  });

  it('is valid once name and email are filled in', () => {
    const fixture = TestBed.createComponent(UserCreation);
    const component = fixture.componentInstance;

    component['model'].set({ name: 'Ada Lovelace', email: 'ada@example.com' });
    fixture.detectChanges();

    const formState = component'userForm';
    expect(formState.invalid()).toBe(false);
  });
});

Neither test touches WebMCP directly, and that's deliberate — the tool declaration is just a thin wrapper around logic you should already be testing regardless of whether an agent or a person is the one triggering it.

Bonus tips

Treat experimental APIs as exactly that. declareExperimentalWebMcpTool, provideExperimentalWebMcpTool, and provideExperimentalWebMcpForms all carry the experimental naming for a reason — expect the shape of these APIs to shift before they stabilize, and avoid building critical functionality on top of them just yet.
Scope tools to the narrowest lifecycle that makes sense. A component-level tool that's cleaned up automatically on destroy is usually safer than an app-wide one that stays registered for the entire session.
Pair route-level providers with withExperimentalAutoCleanupInjectors. If you're registering WebMCP tools through route-scoped providers, this router feature ensures the tools — and everything else in that environment injector — are actually torn down when the user navigates away, rather than lingering.
Read-only tools are the lower-risk place to start. Exposing a "list" or "search" capability carries a lot less downside than exposing something that mutates data, especially while the surrounding security model for WebMCP is still taking shape.
The Agent Skills package is worth adopting even if you have no interest in WebMCP. It's the part of this release most likely to quietly improve your day-to-day experience, since it changes what your coding agent produces by default, not just what your production app can do.

Recap

Angular 22's AI story splits cleanly into two halves once you look past the shared label: Agent Skills and the CLI's MCP server make coding agents better at building and debugging your app, while WebMCP is about your running app exposing capabilities an agent can call directly. The first half is low-risk and immediately useful — install the skills package and your agent's output quietly gets better. The second half is early, genuinely experimental, and worth understanding now specifically so you're not starting from zero once it stabilizes.

If you're curious where this goes next, keep an eye on how the WebMCP standard itself matures outside of Angular — the framework APIs here are clearly built to track it closely, which means they'll likely keep changing until the underlying browser proposal settles down.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular 22.2 Finally Lets Your Templates Touch Private Class Members

Rajat — Tue, 01 Sep 2026 13:30:00 +0000

The compiler error you have been silently working around for years is about to disappear

Have you ever marked a component property private for good reason, only to have the Angular compiler throw an error the second you reference it in the template? You end up doing the same little dance every time: change private to protected, feel slightly annoyed that your encapsulation is now weaker than you wanted, and move on.

Angular 22.2 removes that friction. Templates, host bindings, and directive metadata can now read private class members directly, without the compiler getting in the way. It sounds like a small change, but if you have ever fought with isolatedDeclarations, or just wanted to keep a signal truly private, this one is worth understanding properly.

By the end of this article you will know:

Exactly what changed in the compiler, and what did not
Why nested private members still throw an error (and why that is intentional)
How this plays with host bindings and directives, not just component templates
Why this matters if your project uses TypeScript's isolatedDeclarations
How to write unit tests for components that rely on private state
A few practical tips for deciding when private is still the right call

If you want to follow along or dig into the source change yourself, the feature shipped through this compiler pull request, authored by Angular team member Jean Meche and merged in mid-August 2026.

Before we go further, if this kind of practical, no-fluff Angular breakdown is useful to you, consider following along here on Medium. I write these as soon as something lands in the framework, not months later.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular/React versions. Always refer to the official documentation for the most current API and syntax.

What Actually Changed in Angular 22.2

Let's start with the simplest case. Here is a counter component the way most of us would want to write it, with the internal count kept private:

// counter.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <div class="counter">
      <p>Count: {{ count() }}</p>
      <button (click)="increment()">Add one</button>
    </div>
  `,
})
export class CounterComponent {
  private count = signal(0);

  increment(): void {
    this.count.update((value) => value + 1);
  }
}

Before 22.2, that {{ count() }} binding in the template would fail at compile time. count is private, and the template technically lives outside the class, so the compiler treated it like any other external caller trying to reach into a private field. The usual workaround was bumping the field to protected, which works, but quietly widens your API surface to every subclass, whether you wanted that or not.

As of Angular 22.2, this compiles cleanly. The team's approach was straightforward: catch the private-access error during type checking and discard it specifically for direct members on the component instance. Your private keyword still does its job everywhere else in your TypeScript code. It just stops blocking the one consumer, the template, that Angular already controls and compiles alongside your class.

Nested Private Members Still Throw an Error

This is the part worth paying close attention to, because it is easy to assume the compiler just stopped caring about private members entirely. It did not. The relaxed rule only applies to members accessed directly on this inside the component's own template. Reach one level deeper, into a private member of some other object, and the old error comes right back.

// address.ts
export class Address {
  private zipCode = '10001';

  get formatted(): string {
    return `ZIP: ${this.zipCode}`;
  }
}

// profile.component.ts
import { Component } from '@angular/core';
import { Address } from './address';

@Component({
  selector: 'app-profile',
  template: `
    <!-- This still fails to compile in Angular 22.2 -->
    <p>{{ address.zipCode }}</p>

    <!-- This is fine, since formatted() is public -->
    <p>{{ address.formatted }}</p>
  `,
})
export class ProfileComponent {
  address = new Address();
}

address.zipCode is private on the Address class, not on ProfileComponent, so it is still off-limits from the template. That distinction matters: Angular is not dissolving encapsulation between arbitrary classes, it is only trusting the template compiler with access to the component's own instance, since the template and the class are already tightly coupled by design.

Private Members Work in Host Bindings Too

The same relaxed rule extends to the host metadata object and to directives, not just component templates. That is genuinely useful, because host bindings often reference internal state that has no business being public.

// toggle-panel.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-toggle-panel',
  template: `<ng-content />`,
  host: {
    '[class.is-open]': 'isOpen()',
    '(click)': 'toggle()',
  },
})
export class TogglePanelComponent {
  private isOpen = signal(false);

  toggle(): void {
    this.isOpen.update((value) => !value);
  }
}

Before 22.2, isOpen would have needed to be protected just so the host binding could read it. Now it can stay exactly as private as it should be, while the host binding and the click handler both work as expected.

Why This Matters for isolatedDeclarations

If your project runs with isolatedDeclarations: true, you already know the trade-off: TypeScript requires you to explicitly annotate the type of nearly every class property, since it can no longer infer types across file boundaries during declaration emission. Private members were traditionally exempt from that requirement, which quietly encouraged people to keep template-only properties private just to avoid writing redundant type annotations. Except that clashed directly with the old compiler rule that blocked private access from templates.

Here is what that tension looked like before 22.2:

// search-box.component.ts (before Angular 22.2)
export class SearchBoxComponent {
  // Had to be explicitly typed to satisfy isolatedDeclarations,
  // AND had to be protected instead of private so the template could read it
  protected query: string = '';

  onInput(value: string): void {
    this.query = value;
  }
}

With 22.2, you get to have both things you actually wanted, real encapsulation and less typing:

// search-box.component.ts (Angular 22.2)
export class SearchBoxComponent {
  private query = ''; // type is inferred, template can still read it
  private results = signal<string[]>([]);

  onInput(value: string): void {
    this.query = value;
  }
}

That is a small but meaningful quality-of-life fix if you work in a codebase that leans on isolatedDeclarations for faster builds.

Quick question for you before we move on: have you run into the protected-just-for-the-template workaround in your own projects, or do you tend to keep your components' internals public by default? Drop a comment, I am curious how common this pattern actually is across different teams.

Testing Components with Private State

One reasonable worry with this change is testing. If a property is private, should your tests be reaching into it directly? The honest answer is no, and that has not changed. The right way to test a component is still through its public contract, the DOM it renders and the events it emits, not by casting into private fields from your spec file.

Here is a full test for the counter component above:

// counter.component.spec.ts
import { TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

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

  it('should render a starting count of zero', () => {
    const fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges();

    const paragraph: HTMLParagraphElement =
      fixture.nativeElement.querySelector('p');

    expect(paragraph.textContent).toContain('0');
  });

  it('should increment the count when the button is clicked', () => {
    const fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges();

    const button: HTMLButtonElement =
      fixture.nativeElement.querySelector('button');
    button.click();
    fixture.detectChanges();

    const paragraph: HTMLParagraphElement =
      fixture.nativeElement.querySelector('p');

    expect(paragraph.textContent).toContain('1');
  });
});

Notice that the test never touches component.count directly, it reads the rendered DOM instead, exactly the way a user would experience the component. That is worth internalizing: this compiler change makes private members usable from the template, it does not make them a good target for direct test assertions. Keep testing through the public surface, and this change becomes invisible to your test suite, in a good way.

Bonus Tips

A few practical notes to take with you:

Do not treat this as a reason to make everything private by default without thinking. Private is for internal implementation detail. If a subclass or another part of your codebase legitimately needs the value, protected or a public getter is still the right tool.
If you maintain a component library, this change means you can now tighten your public API surface retroactively in places where you had only used protected to satisfy the template compiler. Worth a pass through older components once you upgrade.
Signals pair particularly well with this change. A private writable signal with no public setter, only read through the template and mutated through explicit methods, is a clean pattern that this update makes fully first-class.
Remember this only applies to Angular's own template compiler. If you are writing custom tooling, schematics, or static analysis that inspects component classes, do not assume private members are inaccessible from templates going forward.

Recap

Angular 22.2, expected to land in September 2026, allows component templates, host bindings, and directive metadata to read private class members directly, as long as those members belong to the component or directive instance itself. Reach into a private member of some other, unrelated object through your template, and the compiler still stops you, which is exactly the boundary you want. The change also quietly resolves an awkward conflict for teams using isolatedDeclarations, where private fields used to force a choice between type-annotation overhead and template access. None of this changes how you should test your components: keep asserting against the rendered output, not the internals.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment, I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect, find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular 22.1 Is Out — Here's Every Feature Worth Your Attention

Rajat — Tue, 25 Aug 2026 13:30:00 +0000

A practical, code-first walkthrough of the new release cadence, the @Service() migration, linkedSignal's custom setter, untracked interceptors, and what it all means for your next sprint

Quick question before we dive in: when was the last time you upgraded Angular and actually used the new stuff within the same week, instead of bookmarking the changelog and forgetting about it?

If you are like most of us, minor releases fly by. We update the version number, run the tests, ship, and move on. Angular 22.1 is one of those releases that is easy to skim past — it is not a major version, there is no big migration guide, no press release. But tucked inside it are a handful of changes that quietly fix real pain points: a migration schematic for the new @Service() decorator, a smarter linkedSignal, interceptors that stop leaking into your effects, and — maybe the biggest news of all — a completely new release schedule that changes how every Angular team should plan the next two years.

In this article we will go feature by feature, with runnable code, so you walk away knowing exactly what changed and how to use it today.

By the end of this article, you will know:

Why Angular is moving to one major release per year, and what that means for your upgrade planning
How to migrate existing services to @Service() with a single CLI command
How linkedSignal's new custom setter gives you control over writes without losing derived state
Why your effects were secretly re-running because of HTTP interceptors, and how 22.1 fixes it
How to write unit tests for signal-based, standalone components using current Angular syntax
Whether this is worth its own follow-up series (spoiler: probably yes, and I want your vote on it)

All examples below use standalone components, the new control-flow syntax (@if, @for), and signals. No NgModule, no *ngIf, no *ngFor, no @Input() decorators pretending to be modern. If you have been burned by outdated tutorials before, this one is current as of Angular 22.1.0.

Got a preference on how deep we go? Drop a comment before you finish reading — I am deciding whether to turn this into a five-part deep-dive series, and your input actually shapes what gets written next.

1. The Big One: Angular Is Switching to a Yearly Major Release

Let's start with the change that is not really a "feature" but affects everyone who has ever groaned at an ng update breaking something two Fridays before a release.

Since Angular 4, the team has shipped a major version every six months. As of 22.1, that is over.

Here is what changes concretely:

One major version per year, landing every June
Version 23 is now expected in June 2027, not November 2026 as the old cadence would have suggested
Version 24 follows in June 2028, and so on
Each major version gets two years of support instead of eighteen months
Minor releases keep shipping roughly every two months, so expect four to six minors between majors

If you manage upgrade cadence for a team, this is worth putting straight into your roadmap. Fewer major-version scrambles, longer support windows, and a predictable June release date instead of guessing whether the next breaking change lands before or after your quarterly freeze.

Discussion point: does a slower major cadence make your team more comfortable upgrading promptly, or does it just mean bigger, scarier majors when they finally land? I would genuinely like to know how your team plans upgrades — tell me in the comments.

2. Migrating to @Service() Without Touching Every File by Hand

Angular 22 introduced the @Service() decorator as a leaner alternative to @Injectable({ providedIn: 'root' }). The CLI has been generating new services with it since then, but there was no automated way to migrate services you had already written. That gap is closed in 22.1.

Run this from your project root:

ng generate @angular/core:service

It takes code like this:

import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class UserService {
  getCurrentUser() {
    // fetch logic here
  }
}

And rewrites it to this:

import { Service } from '@angular/core';

@Service()
export class UserService {
  getCurrentUser() {
    // fetch logic here
  }
}

A bare @Injectable() with no arguments becomes @Service() the same way.

The schematic is deliberately conservative. It will skip:

Services that rely on constructor-based dependency injection patterns it cannot safely rewrite
Services passing options other than providedIn
Anything where providedIn is not 'root'

That is a good thing. A migration tool that silently changes DI scope in a large codebase is a migration tool nobody trusts. Run it with --dry-run first so you know exactly how many files are affected before committing to the change.

ng generate @angular/core:service --dry-run

If this saved you from writing a regex-based codemod at 5 p.m. on a Friday, that is exactly the kind of small win worth a clap — it tells me these practical, "here is the command, here is the diff" breakdowns are what you want more of.

3. linkedSignal Gets a Custom Setter

If you have not used linkedSignal yet, here is the short version: it behaves like computed, except you can also write to it directly. That makes it perfect for "selected item" style state that should reset whenever its source list changes, but also needs to be manually overridable by the user.

readonly items = signal<Array<ItemModel>>([]);
protected readonly selectedItem = linkedSignal(() => this.items()[0]);

Every time items changes, selectedItem recalculates to the first item — unless you write to it yourself, in which case your write wins until the source changes again.

What was missing was control over what happens when someone writes to it. Angular 22.1 adds a set option for exactly that:

protected readonly selectedItem = linkedSignal(() => this.items()[0], {
  set: (item: ItemModel) => {
    const items = this.items();
    if (items.indexOf(item) < 0) {
      this.items.set([item, ...items]);
    }
  }
});

Now, writing an item that is not already in the list adds it to the front instead of silently failing or producing an inconsistent state. This is the kind of API that looks small in a changelog and saves you an entire custom wrapper class in practice.

Here is a full standalone component putting it together, using the current control-flow syntax:

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

interface ItemModel {
  id: number;
  name: string;
}

@Component({
  selector: 'app-item-picker',
  template: `
    <ul>
      @for (item of items(); track item.id) {
        <li
          [class.active]="item.id === selectedItem().id"
          (click)="selectedItem.set(item)">
          {{ item.name }}
        </li>
      }
    </ul>

    @if (selectedItem(); as selected) {
      <p>Selected: {{ selected.name }}</p>
    }

    <button (click)="addAndSelect()">Add new item</button>
  `,
})
export class ItemPickerComponent {
  readonly items = signal<Array<ItemModel>>([
    { id: 1, name: 'Draft' },
    { id: 2, name: 'Review' },
  ]);

  protected readonly selectedItem = linkedSignal(() => this.items()[0], {
    set: (item: ItemModel) => {
      const items = this.items();
      if (items.indexOf(item) < 0) {
        this.items.set([item, ...items]);
      }
    },
  });

  addAndSelect() {
    const newItem: ItemModel = { id: Date.now(), name: 'New Task' };
    this.selectedItem.set(newItem);
  }
}

Note there is no standalone: true anywhere in that decorator — that has been the default for a while now, and Angular 22.1 keeps pushing the ecosystem further away from writing it explicitly.

4. HTTP Interceptors No Longer Leak Into Your Effects

This one is subtle, and if you have ever debugged an effect that seemed to re-run "for no reason," it might explain a few lost hours.

effect() automatically tracks every signal it reads. Before 22.1, that tracking extended into whatever your HTTP interceptors read too. So an effect that triggered an HTTP call was silently depending on any signal your interceptors happened to touch — an auth token signal, a locale signal, a feature flag signal, anything.

As of Angular 22.1, interceptors run untracked by default. Your effects now re-run only for reasons you actually intended.

If you still need fine-grained control inside an effect, untracked() remains your explicit escape hatch:

effect(() => {
  const value = this.mySignal();
  untracked(() => {
    // read other signals here without creating a dependency
  });
});

The difference in 22.1 is that you no longer need to reach for untracked() just to stop your interceptors from becoming invisible dependencies. That happens automatically now.

Have you hit a "why does this effect keep firing" bug before? I would bet money at least one of you has traced it back to something exactly like this. Tell me about it in the comments — misery loves company, and so does debugging content.

5. Smaller but Genuinely Useful: DevTools Improvements

Two changes landed in Angular DevTools alongside 22.1:

You can now search the signal graph by name and by type, using syntax like type:computed. If you have ever opened DevTools on a component with forty signals trying to find the one causing a re-render, this alone is worth the update.
The transfer state panel is now visible by default, instead of being tucked away, making SSR debugging noticeably less annoying.

Neither of these needs a code sample. They just need you to open DevTools after upgrading and notice they are there.

Testing It All: Unit Tests for Signal-Based Standalone Components

Since we are using signals and standalone components throughout, let's write tests that match. Here is a unit test for the ItemPickerComponent above, using TestBed with the current standalone-first testing API:

import { TestBed } from '@angular/core/testing';
import { ItemPickerComponent } from './item-picker.component';

describe('ItemPickerComponent', () => {
  let component: ItemPickerComponent;

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

    const fixture = TestBed.createComponent(ItemPickerComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('selects the first item by default', () => {
    expect(component'selectedItem'.name).toBe('Draft');
  });

  it('updates selection when an existing item is clicked', () => {
    const items = component.items();
    component['selectedItem'].set(items[1]);

    expect(component'selectedItem'.name).toBe('Review');
  });

  it('adds a new item to the list when selecting one that does not exist yet', () => {
    const beforeCount = component.items().length;
    component.addAndSelect();

    expect(component.items().length).toBe(beforeCount + 1);
    expect(component'selectedItem'.name).toBe('New Task');
  });
});

Because we import the standalone component directly into imports rather than declaring it, there is no NgModule boilerplate to maintain. If your team has started moving its Angular test suite to Vitest, the same tests run with only the runner changed — describe, it, and expect stay identical, which is one more reason the standalone-plus-signals combination pairs so well with modern testing setups.

A Bonus Tip Before You Go

If you are on Angular 22 already, the upgrade to 22.1 should be uneventful:

ng update @angular/core @angular/cli

Run the @Service() migration schematic in dry-run mode right after upgrading, even if you are not planning to use it immediately. It costs nothing, and it gives you a concrete count of how much of your codebase is migration-ready — useful ammunition the next time someone asks "how much technical debt do we actually have."

Recap

Angular 22.1 is a minor release doing a lot of quiet, practical work:

A new yearly major release schedule with two-year support windows, replacing the six-month cadence Angular has used since version 4
An automated schematic to migrate @Injectable() services to @Service()
A custom set option for linkedSignal, giving you control over writes without losing derived, reactive defaults
HTTP interceptors now run untracked, fixing a subtle source of unnecessary effect re-runs
DevTools gained signal-graph search and a default-visible transfer state panel

None of these are headline-grabbing on their own. Together, they are the kind of release that makes the next twelve months of Angular development a little less error-prone.

There is genuinely enough depth here — especially in the @Service() migration internals and linkedSignal patterns — to justify splitting into a dedicated mini-series, one feature per article, if that is more digestible than one long read. I am leaning toward doing that. More on this below.

What did you think?

Which of these five changes actually affects your day-to-day work the most — the release schedule, the @Service() migration, linkedSignal, the interceptor fix, or DevTools? Drop a comment and tell me, or vote for the topic you want covered in its own deep-dive next.

Found this helpful? If it saved you from digging through five different changelog pages yourself, that is exactly what a clap tells me to keep doing — hit it so more Angular developers find this.

Want more breakdowns like this, written the week a release actually lands instead of months later? Follow for more Angular and React content, or subscribe to get new articles delivered directly when they publish.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular Templates Just Got More Powerful — Here's What Angular 22 Actually Changed - What Changes in NG 22 (Part 9)

Rajat — Tue, 18 Aug 2026 13:30:00 +0000

Template comments, spread syntax, arrow functions, and stricter type checking that catches bugs before they ship

Ever tried to leave a quick note in an Angular template — just a one-line reminder for future you — and given up because there was no clean way to do it without breaking the compiler? Small annoyances like that pile up over the years, and Angular 22 quietly clears out a handful of them at once.

This isn't a flashy release for templates. There's no new control-flow block, no new directive. What you get instead is a set of small, practical improvements that make templates read more like the TypeScript you already write, plus a stricter compiler that catches mistakes it used to wave through. In this article we'll go through all of it hands-on. By the end you'll know:

How to actually write comments inside your templates without weird workarounds
How object spread, array spread, and rest arguments now work in template expressions
How to use arrow functions directly in event bindings and @for loops
What strictTemplates being on by default means for your existing codebase
How exhaustive @switch checks catch missing cases at compile time
How to write tests that exercise these template features, not just describe them

If you've read my other pieces on this release — the stable Resource API and the router changes — this one rounds things out with the part of Angular 22 that shows up in literally every component you write. If this is the first one you've landed on, don't worry, it stands on its own.

Before we get into the code: if small, practical Angular deep dives like this are useful to you, following me here means you catch the next one instead of relying on the algorithm to surface it for you.

Before we dive into the examples, a quick note: the code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular versions. Always refer to the official documentation for the most current API and syntax.

Comments inside HTML elements

Until this release, you could comment out a chunk of template with , but you couldn't drop a comment inside an element's attribute list the way you'd comment a function call in TypeScript. Angular 22 adds support for both block and line comments directly inside an element definition.

<div
  // primary button, styled from the design system
  class="btn btn-primary"
  /*
    Note: disabled state only reflects the loading signal,
    not the form's overall validity.
  */
  [disabled]="loading()"
>
  Save changes
</div>

This is a small thing, but it matters most in exactly the situation shown above: a long attribute list where a binding's intent isn't obvious from its name alone. Instead of hunting through a component's TypeScript file to figure out why [disabled] is wired up the way it is, the explanation lives right where you're reading the template.

Spread syntax and rest arguments in templates

Template expressions can now use object spread, array spread, and rest arguments — syntax that used to be limited to your TypeScript classes.

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

@Component({
  selector: 'app-tag-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div [class]="{ ...baseClasses, active: isActive() }">
      @for (tag of [...preferredTags, ...extraTags]; track tag) {
        <span class="tag">{{ tag }}</span>
      }
    </div>

    <p>Total: {{ sum(...scores()) }}</p>
  `,
})
export class TagList {
  protected readonly baseClasses = { card: true, rounded: true };
  protected readonly isActive = signal(true);
  protected readonly preferredTags = ['angular', 'signals'];
  protected readonly extraTags = ['templates', 'v22'];
  protected readonly scores = signal([10, 25, 40]);

  protected sum(...values: number[]): number {
    return values.reduce((total, value) => total + value, 0);
  }
}

Three things are happening in that snippet, all of them things you'd normally reach for a component method to do:

{ ...baseClasses, active: isActive() } merges a static class map with a reactive one, directly in the [class] binding.
[...preferredTags, ...extraTags] combines two arrays inline for the @for loop, instead of precomputing a merged array as a class property.
sum(...scores()) spreads a signal's array value straight into a function call.

None of these are things you couldn't do before — you'd just have written a getter or a computed signal to do the merging in TypeScript instead. This syntax mostly saves you from writing small, single-use helper properties whose only job was working around a template limitation.

Arrow functions in event bindings and loops

Template expressions can now include arrow functions with an implicit return, which is genuinely useful inside @for loops where you want to call a method with something specific to the current item.

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

interface Task {
  id: number;
  title: string;
  done: boolean;
}

@Component({
  selector: 'app-task-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @for (task of tasks(); track task.id) {
      <label>
        <input
          type="checkbox"
          [checked]="task.done"
          (change)="toggle((t) => t.id === task.id)"
        />
        {{ task.title }}
      </label>
    }
  `,
})
export class TaskList {
  protected readonly tasks = signal<Task[]>([
    { id: 1, title: 'Write the article', done: false },
    { id: 2, title: 'Review the code samples', done: false },
  ]);

  protected toggle(matches: (task: Task) => boolean): void {
    this.tasks.update((current) =>
      current.map((task) => (matches(task) ? { ...task, done: !task.done } : task)),
    );
  }
}

A couple of constraints to keep in mind: arrow functions with a block body — (x) => { ... } — aren't supported in templates, and you can't use a pipe inside the arrow function's body. The compiler is also smart about identity: an arrow function that only touches its own parameters gets hoisted to the module level so it isn't recreated on every change detection cycle, while one that closes over the template context is kept stable per view. You don't have to think about this while writing the template, but it's good to know your event bindings aren't secretly reallocating functions on every render.

While we're on the topic — have you found other spots where an inline arrow function actually reads better than pulling logic into a component method, or do you still prefer keeping templates as logic-free as possible? I go back and forth on this one myself.

Stricter type checking, on by default

Angular 22 turns strictTemplates on by default, so you get full strict type checking in templates without adding anything to tsconfig.json. If you're upgrading an older project, a migration adds strictTemplates: false automatically to preserve your existing behavior — worth flipping back on deliberately once you've had a chance to fix whatever it surfaces.

Two new compile-time checks come along with this tightening. The first catches an element matched by more than one component:

[ERROR] NG8023: Multiple components match node with tagname pr-menu: 'Menu', 'OtherMenu'. [plugin angular-compiler]

That used to be a runtime surprise. Now it's a build failure, which is a much better place for it to live. The second catches inputs, outputs, or models that collide under an alias:

@Component({ /* ... */ })
export class ProfileCard {
  readonly user = input('');
  readonly user2 = input('', { alias: 'user' });
}

✘ [ERROR] NG1054: Input 'user' is bound to both 'user' and 'user2'. [plugin angular-compiler]

Exhaustive `@switch` checks

Pairing well with stricter type checking, @switch can now enforce that every case of a union type is handled, using @default never.

@Component({
  selector: 'app-session-banner',
  template: `
    @switch (state) {
      @case ('loggedOut') { <button>Log in</button> }
      @case ('loading')   { <p>Checking your session…</p> }
      @case ('loggedIn')  { <p>Welcome back!</p> }
      @default never;
    }
  `,
})
export class SessionBanner {
  protected state: 'loggedOut' | 'loading' | 'loggedIn' = 'loggedOut';
}

If someone later adds 'banned' to that union without adding a matching @case, the compiler flags it immediately instead of letting the new state silently fall through to nothing being rendered. Angular 22 extends this to discriminated unions on a nested property, using never(expression) to tell the compiler exactly which union it should check for full coverage:

@Component({
  selector: 'app-panel',
  template: `
    @switch (state.mode) {
      @case ('show') { <p>Menu item {{ state.menu }}</p> }
      @case ('hide') {}
      @default never(state);
    }
  `,
})
export class Panel {
  protected state!: { mode: 'show'; menu: number } | { mode: 'hide' };
}

This kind of check is exactly the sort of thing that's easy to skip in a code review — a new variant added to a type definition three files away from the template that renders it — and exhaustiveness checking turns that into a build error instead of a silent gap in the UI.

One more type-checking improvement worth knowing: optional chaining in templates now follows the same narrowing rules as regular TypeScript, so this compiles cleanly in Angular 22 without needing a redundant ?. on the second access:

@if (user?.profile?.name) {
  <p>{{ user.profile.name }}</p>
}

Previously, the compiler couldn't tell that the @if guard already ruled out user or user.profile being null, so you had to repeat the safe-navigation operator even where it wasn't logically necessary. If you're upgrading from an older version, be aware that project?.author used to evaluate to null when project was nullish, but now follows JavaScript semantics and evaluates to undefined instead — the migration wraps existing expressions in a $safeNavigationMigration() helper automatically so this change doesn't silently alter behavior in code that specifically checked for null.

Testing template behavior, not just describing it

These are compiler-level features, so the most useful tests aren't testing the syntax directly — they're testing that the component behaves the way the template implies it should. Here's a test for the task list from earlier, confirming the arrow-function-based toggle actually flips the right item.

import { TestBed } from '@angular/core/testing';
import { TaskList } from './task-list';

describe('TaskList', () => {
  it('toggles only the task that was clicked', () => {
    const fixture = TestBed.createComponent(TaskList);
    fixture.detectChanges();

    const checkboxes = fixture.nativeElement.querySelectorAll(
      'input[type="checkbox"]',
    );
    checkboxes[1].dispatchEvent(new Event('change'));
    fixture.detectChanges();

    const component = fixture.componentInstance;
    const tasks = component'tasks';

    expect(tasks[0].done).toBe(false);
    expect(tasks[1].done).toBe(true);
  });
});

And here's one for the exhaustive @switch example — since the compiler already guarantees every case is handled, the test's job is just to confirm the right branch renders for each state.

import { TestBed } from '@angular/core/testing';
import { SessionBanner } from './session-banner';

describe('SessionBanner', () => {
  it('renders the login button when logged out', () => {
    const fixture = TestBed.createComponent(SessionBanner);
    fixture.componentInstance['state'] = 'loggedOut';
    fixture.detectChanges();

    expect(fixture.nativeElement.querySelector('button')).toBeTruthy();
  });

  it('renders the welcome message when logged in', () => {
    const fixture = TestBed.createComponent(SessionBanner);
    fixture.componentInstance['state'] = 'loggedIn';
    fixture.detectChanges();

    expect(fixture.nativeElement.textContent).toContain('Welcome back');
  });
});

Neither test is exotic — that's kind of the point. These template features are designed to remove boilerplate and catch mistakes earlier, not to introduce new things you need special tooling to verify.

Bonus tips

Turn strictTemplates back on deliberately after upgrading. The migration disables it to avoid breaking your build, but you're giving up real bug-catching by leaving it off — budget time to fix what it surfaces rather than leaving the migration's default in place indefinitely.
Use never(expression) instead of bare @default never for nested discriminants. If you switch on a property rather than the whole union, bare never can't tell the compiler what to check for exhaustiveness — you need the explicit expression form.
Don't overuse inline arrow functions for anything beyond a simple predicate. They're great for a one-line comparison like the toggle example above; if the logic grows past a single expression, move it into a component method and call that instead.
Watch for the $safeNavigationMigration() wrapper after upgrading. It's automatically added to preserve old nullish-coalescing behavior, but it's worth going through those spots by hand afterward — you can often remove it once you confirm the new undefined semantics don't change your logic.
Spread syntax is great for merging, not for hiding complexity. If a [class] binding needs to merge three or four different sources, that's usually a sign to pull the merged object into a computed() signal instead of stacking spreads in the template.

Recap

None of Angular 22's template changes are individually dramatic, but together they close a real gap between what you can express in a component's TypeScript and what you can express directly in its template. Comments make intent visible where the binding actually lives, spread syntax removes a category of throwaway helper properties, arrow functions cut down on boilerplate in loops, and the stricter compiler — especially exhaustive @switch checks — catches a class of bugs that used to only show up after someone clicked around long enough to find them.

If you're on an older Angular version, this is a good release to actually read the migration output for, rather than just running ng update and moving on — a few of these changes are quiet enough that they're easy to miss until something in your template stops compiling.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Router Changes: paramsInheritanceStrategy, Stricter Guards, and the Navigation API - What Changes in NG 22 (Part 8)

Rajat — Tue, 04 Aug 2026 13:30:00 +0000

paramsInheritanceStrategy, stricter route guards, and how the Router now talks to the browser's Navigation API

Ever written this.route.parent?.parent?.snapshot.paramMap.get('companyId') just to grab a value that lives three levels up in your route tree? If you've built anything with nested routes in Angular, you already know that particular flavor of pain — and you've probably built a workaround for it more than once.

Angular 22 quietly fixes the root of that problem, tightens up a couple of router guard contracts that used to fail silently, and leans further into the browser's own navigation model instead of reinventing it. In this article, we'll walk through what actually changed, with runnable examples for each one. By the end you'll know:

Why paramsInheritanceStrategy flipping its default is the biggest — and quietest — router change in this release
What breaks in your CanMatch guards if you upgrade without reading the migration notes
How the new withComponentInputBinding() options give you finer control over stale route inputs
How to check if a link is active using a signal instead of a directive
How the Router now integrates with the browser's native Navigation API to let you cancel an in-flight navigation
How to unit test all of the above

If you read my last piece on Angular's stable Resource API, this one is a natural follow-up — same release, different corner of the framework. And if this is your first stop, that's fine too, everything below stands on its own.

One quick ask before we get into it: if router internals like this are useful to you, following me here on Medium means the next deep dive lands in your feed instead of getting buried by the algorithm.

Before we dive into the examples, a quick note: the code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular versions. Always refer to the official documentation for the most current API and syntax.

The problem: route params that don't travel

Historically, Angular's router only merged params, data, and resolved values down to child routes under fairly narrow conditions — mainly when a route had an empty path or no component of its own. Everywhere else, a child route saw only its own params, not its ancestors'. That's why so many Angular codebases are full of route.parent.parent.snapshot chains, or duplicate the same param declaration on every child route just so a deeply nested component can read it directly.

You could always opt into different behavior with paramsInheritanceStrategy: 'always', but it was opt-in, and plenty of teams either didn't know it existed or didn't want to touch router config for one feature.

Angular 22's new default: params inherit automatically

As of Angular 22, paramsInheritanceStrategy now defaults to 'always' instead of 'emptyOnly'. Child routes inherit params, data, and resolved values from every parent route in the chain, with no configuration required. This is explicitly called out as a breaking change with no automatic migration, so it's worth checking your route guards and resolvers for any logic that assumed a child route wouldn't see a parent's params.

import { Routes } from '@angular/router';
import { CompanyDashboard } from './company-dashboard';
import { CompanyReports } from './company-reports';

export const routes: Routes = [
  {
    path: 'company/:companyId',
    children: [
      {
        path: 'dashboard',
        component: CompanyDashboard,
      },
      {
        path: 'reports/:year',
        component: CompanyReports,
      },
    ],
  },
];

With the new default, CompanyReports — nested under company/:companyId/reports/:year — can read both companyId and year directly, without Angular treating companyId as something that belongs only to the parent segment.

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

@Component({
  selector: 'app-company-reports',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <h2>Reports for company {{ companyId() }}, {{ year() }}</h2>
  `,
})
export class CompanyReports {
  // withComponentInputBinding() maps route + inherited params straight to inputs
  companyId = input.required<string>();
  year = input.required<string>();
}

That works because withComponentInputBinding() binds matched route parameters directly to component inputs, and with paramsInheritanceStrategy: 'always', inherited parent params are included in that binding too — no ActivatedRoute injection, no manual subscription, no walking up the route tree.

If you have existing code that relied on child routes not seeing parent params — some validation logic that checked a param was undefined at a certain depth, for instance — you can restore the old behavior explicitly:

import { provideRouter, withRouterConfig } from '@angular/router';
import { routes } from './app.routes';

export const appConfig = {
  providers: [
    provideRouter(routes, withRouterConfig({ paramsInheritanceStrategy: 'emptyOnly' })),
  ],
};

What's your read on defaults like this — do you think inheriting everything by default is the right call, or would you rather Angular stayed conservative and made you opt in? Genuinely curious where people land on this one.

`CanMatch` guards now require a third parameter

If you write custom CanMatch guards as classes rather than plain functions, Angular 22 makes the currentSnapshot parameter mandatory instead of optional. At runtime the Router was already always passing it — this change just makes the type system reflect reality, so a guard written against the old, looser interface won't compile anymore.

import {
  CanMatch,
  Route,
  RouterStateSnapshot,
  UrlSegment,
} from '@angular/router';
import { Injectable, inject } from '@angular/core';
import { FeatureFlags } from './feature-flags';

@Injectable({ providedIn: 'root' })
export class BetaFeatureGuard implements CanMatch {
  private readonly featureFlags = inject(FeatureFlags);

  canMatch(
    route: Route,
    segments: UrlSegment[],
    currentSnapshot: RouterStateSnapshot,
  ): boolean {
    // currentSnapshot is no longer optional — the Router always provides it
    return this.featureFlags.isEnabled('beta-dashboard');
  }
}

There's an automated migration that adds the parameter to existing guards during ng update, so this one is mostly painless — but if you've got a guard defined as a standalone function rather than a class, it's worth double-checking after upgrading.

Finer control over stale route inputs

withComponentInputBinding() picked up two configuration options in this release. The first, queryParams, is a boolean that controls whether query parameters get bound as component inputs at all — it defaults to true, matching the existing behavior.

The second, unmatchedInputBehavior, decides what happens to an input when the corresponding route data disappears on a later navigation. By default ('alwaysUndefined'), an unmatched input is always reset to undefined. The new 'undefinedIfStale' option only resets it to undefined if that input was previously populated by the router — so an input that was never meant to be router-driven doesn't get clobbered.

import { provideRouter, withComponentInputBinding } from '@angular/router';
import { routes } from './app.routes';

export const appConfig = {
  providers: [
    provideRouter(
      routes,
      withComponentInputBinding({
        queryParams: false,
        unmatchedInputBehavior: 'undefinedIfStale',
      }),
    ),
  ],
};

This is a small change, but if you've ever seen an input flicker to undefined for a single frame during a navigation and had to guard your template against it, this option exists specifically for that.

Checking active routes with a signal instead of a directive

routerLinkActive has always worked fine for styling a link in a template, but there was never a clean, reactive way to ask "is this route active" from inside component logic. Angular 22 adds isActive(), a function that returns a signal you can read directly.

import { Component, inject } from '@angular/core';
import { isActive, Router, RouterLink } from '@angular/router';

@Component({
  selector: 'app-booking-navigation',
  imports: [RouterLink],
  template: `
    <a
      [routerLink]="['./flight-search']"
      [class.active]="flightSearchActive()"
    >
      Flights
    </a>
    <a [routerLink]="['./summary']" [class.active]="summaryActive()">
      Summary
    </a>
  `,
})
export class BookingNavigation {
  private readonly router = inject(Router);

  protected readonly flightSearchActive = isActive(
    '/ticketing/booking/flight-search',
    this.router,
  );

  // exact matching for query params and path segments
  protected readonly summaryActive = isActive(
    '/ticketing/booking/summary',
    this.router,
    { paths: 'exact' },
  );
}

Because it's a signal, isActive() slots directly into @if blocks, computed(), or anywhere else you'd use a signal — which matters more than it sounds like once a component needs active-route logic for something other than a CSS class, like conditionally showing a badge or deciding whether to prefetch data for the next likely destination.

The Router talking to the browser's Navigation API

Here's the part that's easy to miss in the changelog: Angular's Router has been steadily aligning itself with the browser's native Navigation API — the modern replacement for the old History API, built specifically with single-page apps in mind. One concrete result of that work is Router.getCurrentNavigation()?.abort(), which lets you cancel a navigation that's already in progress, mirroring what happens when a site visitor clicks the browser's Stop button mid-navigation.

import { ChangeDetectionStrategy, Component, inject } from '@angular/core';
import { Router } from '@angular/router';

@Component({
  selector: 'app-slow-report-link',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <button (click)="startReport()">Open report</button>
    <button (click)="cancelNavigation()">Cancel</button>
  `,
})
export class SlowReportLink {
  private readonly router = inject(Router);

  protected startReport(): void {
    this.router.navigate(['/reports', 'quarterly']);
  }

  protected cancelNavigation(): void {
    // no-op if the navigation already finished or started activating routes
    this.router.getCurrentNavigation()?.abort();
  }
}

This is most useful when a navigation triggers a slow resolver — an expensive data fetch that gates showing the next route — and you want to give people a real way out instead of leaving them stuck watching a spinner for a page they no longer want to visit.

Testing the new router behavior

Testing router-adjacent code doesn't need to mean spinning up a full RouterTestingModule and manually driving navigation. RouterTestingHarness gives you a much more direct way to navigate to a route and inspect the resulting component.

import { TestBed } from '@angular/core/testing';
import { RouterTestingHarness } from '@angular/router/testing';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { CompanyReports } from './company-reports';

describe('CompanyReports', () => {
  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [provideRouter(routes)],
    });
  });

  it('receives inherited parent params as inputs', async () => {
    const harness = await RouterTestingHarness.create();
    const component = await harness.navigateByUrl(
      '/company/acme-42/reports/2026',
      CompanyReports,
    );

    expect(component.companyId()).toBe('acme-42');
    expect(component.year()).toBe('2026');
  });
});

Because RouterTestingHarness.navigateByUrl() drives an actual navigation through the real router configuration, this test doubles as a regression check for the paramsInheritanceStrategy default — if a future change to your route config broke param inheritance, this test would fail immediately instead of surfacing as a confusing bug in production.

For the CanMatch guard, a plain unit test against the class is usually simpler than going through the harness:

import { TestBed } from '@angular/core/testing';
import { BetaFeatureGuard } from './beta-feature.guard';
import { FeatureFlags } from './feature-flags';

describe('BetaFeatureGuard', () => {
  it('blocks matching when the flag is disabled', () => {
    TestBed.configureTestingModule({
      providers: [
        BetaFeatureGuard,
        { provide: FeatureFlags, useValue: { isEnabled: () => false } },
      ],
    });

    const guard = TestBed.inject(BetaFeatureGuard);
    const result = guard.canMatch(
      {} as never,
      [],
      {} as never, // currentSnapshot — required, but irrelevant to this guard's logic
    );

    expect(result).toBe(false);
  });
});

Ever had a guard pass code review but quietly fail to compile after a router upgrade because of a signature change like this one? Tell me about it in the comments — I'd love to know if ng update's migration caught it for you cleanly or if you had to patch it by hand.

Bonus tips

Audit resolvers before you upgrade, not after. Since inherited params now flow further down the route tree by default, a resolver that assumed it only had access to its own route's params might suddenly see more data than it expects. It's rarely harmful, but it's worth a quick read-through.
Combine isActive() with paths: 'subset' deliberately. The default subset matching is usually what you want for parent-style nav highlighting, but for anything acting like a tab — mutually exclusive views — reach for paths: 'exact' so two tabs don't both light up at once.
browserUrl on RouterLink is worth knowing about even outside this release's headline features. It lets a link navigate to one route while showing a different URL in the address bar, which is handy for canonical-URL redirects that shouldn't show the redirect target.
getCurrentNavigation()?.abort() is a no-op past a certain point. Once route activation has started, calling abort() does nothing — so don't rely on it as a way to interrupt a navigation that's already deep into rendering the next component.
Keep unmatchedInputBehavior: 'undefinedIfStale' in mind if you see input flicker in tests. A test that asserts on a bound input immediately after a partial navigation can behave differently depending on which strategy is configured — worth checking if a router config change is the reason a previously-green test started flaking.

Recap

Angular 22's router changes aren't flashy, but they fix a genuinely annoying default, tighten a guard contract that used to lie about its own types, and give you both a signal-based way to check active routes and a real hook into the browser's native navigation model. If you're upgrading, the one item that deserves actual attention is the paramsInheritanceStrategy flip — everything else is either additive or has an automated migration behind it.

If your app leans on deeply nested routes, this is a good moment to delete a few route.parent.parent chains and let the new default do the work for you.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular's Resource APIs Are Finally Stable - Say Goodbye to Manual Loading States - What Changes in NG 22 (Part 7)

Rajat — Tue, 28 Jul 2026 13:30:00 +0000

How `resource()`, `httpResource()`, and `rxResource()` in Angular 22 replace your isLoading flags with a proper signal-based data model

How many times have you written the exact same three lines in a component that fetches data — set isLoading to true, make the call, set it back to false in a finally block, and hope you didn't forget the error flag somewhere? If you've been doing Angular for more than a few months, the honest answer is probably "too many to count."

With Angular 22, that pattern finally has an official, stable answer. resource(), httpResource(), and rxResource() — which have been sitting in developer preview for a while — graduated to stable APIs in this release, alongside Signal Forms and a switch to OnPush as the default change detection strategy. Angular is clearly betting hard on a signals-first future, and resources are the missing piece that makes asynchronous data feel as natural as a computed signal.

In this article, we'll go hands-on with all three resource functions. By the end, you'll know:

Why resources exist and what problem they actually solve
How to fetch data with httpResource() using the new control flow syntax
How to chain dependent resources without nesting subscriptions
How Angular automatically cancels stale requests for you
How to write unit tests for components that use resources
A handful of bonus tricks the docs don't shout about

If you've followed my previous pieces on standalone components and signal-based state management, this one slots in nicely as the "what do I do with server data" chapter. If this is your first stop, no worries — everything here is self-contained.

One more thing before we start: if you've found pieces like this useful before, following me here on Medium means you won't miss the next one. I write about Angular internals roughly once a week, and I'd rather you find out about it than scroll past it in six months.

Before we dive into the examples, a quick note: the code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular versions. Always refer to the official documentation for the most current API and syntax.

Why resources exist in the first place

Before resources, fetching data reactively in Angular usually meant one of two things: subscribing to an HttpClient observable manually inside a component (and remembering to unsubscribe), or wiring up toSignal() on top of an RxJS pipeline just to get a value your template could read. Neither approach knew anything about loading or error states out of the box — you built that bookkeeping yourself, in every component, over and over.

A resource flips that around. You give it a reactive request — usually a function that reads one or more signals — and it gives you back an object that always knows whether it's idle, loading, resolved, or errored, without you touching a boolean anywhere. According to the official Angular v22 release notes, this stabilization is part of a broader push toward "a production-ready reactive foundation" across the framework, not just an isolated feature.

Meet `httpResource()`

The friendliest entry point is httpResource(), which lives in @angular/common/http. You pass it a function that returns a request description, and it takes care of firing the HTTP call whenever a signal inside that function changes.

import { httpResource } from '@angular/common/http';
import { ChangeDetectionStrategy, Component, signal } from '@angular/core';

interface Flight {
  id: number;
  from: string;
  to: string;
  date: string;
}

@Component({
  selector: 'app-flight-search',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input
      [value]="filter().from"
      (input)="updateFrom($event)"
      placeholder="From"
    />

    @switch (flightsResource.status()) {
      @case ('loading') {
        <p role="status">Loading flights…</p>
      }
      @case ('error') {
        <p>Something went wrong: {{ flightsResource.error() }}</p>
      }
      @case ('resolved') {
        <ul>
          @for (flight of flightsResource.value(); track flight.id) {
            <li>{{ flight.from }} → {{ flight.to }} on {{ flight.date }}</li>
          }
        </ul>
      }
      @default {
        <p>Type a city to search.</p>
      }
    }
  `,
})
export class FlightSearch {
  protected readonly filter = signal({ from: '', to: '' });

  protected readonly flightsResource = httpResource<Flight[]>(
    () => {
      const { from, to } = this.filter();
      if (!from || !to) {
        return undefined; // no request until both fields are filled
      }
      return {
        url: 'https://api.example.com/flights',
        params: { from, to },
      };
    },
    { defaultValue: [] },
  );

  protected updateFrom(event: Event): void {
    const value = (event.target as HTMLInputElement).value;
    this.filter.update((current) => ({ ...current, from: value }));
  }
}

A few things worth calling out here, because they trip people up the first time:

The generic Flight[] tells httpResource what shape to expect back, so flightsResource.value() is properly typed instead of unknown.
Returning undefined from the request function tells the resource "don't fetch anything right now" — no need for a separate guard flag.
defaultValue: [] means your template never has to deal with undefined before the first successful load.
status() gives you a more granular view than a single boolean: idle, loading, reloading, error, resolved, or local (for values you've overridden manually). The @switch block above uses exactly those states, and since Angular 22 you can pair this with @default never(...) if you want the compiler to yell at you when a new status value shows up and you forgot to handle it.

Ever built the exact same loading/error/data switch by hand in three different components in the same sprint? Tell me how you usually structure it — I'm curious whether most people reach for a shared directive or just copy-paste it.

Chaining resources without nesting subscriptions

A pattern that used to mean nested switchMap calls — "load the user, then load their posts" — is now handled by the chain() helper available inside a resource's params function. Instead of manually threading loading and error states between two resources, chain() propagates them for you.

import { httpResource } from '@angular/common/http';

interface User {
  id: number;
  authorId: number;
}

interface Post {
  id: number;
  title: string;
}

const userResource = httpResource<User>(() => `/api/users/${userId()}`);

const postsResource = httpResource<Post[]>({
  params: ({ chain }) => {
    const user = chain(userResource);
    return { url: `/api/posts`, params: { authorId: user.authorId } };
  },
});

If userResource is still loading, postsResource automatically reports itself as loading too — you never see a flash of "no posts found" while the user is still in flight. If userResource errors out, postsResource errors with a dedicated ResourceDependencyError instead of silently trying to fetch posts for a user that doesn't exist. That's a genuinely nice ergonomic win over manually forwarding state between two separate subscriptions.

You don't need to worry about race conditions anymore

Here's the part that usually gets a "wait, really?" reaction from people used to RxJS. If your request signal changes quickly — someone typing in a search box, for instance — and a newer request resolves before an older one, resources automatically discard the stale response. Only the result of the most recent request is ever applied, which mirrors what switchMap gives you in RxJS, except you get it for free with no operator to remember.

This matters more than it sounds. Race-condition bugs from out-of-order responses are one of those things that pass code review because they're invisible until a slow network connection surfaces them in production.

`rxResource()` — for when you're not ready to leave RxJS behind

Not every data source maps cleanly to a single HTTP call. If you're wrapping a WebSocket, a polling interval, or an existing RxJS-based service, rxResource() lets you build a resource around any Observable-returning function instead of a plain HTTP request.

import { rxResource } from '@angular/core/rxjs-interop';
import { inject, signal } from '@angular/core';
import { FlightService } from './flight.service';

export class FlightSearchWithRx {
  private readonly flightService = inject(FlightService);
  protected readonly airportCode = signal('HAM');

  protected readonly flightsResource = rxResource({
    params: () => this.airportCode(),
    stream: ({ params }) => this.flightService.findByAirport(params),
  });
}

The template usage is identical to httpResource — same value(), error(), isLoading(), and status() signals. The only difference is the source: instead of describing a request object, you hand it an Observable factory. That interop is deliberate. Angular isn't asking you to rip out your existing RxJS-based services; it's giving you a bridge so the rest of your component can stay signal-first.

The lowest-level option: plain `resource()`

If your async source isn't HTTP or RxJS at all — a Promise-based SDK call, an IndexedDB read, whatever — resource() itself is the primitive both of the above are built on.

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

const userId = signal(42);

const userResource = resource({
  params: () => userId(),
  loader: async ({ params, abortSignal }) => {
    const response = await fetch(`/api/users/${params}`, {
      signal: abortSignal,
    });
    if (!response.ok) {
      throw new Error(`Failed to load user ${params}`);
    }
    return response.json();
  },
});

Notice the abortSignal argument — resources hand you a standard AbortSignal so you can actually cancel an in-flight fetch call when a newer request supersedes it, rather than just ignoring the stale response once it lands. That's the mechanism behind the automatic race-condition handling described above.

Want more tips like this on modern Angular internals? Drop a follow, or subscribe to my newsletter — I'd rather send it to your inbox than hope you catch it in the feed.

Testing components that use resources

A common worry with any new async primitive is "how am I supposed to test this without a mountain of fake timers." The good news is resources built on httpResource still go through HttpClient under the hood, so the standard HttpTestingController workflow applies with only one adjustment: you need to wait for the resource to settle instead of asserting immediately.

import { TestBed } from '@angular/core/testing';
import {
  HttpTestingController,
  provideHttpClientTesting,
} from '@angular/common/http/testing';
import { provideHttpClient } from '@angular/common/http';
import { FlightSearch } from './flight-search';

describe('FlightSearch', () => {
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [provideHttpClient(), provideHttpClientTesting()],
    });
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('loads flights once both filter fields are set', async () => {
    const fixture = TestBed.createComponent(FlightSearch);
    const component = fixture.componentInstance;

    component['filter'].set({ from: 'Hamburg', to: 'Graz' });
    fixture.detectChanges();

    const req = httpMock.expectOne((request) =>
      request.url.includes('/flights'),
    );
    req.flush([{ id: 1, from: 'Hamburg', to: 'Graz', date: '2026-08-01' }]);

    await fixture.whenStable();
    fixture.detectChanges();

    expect(component['flightsResource'].value().length).toBe(1);
    expect(component['flightsResource'].status()).toBe('resolved');
  });

  it('does not fire a request when a filter field is empty', () => {
    const fixture = TestBed.createComponent(FlightSearch);
    fixture.detectChanges();

    httpMock.expectNone((request) => request.url.includes('/flights'));
  });
});

The key line is await fixture.whenStable(). Resources resolve asynchronously even after the mocked response is flushed, so reaching for fixture.detectChanges() alone right after req.flush(...) will catch you off guard with a still-pending resource. If you'd rather assert on isLoading() mid-flight, just check it before calling flush — the resource will report loading (or reloading, if it's a subsequent fetch) until the mocked response lands.

Ever had a test pass locally and flake in CI because of exactly this kind of async timing gap? I've lost a Friday afternoon to that one — what's your go-to way of catching it before it ships?

Bonus tips

A few extras that didn't fit neatly into the sections above but are worth keeping in your back pocket:

Cache resources across SSR and the client. Give a resource an id in its options and, per the Angular v22 changelog, it can be cached so the value rendered on the server is reused on the client instead of re-fetching immediately after hydration.
debounced() for anything that isn't a form field. Signal Forms has built-in debouncing, but if you need to debounce a plain signal that feeds a resource — a search box that isn't part of a form, for instance — the new debounced() function returns a resource-shaped value you can read with .value() and .isLoading() while it settles.
Resource composition via snapshots. If you need to derive a new resource from an existing one — filtering its value, or keeping the previous value visible while reloading instead of flashing undefined — resourceFromSnapshots() combined with linkedSignal on a resource's snapshot() lets you do that without touching the original loading logic. It's a more advanced pattern, but it's the cleanest way to avoid duplicating fetch logic just to reshape data.
Pair resources with OnPush deliberately, even though it's now the default. Since Angular 22 makes OnPush the default change detection strategy, a component driven entirely by resource and other signals gets fully reactive rendering with zero manual markForCheck() calls — which is also exactly what you want in a zoneless application.
Don't forget the abortSignal if you roll your own loader. It's easy to write a resource() loader that ignores abortSignal because the happy path works fine without it. You'll only notice the missing cancellation when a slow request keeps running after a newer one has already superseded it.

Recap

Resources give Angular a proper answer to a problem every one of us has solved manually at least a dozen times: tracking the state of an asynchronous request without scattering boolean flags across a component. With Angular 22, resource(), httpResource(), and rxResource() are no longer an experiment — they're a stable, production-ready part of the framework, complete with automatic stale-request cancellation, resource chaining via chain(), and SSR-aware caching.

If you're starting a new Angular 22 project, or even just adding a new feature to an existing one, reaching for httpResource() instead of a hand-rolled subscription is a genuinely small change that removes a surprising amount of boilerplate. Give it a try in your next component and see how much of your isLoading bookkeeping just disappears.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular 22 Is Officially Signal-First: Here's Everything That Changed - Here's What Changes in NG 22 (Part 6)

Rajat — Wed, 22 Jul 2026 13:30:00 +0000

A practical walkthrough of `resource()`, `rxResource()`, `httpResource()`, and the new `debounced()` utility — with working code and tests

Have you ever opened an Angular changelog and felt like you were reading a different framework than the one you learned three years ago? That's exactly what Angular 22 feels like. Released on June 3, 2026, it's the release where signals stop being "the new thing" and officially become "the only thing."

If you've been putting off learning signals because resources and forms were still marked experimental, that excuse is gone. In this article we're going to get our hands dirty with the APIs that made this release matter: resource(), rxResource(), httpResource(), and the brand-new debounced() signal utility.

By the end of this article you'll know:

Why the Resource API finally graduated to stable, and what that means for your day-to-day code
How to replace a typical HTTP call built with HttpClient and RxJS with httpResource()
When to reach for resource() versus rxResource()
How to debounce a signal properly using debounced(), without a single setTimeout or debounceTime
How to write unit tests for components built entirely around signals

If you're still writing subscribe() blocks everywhere, stick around — this one's for you.

If this is the kind of practical, no-fluff Angular content you're after, follow along here on Medium so you don't miss the next deep dive.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular/React versions. Always refer to the official documentation for the most current API and syntax.

Why Angular 22 Is a Bigger Deal Than It Looks

On paper, Angular 22 reads like a routine minor version bump. In practice, it closes out a two-year arc that started with the introduction of signals back in Angular 16. According to the Angular team's own release notes, the two headline features of this version — the Resource API and Signal Forms — have both left experimental status and are now considered production-ready.

That matters because up until now, most teams were forced to mix paradigms: signals for state, RxJS for async data, and @Input/@Output decorators for component boundaries. Angular 22 removes the RxJS requirement for the most common case — fetching data — and lets you stay inside the signal graph from start to finish.

resource(): The Foundation

resource() is the generic building block. You give it a params function that returns whatever value should trigger a refetch, and a loader function that does the actual async work. Whenever the params change, the loader reruns automatically.

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

export class UserProfileComponent {
  userId = signal(1);

  userResource = resource({
    params: () => ({ id: this.userId() }),
    loader: async ({ params }) => {
      const response = await fetch(`/api/users/${params.id}`);
      if (!response.ok) {
        throw new Error('Failed to load user');
      }
      return response.json();
    },
  });
}

In the template, you get value(), isLoading(), error(), and status() for free — no subscription management required:

@if (userResource.isLoading()) {
  <p>Loading user...</p>
} @else if (userResource.error()) {
  <p>Something went wrong: {{ userResource.error() }}</p>
} @else {
  <p>{{ userResource.value()?.name }}</p>
}

Notice there's no *ngIf here — Angular 22 wants you using the built-in @if/@else control flow, and there's no NgModule in sight because this is a standalone component by default.

rxResource(): For When You Already Have an Observable

Not every data source is fetch-friendly. Maybe you have a WebSocket stream, or a service that already returns observables. That's exactly what rxResource() is for — it lets you plug an existing observable-returning function into the same resource lifecycle.

import { Component, signal, inject } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';

export class OrdersComponent {
  private http = inject(HttpClient);
  customerId = signal('c-1001');

  ordersResource = rxResource({
    params: () => ({ customerId: this.customerId() }),
    stream: ({ params }) =>
      this.http.get<Order[]>(`/api/customers/${params.customerId}/orders`),
  });
}

Everything downstream — value(), isLoading(), error() — behaves identically to resource(). The only difference is the source: RxJS in, Resource out.

httpResource(): The Shortcut for HTTP Calls

If your async work is "just" an HTTP request, you don't need to write a loader or wire up RxJS interop at all. httpResource() is a purpose-built wrapper around HttpClient that turns any reactive URL or request object into a resource.

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

export class BookSearchComponent {
  isbn = signal<string | null>(null);

  book = httpResource<Book>(() => {
    const value = this.isbn();
    return value ? `/api/books/${value}` : undefined;
  });
}

Returning undefined from the reactive function is the idiomatic way to tell httpResource() "don't fetch yet" — handy for search inputs or optional filters. And because it's built on HttpClient, every interceptor you've already registered still applies.

Quick question for you: are you still writing a dedicated service method and a subscribe() call for every single GET request in your app, or have you already started consolidating around resources? Genuinely curious how teams are migrating existing codebases — tell me in the comments.

debounced(): Debouncing Without RxJS

Here's the feature that got the most attention out of this whole release. debounced() takes any signal and a wait time, and gives you back a Resource — not a plain signal — because a debounced value genuinely has loading states while it waits.

import { Component, signal } from '@angular/core';
import { debounced } from '@angular/core';
import { httpResource } from '@angular/common/http';

export class LiveSearchComponent {
  query = signal('');
  debouncedQuery = debounced(this.query, 300);

  results = httpResource<SearchResult[]>(() => {
    const term = this.debouncedQuery.value();
    return term ? `/api/search?q=${term}` : undefined;
  });

  onInput(value: string) {
    this.query.set(value);
  }
}

<input (input)="onInput($any($event.target).value)" placeholder="Search..." />

@if (debouncedQuery.isLoading()) {
  <p>Waiting for you to stop typing...</p>
}

@if (results.isLoading()) {
  <p>Searching...</p>
} @else {
  @for (item of results.value(); track item.id) {
    <p>{{ item.title }}</p>
  }
}

Compare that to the RxJS version most of us have written a dozen times, with a FormControl, debounceTime, distinctUntilChanged, and a manual switchMap. The signal version reads top to bottom, has no subscription to clean up, and exposes its own isLoading() so you can show a "still waiting" state distinct from the actual network request.

Unit Testing Signal-Based Components

The good news: testing resource-driven components is arguably simpler than testing RxJS-based ones, because there's no need to fake observables or flush subjects manually. Here's a test for the LiveSearchComponent above using Angular's TestBed and fakeAsync.

import { TestBed, fakeAsync, tick } from '@angular/core/testing';
import { provideHttpClient } from '@angular/common/http';
import {
  provideHttpClientTesting,
  HttpTestingController,
} from '@angular/common/http/testing';
import { LiveSearchComponent } from './live-search.component';

describe('LiveSearchComponent', () => {
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [LiveSearchComponent],
      providers: [provideHttpClient(), provideHttpClientTesting()],
    });
    httpMock = TestBed.inject(HttpTestingController);
  });

  it('waits for the debounce window before firing a request', fakeAsync(() => {
    const fixture = TestBed.createComponent(LiveSearchComponent);
    const component = fixture.componentInstance;

    component.onInput('angular');
    fixture.detectChanges();

    // No request yet, still inside the debounce window
    httpMock.expectNone('/api/search?q=angular');

    tick(300);
    fixture.detectChanges();

    const req = httpMock.expectOne('/api/search?q=angular');
    req.flush([{ id: 1, title: 'Angular 22 Guide' }]);

    fixture.detectChanges();
    expect(component.results.value()?.length).toBe(1);
  }));

  afterEach(() => {
    httpMock.verify();
  });
});

The key trick here is tick(300) — it advances the virtual clock past the debounce window before we assert the request went out. If you skip that tick, expectOne will fail because debounced() genuinely hasn't settled yet, which is exactly the behavior you want to verify.

If that debounce test just saved you from writing a flaky, timing-dependent spec by hand, this is a good moment to hit that clap button so more people find this walkthrough.

Bonus Tips

Reach for resource() when your data source doesn't naturally fit "URL in, JSON out" — think file reads, IndexedDB, or custom async work.
Use httpResource() as your default for anything backed by a REST endpoint; it's the least code for the most common case.
Combine debounced() with httpResource()'s "return undefined to skip" pattern for the cleanest possible search-as-you-type implementation.
Resources destroy themselves automatically when their owning component or service is destroyed, so you generally don't need manual cleanup — but if you create one outside a component context, pass an explicit injector option.
When migrating an existing RxJS-heavy service, start with rxResource() rather than rewriting everything at once. It lets you keep your existing observable-returning methods while adopting the resource lifecycle in your templates.

Recap

Angular 22 is the release where the two-year signals migration actually finishes. resource(), rxResource(), and httpResource() are stable, which means the "wait for it to leave experimental" excuse for avoiding them is gone. debounced() gives you a clean, RxJS-free way to handle the classic search-input problem, complete with its own loading state. And because everything is built on signals, testing gets simpler, not harder — fakeAsync and tick are all you need.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular 22 Quietly Replaced XHR -Here's What Actually Changes For You (Part 5)

Rajat — Wed, 15 Jul 2026 13:30:00 +0000

HttpClient now runs on Fetch by default. Here's what that means for your SSR app, your tests, and that one file-upload feature everyone forgets about.

Quick question: when was the last time you actually stopped and thought about what HttpClient does under the hood every time you call .get() or .post()?

Most of us never think about it. It's plumbing. It works, so we move on. But with Angular 22 (released June 3, 2026), that plumbing just got swapped out from under you, and depending on what your app does, you might not notice anything — or you might get a very confusing bug report about a progress bar that stopped moving.

Here's the short version: HttpClient used to run every request through XMLHttpRequest (XHR) unless you explicitly opted into withFetch(). As of Angular 22, that's flipped. Fetch is now the default backend, and XHR is the thing you opt into.

By the end of this article, you'll know:

What actually changed in HttpClient and why the Angular team made the switch
How to write the provider setup with the new default (and how to fall back to XHR when you need to)
The one feature that quietly breaks if you're not paying attention (upload progress)
How this connects to SSR, streaming, and service worker caching
How to write unit tests against the new default without your test suite silently lying to you

If you're following along with server-side rendering, incremental hydration, or you just upgraded and your app is behaving slightly differently, this one's for you.

If this is useful, consider following along here on Medium — I write about Angular internals like this pretty regularly, and it helps more than you'd think.

Before we dive into the examples, a quick note: the code snippets here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular versions as the ecosystem keeps evolving quickly. Always check the official Angular documentation for the current API and syntax before shipping anything to production.

What Actually Changed in Angular 22

Let's start with the boring-sounding but important part. Before Angular 22, provideHttpClient() used XHR by default, and you had to explicitly add withFetch() if you wanted requests to go through the native fetch() API instead. In Angular 22, that default flipped — provideHttpClient() now uses FetchBackend automatically, and withFetch() is no longer something you need to write (in fact, it's been deprecated since it now describes the default behavior rather than an opt-in).

Here's what the setup looked like before, and what it looks like now.

// app.config.ts — Angular 21 and earlier
import { ApplicationConfig } from '@angular/core';
import { provideHttpClient, withFetch } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()), // had to opt in explicitly
  ],
};

// app.config.ts — Angular 22+
import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(), // Fetch backend, automatically
  ],
};

That's it. No new API to learn, no migration steps for the common case. If you never touched withFetch() or withXhr() before, your app is already running on the new backend the moment you upgrade.

Why the Angular Team Made the Switch

A few reasons keep coming up when you dig into why this matters:

Better SSR compatibility. fetch() is a standard API that exists natively in both the browser and in server runtimes like Node.js. XMLHttpRequest is a browser-only construct that had to be polyfilled or shimmed for server-side rendering. Standardizing on fetch() removes an entire category of "works in the browser, breaks on the server" bugs.

Streaming support. Fetch's response body is a readable stream by design, which lines up naturally with patterns like streaming SSR and incremental hydration that Angular has been leaning into over the last few releases.

Smaller bundles. Because the XHR code path is no longer needed by default, apps that don't explicitly ask for it can ship a slightly leaner bundle.

Service worker synergy. Since fetch() is the same API the Fetch event in a service worker listens for, an Angular app using @angular/service-worker can now have its HttpClient calls participate in caching strategies defined in ngsw-config.json without extra wiring.

Ever run into a weird SSR-only bug that never showed up locally? Tell me about it in the comments — I'm willing to bet a chunk of those were XHR-related timing issues in disguise.

The One Thing That Breaks: Upload Progress

Here's the gotcha, and it's a real one if your app has file uploads.

FetchBackend does not support upload progress events. If you have code that watches reportProgress: true and listens for HttpEventType.UploadProgress on a POST request, that progress reporting will silently stop working once you're on the Fetch backend — no error, no warning, the progress bar just never moves past 0 (or jumps straight to 100).

The fix is to explicitly request the XHR backend for the parts of your app that need it, using withXhr():

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideHttpClient, withXhr } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withXhr()), // opt back into XHR app-wide
  ],
};

If you only need XHR for a specific feature rather than your whole app, you can inject a separate HttpClient scoped to a child injector that provides withXhr(), and use that client just for upload calls. That way the rest of your app keeps the benefits of Fetch, and only the upload path pays the XHR cost.

A realistic upload service, written with signals and the current dependency injection style, looks like this:

import { HttpClient, HttpEvent, HttpEventType } from '@angular/common/http';
import { inject, Injectable, signal } from '@angular/core';
import { map } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class FileUploadService {
  private http = inject(HttpClient);
  readonly uploadProgress = signal(0);

  uploadFile(file: File) {
    const formData = new FormData();
    formData.append('file', file);

    return this.http
      .post('/api/upload', formData, {
        reportProgress: true,
        observe: 'events',
      })
      .pipe(
        map((event: HttpEvent<unknown>) => {
          if (event.type === HttpEventType.UploadProgress && event.total) {
            this.uploadProgress.set(Math.round((100 * event.loaded) / event.total));
          }
          return event;
        }),
      );
  }
}

Remember: this only reports progress correctly if the injector providing this service is configured with withXhr(). On the default Fetch backend, event.total for upload events simply won't fire the way you expect.

Putting It Together in a Component

Here's a small, complete component that consumes the service above, using standalone architecture, signal-based state, and the new control flow syntax:

import { Component, inject, signal } from '@angular/core';
import { FileUploadService } from './file-upload.service';

@Component({
  selector: 'app-file-upload',
  template: `
    <input type="file" (change)="onFileSelected($event)" />

    @if (uploading()) {
      <p>Uploading… {{ uploadService.uploadProgress() }}%</p>
    } @else {
      <p>Choose a file to upload.</p>
    }
  `,
})
export class FileUploadComponent {
  protected uploadService = inject(FileUploadService);
  protected uploading = signal(false);

  onFileSelected(event: Event) {
    const input = event.target as HTMLInputElement;
    const file = input.files?.[0];
    if (!file) return;

    this.uploading.set(true);
    this.uploadService.uploadFile(file).subscribe({
      complete: () => this.uploading.set(false),
      error: () => this.uploading.set(false),
    });
  }
}

Notice there's no NgModule, no *ngIf, and no @Input() decorator anywhere. This is standalone by default, using @if for conditional rendering, which is exactly how a fresh Angular 22 project scaffolds things today.

Writing Unit Tests Against the Fetch Backend

Testing HTTP calls hasn't fundamentally changed in shape — you still use the HttpClient testing utilities to intercept and assert against requests. What's worth double-checking is that your test provider setup matches whatever backend your app actually runs in production, especially if you've explicitly opted into withXhr() somewhere.

import { TestBed } from '@angular/core/testing';
import {
  HttpTestingController,
  provideHttpClientTesting,
} from '@angular/common/http/testing';
import { provideHttpClient } from '@angular/common/http';
import { FileUploadService } from './file-upload.service';

describe('FileUploadService', () => {
  let service: FileUploadService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        provideHttpClient(),
        provideHttpClientTesting(),
        FileUploadService,
      ],
    });

    service = TestBed.inject(FileUploadService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should POST the file to the upload endpoint', () => {
    const file = new File(['dummy content'], 'test.png', { type: 'image/png' });

    service.uploadFile(file).subscribe();

    const req = httpMock.expectOne('/api/upload');
    expect(req.request.method).toBe('POST');

    req.flush({});
  });

  it('should update uploadProgress on progress events', () => {
    const file = new File(['dummy content'], 'test.png', { type: 'image/png' });

    service.uploadFile(file).subscribe();

    const req = httpMock.expectOne('/api/upload');
    req.event({
      type: 1, // HttpEventType.UploadProgress
      loaded: 50,
      total: 100,
    } as any);

    expect(service.uploadProgress()).toBe(50);
  });
});

A couple of things worth calling out: HttpTestingController intercepts requests regardless of which real backend (Fetch or XHR) is configured, since it replaces the backend entirely during testing. That's convenient, but it also means your unit tests won't catch the "upload progress silently stops working" issue described earlier — that only shows up with a real network layer, so it's worth covering with at least one integration or e2e test if uploads matter to your app.

Have you hit a case where your test suite passed but the real backend behaved differently once deployed? That's exactly the kind of gap worth sharing — drop a comment with what tripped you up.

Migration Notes

If you're upgrading an existing app to Angular 22, running ng update @angular/core @angular/cli handles the mechanical parts. A few things worth checking manually afterward:

Search your codebase for withFetch() — it still works but is deprecated, so it's a good time to remove it since it's now redundant.
Search for reportProgress: true and confirm those call sites either don't rely on upload progress, or have been updated to use withXhr().
If you're running Angular on the server for SSR, double-check any custom interceptors that assumed XHR-specific behavior (things like inspecting XMLHttpRequestspecific properties directly rather than going through the HttpEvent API).
Angular 22 also requires TypeScript 6 and drops support for Node 20, so factor that into your upgrade path if you haven't already touched your toolchain.

Bonus Tips

A few smaller things that are easy to miss:

If your app talks to an API that returns very large responses, Fetch's native streaming support means you can process a response as it arrives rather than waiting for the whole payload, which is worth exploring if you're dealing with large downloads.
withXhr() isn't just an escape hatch for uploads — some corporate proxy setups and older embedded browser environments still behave more predictably with XHR, so keep it in your back pocket for edge-case debugging.
If you're using @angular/service-worker, revisit your ngsw-config.json caching strategy now that HttpClient requests go through fetch() — you may be able to simplify caching logic that previously had to work around XHR quirks.
Pair this change with Angular's httpResource() API if you haven't already looked at it — it builds on HttpClient and gives you a signal-based way to load data without manually wiring up subscriptions.

Recap

Angular 22 flips HttpClient's default backend from XHR to Fetch. For most apps, this is a zero-line-change upgrade — you get better SSR compatibility, native streaming support, and service worker synergy for free. The one place to slow down is upload progress tracking, since FetchBackend doesn't support it; if your app needs it, reach for withXhr() explicitly. Unit tests using HttpTestingController continue to work the same way regardless of backend, but they won't catch backend-specific behavior gaps on their own, so keep that in mind for anything progress-related.

What's your take: are you planning to stick with the new Fetch default, or do you have a use case that pushes you back to XHR? Let me know in the comments.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit** — Developer blog posts & tech discussions

@Service: Angular 22's @Service Decorator: Say Goodbye to @Injectable Boilerplate - Here’s What Changes (Part 4)

Rajat — Wed, 08 Jul 2026 13:30:00 +0000

A practical look at Angular's new, opinionated way to write services — what changed, why it matters, and when you should still reach for the old decorator

Quick question before we start: how many times have you typed @Injectable({ providedIn: 'root' }) this month without thinking twice about it?

If you've been writing Angular for more than a few weeks, the answer is probably "too many to count." It's one of those patterns we type on autopilot — copy, paste, rename the class, move on. Angular 22 finally does something about that muscle memory, and it's called @Service.

In this article we're going to unpack the new decorator like two developers pairing on a Friday afternoon: no fluff, just the "why," the "how," and the "when should I actually use this." By the end, you'll know:

Why the Angular team added @Service when @Injectable already worked fine
Exactly how @Service differs from @Injectable, with a side-by-side comparison
How to use the factory and autoProvided options for more advanced cases
How to write unit tests for services built with @Service
When you should skip @Service and stick with the classic decorator

Sound good? Follow along, and if you find this useful, consider following me here on Medium — I write about practical Angular and React patterns every week, not just "what's new" roundups.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular/React versions. Always refer to the official documentation for the most current API and syntax.

Why Angular introduced @Service

Let's start with the pattern we all know. Here's a completely typical Angular service, written the way we've written it for years:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  getUsers() {
    return this.http.get('/api/users');
  }
}

Nothing wrong with this. It works, it's familiar, and it's been the backbone of Angular DI since the framework's early days. But look closely at what's actually happening: @Injectable was built to describe how Angular should construct and provide a class, with support for useClass, useValue, useExisting, useFactory, non-root scopes, and constructor injection. Almost none of that flexibility gets used in a typical app service. Most of the time you just want a plain singleton that lives at the root of your app.

That mismatch — a powerful, general-purpose decorator being used for the simplest possible case — is exactly what @Service is designed to fix. It's a more opinionated decorator built around the assumption that you're creating a root-provided singleton and injecting your dependencies with the inject() function rather than a constructor.

Here's the same service, rewritten with @Service:

import { Service, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Service()
export class UserService {
  private http = inject(HttpClient);

  getUsers() {
    return this.http.get('/api/users');
  }
}

Same behavior, same singleton guarantees — Angular still gives you a single shared instance, automatic availability across the app, and tree-shakability if the service is never actually used. What's gone is the ceremony: no providedIn: 'root' to remember, no constructor parameter list to keep in sync every time a dependency changes.

Ever caught yourself forgetting providedIn: 'root' and wondering why you got a NullInjectorError at runtime? That's precisely the kind of small, avoidable mistake @Service removes from the equation, since root provisioning is now the default rather than something you opt into.

@Service vs @Injectable: what's actually different

It helps to see the two side by side instead of just reading about them. Here's how they compare:

Feature	`@Service`	`@Injectable`
`inject()` function support	Yes	Yes
Constructor-based DI	No	Yes
Root singleton by default	Yes	No — requires `providedIn: 'root'`
Advanced provider keys (`useClass`, `useValue`, etc.)	No	Yes
Custom initialization via factory	Yes, via `factory`	Yes, via `useFactory`
Non-root scopes (`platform`, etc.)	No	Yes

The biggest mental shift is that @Service only supports inject() for dependencies — there's no constructor injection at all. If your team has already standardized on inject() (which most modern Angular codebases have, especially since standalone components became the default), this isn't a big adjustment. If you're still writing constructor-based DI throughout your app, this is a good nudge to modernize.

Using a factory for conditional logic

Sometimes a service's implementation needs to change based on environment or configuration — think analytics that should be a no-op locally but forward events to a real tracker in production. @Service handles this with a single factory option that runs inside an injection context, so you can call inject() right inside it:

import { inject, InjectionToken, Service } from '@angular/core';

export const ANALYTICS_ENABLED = new InjectionToken<boolean>('ANALYTICS_ENABLED');

@Service({
  factory: () =>
    inject(ANALYTICS_ENABLED) ? new GoogleAnalytics() : new Analytics(),
})
export class Analytics {
  track(event: string, payload?: Record<string, unknown>) {
    // No-op by default.
  }
}

class GoogleAnalytics extends Analytics {
  override track(event: string, payload?: Record<string, unknown>) {
    // Sends the event to Google Analytics in production.
  }
}

The factory option is meant to replace useClass, useValue, useExisting, and useFactory from @Injectable. If your use case needs one of those specifically, that's your signal to reach for @Injectable instead — @Service is intentionally not trying to cover every advanced scenario.

Opting out of automatic root provisioning

Not every service should live at the root. If you want a service scoped to a specific route or component instead, set autoProvided: false and register it manually, the same way you would with @Injectable:

import { Service } from '@angular/core';

@Service({ autoProvided: false })
export class AnalyticsLogger {
  trackEvent(name: string) {
    console.log('event:', name);
  }
}

You'd then add AnalyticsLogger to the providers array of whichever component or route should own its lifecycle — nothing new here if you've scoped services before, just a slightly different starting point.

Using the service in a component

Injecting a @Service-decorated class works exactly the way you'd expect if you're already using inject():

import { Component, inject } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-list',
  template: `
    @if (users(); as list) {
      @for (user of list; track user.id) {
        <p>{{ user.name }}</p>
      }
    } @else {
      <p>Loading users...</p>
    }
  `,
})
export class UserList {
  private userService = inject(UserService);
  users = this.userService.getUsers();
}

Notice the @if / @for control flow syntax here instead of *ngIf / *ngFor — that's the modern Angular template syntax, and it pairs naturally with the rest of this more streamlined, signal-friendly style of writing components.

Writing unit tests for a @Service class

Good news: testing a @Service class is nearly identical to testing an @Injectable one, since TestBed doesn't care which decorator produced the provider — it just resolves the dependency graph. Here's a straightforward test for the UserService from earlier:

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService } from './user.service';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });

  it('should fetch users from the API', () => {
    const mockUsers = [{ id: 1, name: 'Ada Lovelace' }];

    service.getUsers().subscribe((users) => {
      expect(users).toEqual(mockUsers);
    });

    const req = httpMock.expectOne('/api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);
  });
});

If you're testing a service created with autoProvided: false, just remember it won't be picked up automatically — you'll need to add it to the providers array of your TestBed.configureTestingModule call, the same way you would in a real component:

TestBed.configureTestingModule({
  providers: [AnalyticsLogger],
});

That's really the whole story for testing: the decorator changes how the service is provided, not how it behaves once it's resolved, so your existing testing habits carry over almost untouched.

What's your usual setup for mocking HTTP calls in service tests — HttpClientTestingModule, a hand-rolled spy, or something else? I'd genuinely like to know what's working for people right now.

Best practices for adopting @Service

A few things worth keeping in mind as you start using this in real projects:

Migrate incrementally. You don't need to convert every service in your app at once. @Service and @Injectable interoperate fine, so it's safe to introduce the new decorator only in new files and gradually touch old ones as you edit them anyway.
Pair it with inject() everywhere. Since @Service doesn't support constructor injection, standardizing on inject() across your whole codebase — components included — keeps things consistent and avoids a codebase with two competing DI styles.
Use factory sparingly. It's there for genuine conditional construction, not as a place to smuggle in business logic. If your factory function is getting long, that's usually a sign the logic belongs inside the class itself.
Reach for autoProvided: false deliberately. Scoping a service to a component is a real architectural decision — make sure it's intentional rather than a copy-pasted default.

When not to use @Service

@Service is not a full replacement for @Injectable, and that's fine — it was never meant to be. Stick with @Injectable when you need:

Constructor-based dependency injection, for example in a codebase that hasn't migrated to inject() yet
Advanced provider configuration such as useClass, useValue, or useExisting
A non-root scope like providedIn: 'platform'

If none of those apply, @Service is generally the more direct, more modern choice for a new singleton class.

Bonus tips

If you're using an editor with Angular language service support, decorator autocompletion for @Service should already suggest factory and autoProvided as you type — a quick way to double-check you're not misremembering the option names.
Consider adding an ESLint rule to your project that flags new @Injectable({ providedIn: 'root' }) usages without useClass/useFactory/etc., nudging your team toward @Service for the simple cases automatically.
When reviewing pull requests, a quick heuristic is: if the diff adds a constructor purely to inject one or two dependencies, that's often a good candidate to rewrite with inject() and @Service in the same pass.

Recap

@Service is Angular 22's answer to years of typing the same @Injectable({ providedIn: 'root' }) boilerplate for services that never needed the extra configuration in the first place. It defaults to a root-provided singleton, drops constructor injection in favor of inject(), and replaces the old provider keys with a single factory option for the cases that genuinely need one. It's not trying to replace @Injectable entirely — for constructor DI, advanced provider configuration, or non-root scopes, @Injectable is still the right tool. But for the everyday singleton service, which is most of them, @Service is a small change that removes a surprising amount of repetitive code.

Did this approach match how you've been writing services, or are you planning to hold off on adopting it for a while? Either way, I'd like to hear where you land.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Meet injectAsync(): How injectAsync() in Angular 22 Can Shrink Your Initial Bundle Without Changing Your Architecture — Here's NG 22 (Part 3)

Rajat — Sat, 04 Jul 2026 12:15:36 +0000

Angular 22 quietly shipped one of the most developer-friendly DI improvements in years — and most people are still sleeping on it.

Have you ever injected a heavyweight service at the top of a component, knowing full well that 90% of your users will never actually trigger the feature that needs it? You import it, Angular boots it eagerly, it pulls in its own dependencies, and suddenly a chunk of your bundle is loaded just in case someone clicks "Export PDF." Sound familiar?

That exact pain point is what injectAsync() — one of the standout additions in Angular 22 — is designed to fix. And once you see how it works, you will start questioning every inject() call in your codebase.

In this article, you will learn:

What injectAsync() is and why it was introduced
How it differs from the familiar inject() function
Real-world use cases where lazy injection makes a meaningful difference
How to write unit tests for components that use it
Bonus tips to squeeze even more out of Angular 22's DI improvements

If this is the kind of deep-dive content you find useful, consider following me here on Medium — I publish one practical Angular article every week, and the Angular 22 series is just getting started.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular. Always refer to the official Angular documentation for the most current API and syntax.

What Changed in Angular 22's Dependency Injection

Angular 22 landed on June 3, 2026, and it came with a headline list that includes Signal Forms going stable, Resources graduating to production-ready, and OnPush becoming the default change detection strategy. Those are big deals. But tucked in alongside them is injectAsync() — a quieter addition that solves a very specific and very common problem.

To understand why it matters, you need to understand what eager injection actually costs you.

When you write inject(HeavyAnalyticsService) in a component, Angular resolves that dependency the moment the component is created. The service gets instantiated, its own dependencies get resolved, and everything that service depends on gets pulled into the initial load. If that service is only needed when a user clicks a specific button — maybe one that exports a report, or opens an advanced settings panel — you have just loaded that entire dependency graph on behalf of every user who lands on the page, even those who never click that button.

injectAsync() breaks that pattern. It lets you declare a dependency but defer its actual resolution until the moment you need it.

The Old Way: inject() and Its Limits

Here is what the traditional pattern looks like. You have a component with a button that triggers a PDF export. The PdfReportService is non-trivial — it pulls in a PDF generation library and potentially some charting utilities.

// pdf-report.service.ts
import { Service } from '@angular/core';

@Service()
export class PdfReportService {
  generate(data: ReportData): Promise<Blob> {
    // imagine this pulls in a large PDF library
    return heavyPdfLibrary.render(data);
  }
}

// dashboard.component.ts
import { Component, inject } from '@angular/core';
import { PdfReportService } from './pdf-report.service';

@Component({
  selector: 'app-dashboard',
  template: `
    <h1>Dashboard</h1>
    <button (click)="exportReport()">Export PDF</button>
  `
})
export class DashboardComponent {
  // This is resolved eagerly — the service is created when the component is created
  private readonly pdfService = inject(PdfReportService);

  exportReport() {
    this.pdfService.generate(this.getReportData());
  }
}

Every time DashboardComponent is created, PdfReportService is instantiated — regardless of whether the user ever touches that export button. In a large application, this adds up.

Introducing injectAsync(): Lazy DI on Demand

Angular 22 ships injectAsync() to solve exactly this. The function signature is simple: you pass it a factory function that returns a Promise resolving to the service instance. Angular handles the DI resolution for you, including respecting the injection context — you are not reaching outside the DI system.

Here is the same dashboard rewritten with injectAsync():

// dashboard.component.ts
import { Component, injectAsync } from '@angular/core';
import { PdfReportService } from './pdf-report.service';

@Component({
  selector: 'app-dashboard',
  template: `
    <h1>Dashboard</h1>
    <button (click)="exportReport()">Export PDF</button>
  `
})
export class DashboardComponent {
  // The service is NOT resolved until exportReport() is called
  private readonly getPdfService = injectAsync(() => import('./pdf-report.service')
    .then(m => m.PdfReportService));

  async exportReport() {
    const pdfService = await this.getPdfService();
    pdfService.generate(this.getReportData());
  }

  private getReportData(): ReportData {
    return { /* ... */ };
  }
}

What injectAsync() returns is not the service itself — it returns a function. Calling that function returns a Promise that resolves to the service. Angular ensures the instance is created within the correct injection context, so all the DI guarantees you expect still apply.

The key behavioral difference: the service (and its dependency graph) is only resolved the first time exportReport() is called. For users who never click that button, that chunk of code never loads.

How injectAsync() Works Under the Hood

You might be wondering: if injectAsync() returns a function that returns a Promise, how does Angular know to use DI for the resolved service?

The answer is that injectAsync() captures the injection context at the time it is called — which is during component construction, inside the injection context. The actual resolution is deferred, but the context reference is preserved. This is the same mechanism that allows things like toSignal() to work when called during component initialization.

This also means there is one important constraint: you must call injectAsync() during component construction (or in another valid injection context), not inside a method or lifecycle hook that runs later. The returned function can be called anywhere and at any time.

// CORRECT: called during construction
export class MyComponent {
  private readonly lazyService = injectAsync(() =>
    import('./heavy.service').then(m => m.HeavyService)
  );
}

// WRONG: called inside a method — will throw
export class MyComponent {
  someMethod() {
    // This will throw — no injection context here
    const lazyService = injectAsync(...);
  }
}

Real-World Use Cases

Let me walk through a few scenarios where injectAsync() earns its keep.

Use Case 1: Feature-Gated Admin Tools

Imagine a component that most users never interact with — say, a bulk data export panel visible only to admins. The export logic imports a heavy CSV serializer and a custom reporting engine.

// admin-panel.component.ts
import { Component, injectAsync, signal } from '@angular/core';

@Component({
  selector: 'app-admin-panel',
  template: `
    <section>
      <h2>Admin Tools</h2>
      @if (isExporting()) {
        <p role="status">Generating export...</p>
      }
      <button (click)="runExport()" [disabled]="isExporting()">
        Export All Records
      </button>
    </section>
  `
})
export class AdminPanelComponent {
  protected readonly isExporting = signal(false);

  private readonly getExportService = injectAsync(() =>
    import('../services/bulk-export.service').then(m => m.BulkExportService)
  );

  async runExport() {
    this.isExporting.set(true);
    try {
      const exportService = await this.getExportService();
      await exportService.run();
    } finally {
      this.isExporting.set(false);
    }
  }
}

For 95% of users who never visit the admin panel, the BulkExportService never loads.

Use Case 2: On-Demand Map Integration

A logistics dashboard shows a table of shipments by default, with an optional map view that loads a mapping SDK.

// shipment-tracker.component.ts
import { Component, injectAsync, signal } from '@angular/core';

@Component({
  selector: 'app-shipment-tracker',
  template: `
    <div class="toolbar">
      <button (click)="toggleView()">
        @if (showingMap()) { Show Table } @else { Show Map }
      </button>
    </div>

    @if (showingMap()) {
      <div id="map-container"></div>
    } @else {
      <app-shipment-table />
    }
  `
})
export class ShipmentTrackerComponent {
  protected readonly showingMap = signal(false);

  private readonly getMapService = injectAsync(() =>
    import('../services/map-renderer.service').then(m => m.MapRendererService)
  );

  async toggleView() {
    if (!this.showingMap()) {
      const mapService = await this.getMapService();
      mapService.initialize('map-container');
    }
    this.showingMap.update(v => !v);
  }
}

The mapping SDK and its associated bundle — which can be several hundred kilobytes — only loads the first time the user requests the map view.

Comparing inject() and injectAsync() Side by Side

Here is a direct comparison so the distinction stays clear:

Aspect	inject()	injectAsync()
Resolution timing	Eagerly at component creation	Lazily on first call
Return value	The service instance	A function returning Promise
Bundle impact	Included in initial bundle	Split into a lazy chunk
Usage context	Construction or injection context	Must be called in injection context; result usable anywhere
DI guarantees	Full	Full (context is captured)
Use when	Service always needed	Service conditionally needed

What pattern are you currently using for deferred feature loading in Angular? Drop a comment below — I am curious whether you have been reaching for lazy-loaded routes, dynamic imports, or something else entirely. This is exactly the kind of trade-off worth discussing.

Unit Testing Components That Use injectAsync()

Testing injectAsync() requires a slightly different approach than testing inject(). The key is that the lazy factory returns a Promise, so your tests need to handle async resolution.

First, let us look at the service we want to mock:

// bulk-export.service.ts
import { Service } from '@angular/core';

@Service()
export class BulkExportService {
  async run(): Promise<void> {
    // heavy export logic
  }
}

Now here is how to write a unit test for the AdminPanelComponent:

// admin-panel.component.spec.ts
import { ComponentFixture, TestBed, fakeAsync, tick } from '@angular/core/testing';
import { AdminPanelComponent } from './admin-panel.component';
import { BulkExportService } from '../services/bulk-export.service';

describe('AdminPanelComponent', () => {
  let fixture: ComponentFixture<AdminPanelComponent>;
  let component: AdminPanelComponent;
  let mockExportService: jasmine.SpyObj<BulkExportService>;

  beforeEach(async () => {
    mockExportService = jasmine.createSpyObj('BulkExportService', ['run']);
    mockExportService.run.and.returnValue(Promise.resolve());

    // Intercept the dynamic import by providing the service in the test module
    await TestBed.configureTestingModule({
      imports: [AdminPanelComponent],
      providers: [
        { provide: BulkExportService, useValue: mockExportService }
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(AdminPanelComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should show exporting state while export runs', fakeAsync(async () => {
    const exportPromise = component.runExport();
    fixture.detectChanges();

    // isExporting should be true during the async operation
    expect(component['isExporting']()).toBeTrue();

    await exportPromise;
    fixture.detectChanges();

    expect(component['isExporting']()).toBeFalse();
  }));

  it('should call BulkExportService.run() when export is triggered', async () => {
    await component.runExport();
    expect(mockExportService.run).toHaveBeenCalledTimes(1);
  });

  it('should reset isExporting to false even if export throws', async () => {
    mockExportService.run.and.returnValue(Promise.reject(new Error('Export failed')));

    try {
      await component.runExport();
    } catch {
      // expected
    }

    fixture.detectChanges();
    expect(component['isExporting']()).toBeFalse();
  });
});

A few things to note about this testing approach. Because injectAsync() captures the injection context at construction time and resolves through Angular's DI system, your TestBed.configureTestingModule providers are respected. You do not need to mock the dynamic import itself — providing the service in the test module is sufficient. The fakeAsync and async utilities both work here depending on the scenario.

injectAsync() and the New @Service Decorator

Angular 22 also ships the @Service() decorator, which is essentially a shorthand for @Injectable({ providedIn: 'root' }). One requirement of injectAsync() is that the lazily injected service must be auto-provided — either with @Service() or with @Injectable({ providedIn: 'root' }).

// analytics.service.ts
import { Service } from '@angular/core';

@Service()
export class AnalyticsService {
  trackEvent(name: string, data: Record<string, unknown>) {
    // heavy analytics logic
  }
}

If you try to use injectAsync() with a service that is provided only at the component level or module level, you will run into issues because the DI resolution path for lazy injection relies on the root injector. Keep this constraint in mind when designing services you intend to lazy-inject.

As noted in the Angular 22 release coverage from Ninja Squad, injectAsync() requires the service to be auto-provided, either with @Service() or with @Injectable({ providedIn: 'root' }).

Bundle Size: The Real Payoff

The most concrete benefit of injectAsync() is what it does to your initial bundle. When you use a regular dynamic import() inside a method, most bundlers (including esbuild and webpack) will create a separate chunk for that imported module. injectAsync() plugs directly into that same mechanism — the factory function you pass to it typically contains a dynamic import, which gives your bundler the signal it needs to split that code into a lazy chunk.

The practical result: code that was previously part of your main bundle (because the service was eagerly injected at the top of your component) now lives in a separate chunk that only downloads when the feature is actually used.

For a service backed by a large third-party library — a PDF engine, a charting library, a rich text editor — the savings can be measured in hundreds of kilobytes off your initial load.

Bonus Tips

Tip 1: Cache the resolved instance yourself if you want synchronous access later.

injectAsync() always returns a Promise, even on subsequent calls. If you need synchronous access after the first resolution, store the result in a signal or a class property.

private resolvedService: HeavyService | null = null;
private readonly getHeavyService = injectAsync(() =>
  import('./heavy.service').then(m => m.HeavyService)
);

async ensureService(): Promise<HeavyService> {
  if (!this.resolvedService) {
    this.resolvedService = await this.getHeavyService();
  }
  return this.resolvedService;
}

Tip 2: Combine with OnPush and Signals for maximum efficiency.

With OnPush now the default in Angular 22, components only re-render when their signal inputs change or when you explicitly trigger change detection. Pair injectAsync() with signals to communicate loading state, and your component will only repaint when it actually needs to.

Tip 3: Do not over-lazy-load.

injectAsync() is powerful but it is not a hammer for every nail. Services that are virtually always needed — routing, auth, core data — should stay as regular inject() calls. The overhead of a Promise resolution and a network request (for the lazy chunk) is only worth it when the service is genuinely conditional or infrequently needed.

Tip 4: Use TypeScript's type inference.

injectAsync() is fully typed. The returned function's return type is inferred from the factory's Promise type, so you get full autocomplete on the resolved service without any casting.

Tip 5: Watch the Angular 22 migration guide before upgrading.

Angular 22 introduces OnPush as the default, which means existing components without an explicit change detection strategy will behave differently after the upgrade. The ng update command automatically adds changeDetection: ChangeDetectionStrategy.Eager to components that do not specify a strategy, preserving their previous behavior during the upgrade. Run the migration before deploying.

Recap

Let us bring it all together. Angular 22's injectAsync() gives you a first-class, DI-aware way to defer service resolution until the moment you actually need it. Here is what we covered:

The problem: inject() resolves dependencies eagerly at component creation, pulling large services and their dependency graphs into the initial bundle even when they are only conditionally needed.
The solution: injectAsync() accepts a factory function (typically wrapping a dynamic import) and returns a function that, when called, resolves to the service via Angular's DI system.
The constraint: injectAsync() must be called during component construction (in an injection context), and the target service must be auto-provided via @Service() or @Injectable({ providedIn: 'root' }).
The payoff: Conditionally needed services are code-split into lazy chunks, reducing initial bundle size for features that only a subset of users ever trigger.
Testing: Providing the service in TestBed.configureTestingModule is sufficient — Angular's DI respects test providers even for lazy-injected services.

Angular 22 continues a pattern that the team has been building toward for several versions: a framework where every performance best practice is also the ergonomic default. injectAsync() fits that vision well.

What did you think?
Did this approach match how you are solving lazy loading in your Angular apps, or do you have a different take? Drop a comment — I genuinely read every single one. Specifically: are there services in your current codebase that you are already thinking about converting to injectAsync()?

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit** — Developer blog posts & tech discussions

Signal Forms Are Finally Production-Ready in Angular 22 — Here’s What Changes (Part 2)

Rajat — Wed, 24 Jun 2026 13:30:00 +0000

Angular 22 graduates Signal Forms from experimental to stable — here is everything you need to know to start using them today.

Part 1 of the series: The OnPush Default Has Arrived
Part 2 of the series: "Angular 22 Features Every Developer Should Know"

Have you ever looked at a Reactive Forms setup and thought, "this is way more code than the problem deserves"? You write a FormGroup, wire up FormControl objects, subscribe to valueChanges, manage your subscriptions, then manually trigger change detection just to show a validation error. For a login form. A login form.

If you have been working with Angular for any length of time, you know exactly what I am talking about.

Angular 22 — released on June 3, 2026 — changes that conversation entirely. Signal Forms have graduated from experimental to stable, and they are ready for production. In this article we will dig into what Signal Forms actually are, how they compare to Reactive Forms, and how to build something real with them.

By the end, you will know:

Why Signal Forms exist and what problem they solve
How form(), FormRoot, and FormField work
How to write validation, async validation, and debounced inputs
How to migrate gradually without rewriting your entire codebase
How to write unit tests for Signal Form components

If you enjoy this kind of deep-dive into Angular internals, follow me here on Medium. I publish one practical article every week, and I would love to have you along for the ride.

Note: The code snippets in this article reflect Angular 22 APIs as of the stable release. Some patterns shown may differ from earlier experimental versions of Signal Forms. Always refer to the official Angular documentation for the most current API and syntax.

Why Angular Needed Signal Forms

Let me show you something. Here is a minimal user registration form using Reactive Forms:

import { Component, OnDestroy, OnInit } from '@angular/core';
import {
  FormBuilder,
  FormGroup,
  Validators,
  ReactiveFormsModule
} from '@angular/forms';
import { Subject, takeUntil } from 'rxjs';

@Component({
  selector: 'app-registration',
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="form" (ngSubmit)="onSubmit()">
      <input formControlName="email" />
      @if (form.get('email')?.invalid && form.get('email')?.touched) {
        <span>Email is required</span>
      }
      <button type="submit">Register</button>
    </form>
  `
})
export class RegistrationComponent implements OnInit, OnDestroy {
  form!: FormGroup;
  private destroy$ = new Subject<void>();

  constructor(private fb: FormBuilder) {}

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

    this.form.get('email')!.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(value => {
        // do something
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }

  onSubmit(): void {
    if (this.form.valid) {
      console.log(this.form.value);
    }
  }
}

There is a lot going on here that has nothing to do with the actual form logic. You have lifecycle methods, manual subscription teardown with Subject, and imperative wiring between the FormBuilder and the template. Now multiply this across dozens of forms in a real application.

Reactive Forms were built in a different era of Angular — before Signals, before zoneless change detection, before the framework had a unified reactivity model. They work, but they carry the weight of that history. Every valueChanges subscription is a subscription that needs to be cleaned up. Every patchValue call is a push-based mutation that the rest of your Signal-based code has to accommodate.

Signal Forms were designed to fit naturally into the Signal ecosystem, with a model-driven API that is reactive by default and requires almost no boilerplate.

What Are Signal Forms?

At their core, Signal Forms replace the FormGroup/FormControl tree with a FieldTree — a deeply nested Signal structure where every property of your form model is represented as a Signal, complete with form state like dirty, invalid, touched, and errors.

The mental model shift is significant: instead of constructing a parallel form structure that mirrors your data model, you hand your data Signal directly to the form() function. Angular builds the FieldTree from it, and the template binds to that tree. There is no synchronization step, no patchValue, and no subscription to manage.

Here is the architecture at a glance:

Signal (your data)
       |
    form()
       |
    FieldTree (FieldRoot + FieldNode per property)
       |
  FormField directive (binds input -> FieldNode)
       |
   Template

Every node in the FieldTree is reactive. Reading field.value(), field.dirty(), or field.errors() in a template creates a reactive dependency — Angular will re-render only the parts of the template that actually consumed the changed signal.

Creating Your First Signal Form

Let us start with the simplest possible case: a contact form with a name and email.

import { Component, signal } from '@angular/core';
import { form, required } from '@angular/forms/signals';
import { FormField } from '@angular/forms/signals';

interface ContactModel {
  name: string;
  email: string;
}

@Component({
  selector: 'app-contact-form',
  imports: [FormField],
  template: `
    <form (submit)="onSubmit($event)">
      <div>
        <label for="name">Name</label>
        <input id="name" [formField]="contactForm.name" />
        @let nameField = contactForm.name();
        @if (nameField.touched() && nameField.invalid()) {
          <span class="error">Name is required</span>
        }
      </div>

      <div>
        <label for="email">Email</label>
        <input id="email" type="email" [formField]="contactForm.email" />
        @let emailField = contactForm.email();
        @if (emailField.touched() && emailField.invalid()) {
          <span class="error">Valid email is required</span>
        }
      </div>

      <button type="submit" [disabled]="contactForm().invalid()">Submit</button>
    </form>
  `
})
export class ContactFormComponent {
  protected readonly model = signal<ContactModel>({ name: '', email: '' });

  protected readonly contactForm = form(this.model, (f) => {
    required(f.name);
    required(f.email);
  });

  protected onSubmit(event: SubmitEvent): void {
    event.preventDefault();
    if (this.contactForm().valid()) {
      console.log(this.contactForm().value());
    }
  }
}

Notice what is not there. No FormBuilder. No ngOnInit. No this.form.get('email'). The form() function takes your Signal and an optional schema callback where you declare validation rules. What comes back is the FieldTree — and you bind directly to each node in the template using [formField].

FormRoot Explained

FormRoot is what form() returns at the top level. Think of it as the Signal Forms equivalent of FormGroup, but it is a Signal itself rather than a plain class instance.

Calling contactForm() — invoking it like a function — gives you access to the root-level form state:

// Check the whole form
const isFormValid = this.contactForm().valid();
const isFormDirty = this.contactForm().dirty();
const formValue = this.contactForm().value();

// Reset the entire form to its initial model value
this.contactForm().reset();

// Mark all fields as touched (useful before submit)
this.contactForm().markAllAsTouched();

One important behavior in Angular 22: markAsTouched() now marks a field and all its descendants as touched in one call. If you want to mark only the field itself without touching children, you pass { skipDescendants: true }.

FormField Explained

Each property in your FieldTree is a FormField — a Signal node that holds the field's current value and its form state. Reading any of these in a template creates a reactive dependency:

@Component({
  template: `
    <input [formField]="userForm.username" />

    @let username = userForm.username();
    @if (username.touched()) {
      @if (username.getError('required')) {
        <div class="error">Username is required</div>
      }
      @if (username.getError('minLength'); as minLengthError) {
        <div class="error">
          Username must be at least {{ minLengthError.minLength }} characters
        </div>
      }
    }
  `
})

The new getError() method in Angular 22 is a significant quality-of-life improvement. Previously, you had to iterate over field.errors() to find the specific error you wanted. Now you call getError('required') directly, and it narrows the return type for you — so TypeScript knows the shape of the minLength error object.

The key FormField state signals are:

field.value() — the current value
field.dirty() — true if the user has changed the value
field.touched() — true if the field has been blurred
field.invalid() — true if any validator is failing
field.errors() — the full error map
field.getError('key') — typed access to a specific error

Validation in Signal Forms

Built-in Validators

Angular 22's Signal Forms ship with a set of familiar validators, imported from @angular/forms/signals:

import {
  form,
  required,
  minLength,
  maxLength,
  pattern,
  email,
  min,
  max,
  minDate,
  maxDate
} from '@angular/forms/signals';

protected readonly profileForm = form(this.profile, (f) => {
  required(f.username);
  minLength(f.username, 3);
  maxLength(f.username, 30);
  pattern(f.username, /^[a-zA-Z0-9_]+$/);
  required(f.email);
  email(f.email);
  min(f.age, 18);
  max(f.age, 120);
  // Angular 22 new additions
  minDate(f.birthDate, new Date('1900-01-01'));
  maxDate(f.birthDate, new Date());
});

The minDate and maxDate validators are new in Angular 22 and add minDate/maxDate errors to the field's error map if the date value falls outside the specified range.

Custom Validators

Writing a custom validator is a plain function — no class, no AbstractControl:

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

function noSpaces(field: FormFieldNode<string>): void {
  // Register a validator on this field
  field.addValidator({
    kind: 'noSpaces',
    validate: ({ valueOf }) => {
      const value = valueOf(field);
      return value.includes(' ')
        ? { noSpaces: { message: 'Value must not contain spaces' } }
        : null;
    }
  });
}

// Usage in form schema
protected readonly usernameForm = form(this.userModel, (f) => {
  required(f.username);
  noSpaces(f.username);
});

@if (usernameForm.username().getError('noSpaces'); as err) {
  <div class="error">{{ err.message }}</div>
}

The `when` Option

Angular 22 standardizes how conditional validators work. All validators and dynamic behaviors (disabled, readonly, hidden) now accept a when option:

protected readonly checkoutForm = form(this.order, (f) => {
  required(f.billingAddress);
  // Only validate shipping address when it differs from billing
  required(f.shippingAddress, {
    when: ({ valueOf }) => valueOf(f.useDifferentShipping)
  });
});

The old syntax of passing the reactive function as a direct argument still works but is now deprecated.

Async Validation

Async validation is where Signal Forms really shine compared to Reactive Forms. Rather than dealing with AsyncValidatorFn and Observable chains, you use validateHttp() to wire up an HTTP check declaratively:

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

@Component({
  selector: 'app-register',
  imports: [FormField],
  template: `
    <input [formField]="registrationForm.email" type="email" />
    @let emailField = registrationForm.email();
    @if (emailField.isValidating()) {
      <span>Checking availability...</span>
    }
    @if (emailField.touched() && emailField.getError('emailTaken')) {
      <span class="error">This email is already registered</span>
    }
  `
})
export class RegisterComponent {
  protected readonly user = signal({ email: '', password: '' });

  protected readonly registrationForm = form(this.user, (f) => {
    required(f.email);
    validateHttp(f.email, {
      request: (email) => ({
        url: `/api/users/check-email`,
        params: { email: email.value() }
      }),
      error: 'emailTaken',
      debounce: 400
    });
  });
}

The debounce: 400 option tells Angular to wait 400 milliseconds after the last keystroke before sending the HTTP request. This replaces what used to require a custom debounceTime operator in an Observable pipe.

Debounce Support

Debouncing in Signal Forms comes in three flavors in Angular 22:

1. Debounce a field's value changes on input:

protected readonly searchForm = form(this.search, (f) => {
  debounce(f.query, 300);
});

2. Debounce only the async validators:

validateHttp(f.username, {
  request: (username) => `/api/users/check?username=${username.value()}`,
  error: 'usernameTaken',
  debounce: 500
});

3. Debounce a field's value changes on blur (new in Angular 22):

protected readonly form = form(this.model, (f) => {
  debounce(f.password, 'blur');
});

The 'blur' option is particularly useful for password fields and other inputs where you want to validate only after the user finishes typing and moves on — rather than on every keystroke.

Reactive Forms vs Signal Forms — A Direct Comparison

Aspect	Reactive Forms	Signal Forms
API surface	`FormGroup`, `FormControl`, `FormBuilder`	`form()`, `FieldTree`, `FormField`
RxJS dependency	Required (`valueChanges`, `statusChanges`)	None
Subscription management	Manual (`takeUntil`, `unsubscribe`)	Automatic
Change detection	Requires manual `markForCheck` in some cases	Fine-grained via Signals
Validation syntax	`Validators.required` in constructor	`required(f.field)` in schema
Async validation	`AsyncValidatorFn` with Observables	`validateHttp()` declaratively
Boilerplate	High	Low
Learning curve	Moderate (but familiar)	Low for Signal users
Template ergonomics	`form.get('field')?.invalid`	`formField().invalid()`
Debugging	Console logs, DevTools	Signal DevTools, typed errors
Scalability	Good	Excellent
Migration path	None needed	Gradual (compatible with CVA)

The biggest practical difference: with Reactive Forms, you are always managing two things — your data and your form state. With Signal Forms, there is only one source of truth: the Signal you handed to form(). The form state is derived from it, not a separate parallel construct.

What is the performance story here?

Worth pausing on this question, because "Signals are faster" is thrown around a lot without much substance.

With Reactive Forms under the Eager (formerly Default) change detection strategy, any event in the application — even one completely unrelated to your form — could trigger a re-check of the entire component tree. Angular 22 makes OnPush the default, which already helps. But inside an OnPush component, if you call markForCheck() to update form state, you mark the entire component for re-check — not just the template nodes that actually changed.

Signal Forms are different because each FormField is a Signal. When the email field's invalid() signal changes, Angular knows to update only the template expressions that read emailField.invalid(). Nothing else re-renders.

This becomes noticeable in large forms with many interdependent fields, or in forms that are part of complex component trees. Fine-grained updates are the answer to forms that feel sluggish as they scale.

This is a good moment to ask: are you currently migrating an existing Angular app to use Signals? Or are you starting fresh with Angular 22? Drop a comment below — the migration path is genuinely different depending on your starting point, and I am curious how teams are approaching it.

Migration Guidance

Should you migrate everything right now?

Short answer: no.

Reactive Forms are not going anywhere. They are stable, well-tested in production across millions of Angular applications, and will continue to be supported. There is no deprecation notice.

Signal Forms are the recommended path for new forms you are writing today. For existing forms, the migration calculus depends on a few things:

Forms with complex cross-field dependencies benefit the most — Signal Forms make these relationships explicit and reactive.
Large, heavily customized forms with many third-party ControlValueAccessor components may take longer, but Angular 22 makes this easier: ControlValueAccessor components are now compatible with formField, and any validation errors they define are propagated into the Signal Forms tree.
Utility-focused forms (admin tables, settings panels) where the form logic is simple and working fine — migrate these last, or not at all.

Hybrid Approach

The good news in Angular 22 is that FormValueControl — the new interface for custom form components — is now fully compatible with legacy Reactive Forms and Template-Driven Forms. This means you can migrate your custom components first, then migrate your forms progressively, without breaking the parts that are still using the old API.

Real-World Example: User Registration Form

Let us build something realistic — a registration form with validation, async email checking, debouncing, and a submit handler.

// registration.model.ts
export interface RegistrationModel {
  username: string;
  email: string;
  password: string;
  confirmPassword: string;
  birthDate: Date | null;
}

// registration.component.ts
import { Component, signal, computed } from '@angular/core';
import {
  form,
  required,
  minLength,
  maxLength,
  email,
  minDate,
  maxDate,
  debounce,
  validateHttp
} from '@angular/forms/signals';
import { FormField } from '@angular/forms/signals';
import { RegistrationModel } from './registration.model';

@Component({
  selector: 'app-registration',
  imports: [FormField],
  template: `
    <form (submit)="onSubmit($event)">

      <!-- Username -->
      <div class="field">
        <label for="username">Username</label>
        <input id="username" [formField]="registrationForm.username" />
        @let username = registrationForm.username();
        @if (username.touched()) {
          @if (username.getError('required')) {
            <p class="error">Username is required</p>
          }
          @if (username.getError('minLength'); as err) {
            <p class="error">At least {{ err.minLength }} characters</p>
          }
          @if (username.getError('maxLength'); as err) {
            <p class="error">No more than {{ err.maxLength }} characters</p>
          }
          @if (username.getError('usernameTaken')) {
            <p class="error">This username is already taken</p>
          }
          @if (username.isValidating()) {
            <p class="info">Checking availability...</p>
          }
        }
      </div>

      <!-- Email -->
      <div class="field">
        <label for="email">Email</label>
        <input id="email" type="email" [formField]="registrationForm.email" />
        @let emailField = registrationForm.email();
        @if (emailField.touched()) {
          @if (emailField.getError('required')) {
            <p class="error">Email is required</p>
          }
          @if (emailField.getError('email')) {
            <p class="error">Enter a valid email address</p>
          }
          @if (emailField.getError('emailTaken')) {
            <p class="error">An account with this email already exists</p>
          }
        }
      </div>

      <!-- Password -->
      <div class="field">
        <label for="password">Password</label>
        <input id="password" type="password" [formField]="registrationForm.password" />
        @let passwordField = registrationForm.password();
        @if (passwordField.touched() && passwordField.getError('minLength'); as err) {
          <p class="error">Password must be at least {{ err.minLength }} characters</p>
        }
      </div>

      <!-- Date of Birth -->
      <div class="field">
        <label for="birthDate">Date of Birth</label>
        <input id="birthDate" type="date" [formField]="registrationForm.birthDate" />
        @let birthField = registrationForm.birthDate();
        @if (birthField.touched()) {
          @if (birthField.getError('required')) {
            <p class="error">Date of birth is required</p>
          }
          @if (birthField.getError('maxDate')) {
            <p class="error">Date of birth cannot be in the future</p>
          }
          @if (birthField.getError('minDate')) {
            <p class="error">Please enter a valid date of birth</p>
          }
        }
      </div>

      <button
        type="submit"
        [disabled]="registrationForm().invalid() || registrationForm().isValidating()"
      >
        Create Account
      </button>

    </form>
  `
})
export class RegistrationComponent {
  private readonly initialModel: RegistrationModel = {
    username: '',
    email: '',
    password: '',
    confirmPassword: '',
    birthDate: null
  };

  protected readonly model = signal<RegistrationModel>(this.initialModel);

  protected readonly registrationForm = form(this.model, (f) => {
    // Username
    required(f.username);
    minLength(f.username, 3);
    maxLength(f.username, 20);
    validateHttp(f.username, {
      request: (field) => ({
        url: '/api/users/check-username',
        params: { username: field.value() }
      }),
      error: 'usernameTaken',
      debounce: 400
    });

    // Email
    required(f.email);
    email(f.email);
    validateHttp(f.email, {
      request: (field) => ({
        url: '/api/users/check-email',
        params: { email: field.value() }
      }),
      error: 'emailTaken',
      debounce: 400
    });

    // Password
    required(f.password);
    minLength(f.password, 8);
    // Debounce on blur for password
    debounce(f.password, 'blur');

    // Date of Birth
    required(f.birthDate);
    minDate(f.birthDate, new Date('1900-01-01'));
    maxDate(f.birthDate, new Date());
  });

  protected onSubmit(event: SubmitEvent): void {
    event.preventDefault();
    this.registrationForm().markAllAsTouched();

    if (this.registrationForm().valid() && !this.registrationForm().isValidating()) {
      const payload = this.registrationForm().value();
      console.log('Submitting:', payload);
      // call your registration service here
    }
  }
}

This is a complete, working registration form. No FormBuilder, no ngOnInit, no subscription cleanup. The async validators for username and email both debounce automatically to avoid a server request on every keystroke.

Unit Testing Signal Form Components

Testing Signal Form components is cleaner than testing Reactive Forms because there are fewer moving pieces to mock.

// registration.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { RegistrationComponent } from './registration.component';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';
import { provideHttpClient } from '@angular/common/http';

describe('RegistrationComponent', () => {
  let fixture: ComponentFixture<RegistrationComponent>;
  let component: RegistrationComponent;
  let httpMock: HttpTestingController;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [RegistrationComponent],
      providers: [
        provideHttpClient(),
        provideHttpClientTesting()
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(RegistrationComponent);
    component = fixture.componentInstance;
    httpMock = TestBed.inject(HttpTestingController);
    fixture.detectChanges();
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should mark username as invalid when empty and touched', () => {
    const usernameField = component['registrationForm'].username;
    // Mark as touched to trigger validation display
    usernameField().markAsTouched();
    fixture.detectChanges();

    expect(usernameField().invalid()).toBe(true);
    expect(usernameField().getError('required')).toBeTruthy();
  });

  it('should mark username as invalid when too short', () => {
    const form = component['registrationForm'];
    // Update the model to set the username
    component['model'].update(m => ({ ...m, username: 'ab' }));
    form.username().markAsTouched();
    fixture.detectChanges();

    expect(form.username().getError('minLength')).toBeTruthy();
    expect(form.username().getError('minLength')?.minLength).toBe(3);
  });

  it('should mark email as invalid for incorrect format', () => {
    component['model'].update(m => ({ ...m, email: 'not-an-email' }));
    component['registrationForm'].email().markAsTouched();
    fixture.detectChanges();

    expect(component['registrationForm'].email().getError('email')).toBeTruthy();
  });

  it('should show emailTaken error from async validator', async () => {
    component['model'].update(m => ({ ...m, email: 'existing@example.com' }));
    fixture.detectChanges();

    // Flush the debounce
    await new Promise(resolve => setTimeout(resolve, 500));
    fixture.detectChanges();

    const req = httpMock.expectOne(r => r.url.includes('/api/users/check-email'));
    req.flush({ taken: true }, { status: 200, statusText: 'OK' });
    fixture.detectChanges();

    expect(component['registrationForm'].email().getError('emailTaken')).toBeTruthy();
  });

  it('should not allow submit when form is invalid', () => {
    const submitSpy = jest.spyOn(console, 'log');
    const formElement = fixture.nativeElement.querySelector('form');
    formElement.dispatchEvent(new Event('submit'));
    fixture.detectChanges();

    expect(submitSpy).not.toHaveBeenCalledWith('Submitting:', expect.anything());
  });

  it('should mark all fields as touched on invalid submit', () => {
    const formElement = fixture.nativeElement.querySelector('form');
    formElement.dispatchEvent(new Event('submit'));
    fixture.detectChanges();

    const usernameField = component['registrationForm'].username();
    expect(usernameField.touched()).toBe(true);
  });
});

A few things to notice in these tests. First, you are testing the Signal directly — form.username().invalid() — which is synchronous and does not require a fake AbstractControl. Second, async validator tests use HttpTestingController the same way you would test an httpResource, which keeps the pattern consistent across your test suite.

Key Takeaways

Signal Forms in Angular 22 are not just a cosmetic improvement to Reactive Forms. They represent a fundamentally different model for thinking about form state — one that fits naturally alongside Signals, httpResource, and zoneless change detection.

The three things to take away from this article:

1. The data is the form. You hand a Signal to form() and Angular derives the form state from it. There is no parallel structure to synchronize.

2. Fine-grained reactivity means better performance. Only the template nodes that read a specific Signal re-render when that Signal changes. In large, complex forms this matters a lot.

3. Migration is gradual. Angular 22 ensures ControlValueAccessor and FormValueControl are mutually compatible, so you can migrate piece by piece without rewriting everything at once.

The right time to start using Signal Forms is on the next new form you write. That first one is the fastest way to develop an intuition for how they work.

Bonus Tips

Tip 1: Use linkedSignal for editable server data

When your form model comes from a server (loaded via httpResource), use linkedSignal to connect the resource value to a writable Signal that form() can consume:

protected readonly userResource = httpResource<User>(() => `/api/users/${this.userId()}`);

protected readonly editableUser = linkedSignal(() =>
  this.userResource.value() ?? { username: '', email: '' }
);

protected readonly userForm = form(this.editableUser, (f) => {
  required(f.username);
  required(f.email);
});

When the resource reloads, linkedSignal updates editableUser, which updates the form automatically.

Tip 2: Use reloadValidation() for retry logic

If an async validator fails due to a network error, you can retry it programmatically:

protected retryValidation(): void {
  this.registrationForm.email().reloadValidation();
}

This re-runs all async validators on the field and its descendants without requiring any user interaction.

Tip 3: The @Service decorator pairs well with Signal Forms

Angular 22 introduces the @Service() decorator as shorthand for @Injectable({ providedIn: 'root' }). Use it for services that your form components inject:

import { Service } from '@angular/core';

@Service()
export class UserValidationService {
  checkEmail(email: string) {
    // returns Observable or Promise
  }
}

Tip 4: Global debounced() is available for non-form use cases

Angular 22 also ships an experimental debounced() function that works on any Signal, not just form fields. Useful for search inputs that are not part of a form schema:

protected readonly query = signal('');
protected readonly debouncedQuery = debounced(() => this.query(), 300);
protected readonly results = httpResource(() => `/api/search?q=${this.debouncedQuery.value()}`);

Recap

Angular 22 Signal Forms are stable. Here is what we covered:

Reactive Forms carry significant boilerplate and rely on RxJS in ways that do not compose well with the Signal ecosystem
form() takes a Signal and returns a FieldTree — a deeply nested reactive structure where every property is a Signal with full form state
FormRoot manages top-level form state; FormField nodes manage per-field state with typed error access via getError()
Built-in validators like minDate and maxDate are new in Angular 22; the when option standardizes conditional validation
validateHttp() handles async validation declaratively, with built-in debounce support
The debounce(field, 'blur') option is new in Angular 22 for blur-triggered debouncing
Migration is gradual — ControlValueAccessor components work with Signal Forms out of the box
Testing follows the same pattern as testing other Signal-based code — synchronous and straightforward

What did you think?
Did your mental model of Angular forms shift after reading this, or do you see a case where Reactive Forms still have a clear advantage? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

The OnPush Default Has Arrived: A Practical Guide to Angular 22's Biggest Shift - Here's What Changes (Part 1)

Rajat — Wed, 17 Jun 2026 13:30:00 +0000

A practical, code-first tour of Angular 22's biggest change-detection shift — what breaks, what doesn't, and how to migrate without surprises*

Quick question before we get into it: when was the last time you added ChangeDetectionStrategy.OnPush to a component, ran the app, and then spent the next ten minutes wondering why a value on screen just... stopped updating?

If you've written Angular for more than a few months, that probably rings a bell. OnPush has always been the "fast lane" — fewer wasted checks, better performance — but it came with a tax. You had to opt in, understand exactly what triggers a re-render, and occasionally sprinkle markForCheck() around like seasoning when something didn't refresh the way you expected.

Angular 22 just changed that deal. As of this release, every component that doesn't explicitly set a change detection strategy now runs under OnPush automatically. The fast lane is now just... the lane.

This is part 1 of a series where we're going through Angular 22 feature by feature. This one is all about the change-detection shift specifically — what changed, why now, what can quietly break, and how to migrate without losing a weekend to it.

By the end, you'll know:

What actually changes when OnPush becomes the default — and what doesn't
Why ChangeDetectionStrategy.Default got renamed to Eager, and why that name makes more sense
The one scenario that can silently break your app after upgrading, with zero console errors
Why signals and OnPush are basically built for each other
Where this fits into Angular's bigger move toward zoneless apps
A step-by-step ng update walkthrough so you're not migrating blind

That's a lot of ground, but I promise it's more "oh, that makes sense" than "oh no." Let's get into it.

If you want the rest of this series as it drops — eleven more parts covering everything else in this release — following me here on Medium is the easiest way to not miss one.

Before we dive into the examples, a quick note: these snippets are meant purely for understanding the concepts in this release. Angular 22 only shipped on June 3, 2026, so a couple of the APIs we'll touch — especially the experimental debounced() helper — may still see small signature tweaks in patch releases. Always check the official Angular documentation for the exact, current syntax before shipping any of this to production.

OnPush Becomes the Default Change Detection Strategy

Let's start with the headline change.

Through Angular 21, if you wrote a component and didn't specify a changeDetection property, Angular used what was then called the Default strategy: on every change-detection cycle, it walked the entire component subtree and checked every binding — whether or not anything inside had actually changed. It worked, but in large component trees, it meant a lot of checks that found nothing to update.

As of Angular 22, that's flipped. Any @Component without an explicit changeDetection property now uses ChangeDetectionStrategy.OnPush automatically. No decorator property, no extra import, nothing to opt into.

Here's what that looks like in practice:

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

@Component({
  selector: 'app-counter',
  // No changeDetection property here -- this component is OnPush
  // automatically in Angular 22.
  template: `
    <button (click)="increment()">Count: {{ count() }}</button>
  `,
})
export class CounterComponent {
  readonly count = signal(0);

  increment() {
    this.count.update(c => c + 1);
  }
}

Nothing in that file mentions OnPush — and yet it behaves exactly like an OnPush component always has: Angular skips this subtree unless something inside explicitly says "something changed." Here, the signal read inside {{ count() }} and the (click) event binding both qualify, so the button updates correctly with zero extra ceremony.

If you've got a component that genuinely needs the old "check everything, every time" behavior — say, it wraps a third-party widget that mutates the DOM behind Angular's back — you can still opt into that explicitly:

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

@Component({
  selector: 'app-legacy-widget',
  changeDetection: ChangeDetectionStrategy.Eager, // restores pre-v22 default behavior
  template: `...`,
})
export class LegacyWidgetComponent {}

Which brings us to that name — Eager. Where did Default go?

ChangeDetectionStrategy.Default Is Now ChangeDetectionStrategy.Eager

This is a small change with a satisfying reason behind it.

ChangeDetectionStrategy.Default was deprecated in Angular 21.2 and replaced by ChangeDetectionStrategy.Eager in Angular 22. Both values represent exactly the behavior they always did — check the whole subtree, every time — but the new name describes what the strategy does, instead of describing its position in a list.

Think about it from the framework's point of view: once OnPush became the default, calling the other option "Default" stopped making sense. Default... compared to what? The Angular team's own discussion on this rename put it nicely: Default used to mean "run change detection on me by default," not "I am the default strategy" — and that mismatch was confusing enough to be worth fixing.

So now you have two clearly named strategies:

OnPush — skip this subtree unless something explicitly marks it dirty (the new default)
Eager — check this subtree on every CD run, no matter what (the old default, now opt-in)

If your codebase had components explicitly setting ChangeDetectionStrategy.Default, ng update rewrites them for you:

// Before Angular 22
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Default,
  template: `...`,
})
export class OldComponent {}

// After ng update to Angular 22 -- same runtime behavior, new name
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `...`,
})
export class OldComponent {}

Here's the side-by-side that I think makes this click fastest:

	`Eager` (formerly `Default`)	`OnPush` (now the default)
Default through...	Angular 21	Angular 22 onward
Subtree checked when	Every CD run, unconditionally	Only when something marks it dirty
What marks it dirty	Nothing needed — always checked	Signal reads in the template, `async` pipe emissions, event bindings, input changes, `markForCheck()`
Best fit	Legacy code mutating plain fields directly	Signal-based, zoneless-ready components

Once you see it laid out this way, the rename stops feeling cosmetic — it's Angular finally calling things what they actually are.

Now, here's the part I really want you to slow down for, because it's the one that can bite you with zero warning.

Quick gut check before we move on: have you ever upgraded a dependency and had some piece of UI just... stop updating, with nothing in the console to explain why? Hold that thought — the next section is exactly that scenario, and I'd genuinely like to know in the comments afterward whether it matches what you ran into.

Impact on Existing Apps: The Good News and the One Catch

Let's get the good news out of the way first.

When you run ng update to Angular 22, the migration:

Adds changeDetection: ChangeDetectionStrategy.Eager to every component decorator that doesn't already specify a strategy — preserving your exact pre-upgrade behavior.
Renames any existing ChangeDetectionStrategy.Default to ChangeDetectionStrategy.Eager.
Leaves any existing ChangeDetectionStrategy.OnPush alone.

In other words: your own application code keeps working exactly as it did the moment before you upgraded. Angular doesn't silently flip your components to OnPush behind your back — it explicitly tags them as Eager so nothing changes at runtime. That's the whole point of the migration.

So where's the catch?

ng update can only rewrite the source files inside your project. It has no way to touch code that's already compiled and sitting inside node_modules.

Picture a third-party library — say, a price-ticker widget — that ships a component with no explicit changeDetection, and updates its template by writing to a plain class property inside an RxJS subscription:

// A library component published before Angular 22.
// No explicit changeDetection -- pre-v22 this ran "check everything"
// and worked fine.
@Component({
  selector: 'price-ticker',
  // No changeDetection set here.
  template: `<span>Latest price: {{ price }}</span>`,
})
export class PriceTickerComponent implements OnInit {
  price = 0;

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p; // plain field write -- Angular is never told to re-check
    });
  }
}

Before Angular 22, this worked because the component ran under Eager (then called Default) — Angular checked it on every cycle regardless. After you upgrade your app to Angular 22, that compiled library code still has no changeDetection property... which now means OnPush.

The result: the price stops updating on screen. No error. No console warning. No exception. The data is still arriving — prices$ is still emitting — but Angular was never told this component needs re-checking, so the template binding just freezes. If that same library does something imperative, like drawing onto a <canvas>, that keeps working fine. It's specifically Angular's template bindings — {{ }}, property bindings — that stop refreshing.

This is the single most important thing to test after upgrading: any third-party components that display live, push-based data.

If you hit this, you've got two options. The quick one, if you're still on zone.js:

export class PriceTickerComponent implements OnInit {
  price = 0;
  private cdr = inject(ChangeDetectorRef);

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p;
      this.cdr.markForCheck(); // works with zone.js; does not help in zoneless apps
    });
  }
}

And the one that actually fixes it for good — bridge the observable into a signal:

import { Component, DestroyRef, inject } from '@angular/core';
import { takeUntilDestroyed, toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'price-ticker',
  template: `<span>Latest price: {{ price() }}</span>`,
})
export class PriceTickerComponent {
  private feed = inject(PriceFeedService);
  private destroyRef = inject(DestroyRef);

  readonly price = toSignal(
    this.feed.prices$.pipe(takeUntilDestroyed(this.destroyRef)),
    { initialValue: 0 },
  );
}

toSignal() turns the observable into a signal, and writing to a signal that's read in the template automatically marks the component dirty. This works correctly under Eager or OnPush, with zone.js or without it — which is really the whole theme of this release.

A handful of other breaking changes landed in the same v22 release, most of them auto-migrated:

strictTemplates is now true by default in tsconfig.json — the migration adds strictTemplates: false if you weren't using it, so your build doesn't suddenly fail on new type errors.
Optional chaining in templates now matches TypeScript semantics: project?.author returns undefined (not null) when the chain breaks. The migration wraps affected expressions in $safeNavigationMigration(...) so you can review them on your own schedule. On the upside, the compiler can now correctly narrow project?.author inside an @if (project?.author) guard, so a lot of those defensive ?. usages can eventually come out entirely.
HttpClient now defaults to the Fetch-based backend. withFetch() is deprecated and removed by the migration — or replaced with withXhr() if you relied on upload-progress events, which Fetch doesn't support.
provideClientHydration() now enables incremental hydration by default; the migration adds withNoIncrementalHydration() if you weren't previously opted in.
The canMatch guard signature gains a mandatory third parameter, currentSnapshot — auto-migrated. paramsInheritanceStrategy now defaults to 'always' — this one is not auto-migrated, so check your router config if your app relies on the old 'emptyOnly' behavior.
The toolchain floor moved up: TypeScript 6 is required (5.9 and below are unsupported), and Node 20 support is dropped (Node 22+ required, Node 26 officially supported).

None of these are scary individually, but they're exactly the kind of thing that's easy to skim past in a changelog and then debug three weeks later. Worth a slow read through your ng update diff.

Signals and OnPush: Why They Were Basically Built for Each Other

Here's the conceptual thread that ties this whole release together.

Signals tell Angular what changed. OnPush tells Angular what to skip. Put those together and you get a complete fine-grained reactivity model — and that's really why making OnPush the default "completes" the signals story rather than being some unrelated cleanup item.

Under the old Eager strategy, this distinction was invisible, because everything got checked regardless of whether a signal changed. Under OnPush, it's the entire mechanism: when a signal that's read in a template updates, Angular marks that component dirty and schedules a CD run. If nothing marks it dirty, the subtree is skipped entirely. The signal is the dirty flag.

This is also why the Resource API graduating to stable in Angular 22 matters so much for this topic. resource, rxResource, and httpResource all move from experimental to stable in this release, and httpResource in particular is a genuinely pleasant way to fetch data reactively:

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
import { CurrencyPipe } from '@angular/common';

interface Product {
  id: number;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-list',
  imports: [CurrencyPipe],
  template: `
    @if (productsResource.isLoading()) {
      <p>Loading products...</p>
    }
    @if (productsResource.error()) {
      <p>Something went wrong loading products.</p>
    } @else {
      @for (product of productsResource.value(); track product.id) {
        <div>{{ product.name }} -- {{ product.price | currency }}</div>
      }
    }
  `,
})
export class ProductListComponent {
  readonly category = signal('electronics');

  // Re-fetches automatically whenever category() changes.
  readonly productsResource = httpResource<Product[]>(
    () => `/api/products?category=${this.category()}`,
    { defaultValue: [] },
  );
}

Notice there's no changeDetection here either — it's OnPush by default, and it doesn't need to be anything else. productsResource.value(), .isLoading(), and .error() are all signals, so reading them in the template is exactly the "tell Angular what changed" signal that OnPush needs.

Angular 22 also adds an experimental debounced() helper, which is handy for search-as-you-type without hand-rolling RxJS debounceTime. One thing worth getting right here: debounced() takes a reactive function that reads a signal — not the signal itself — and it returns a Resource, not another signal:

import { Component, signal, debounced } from '@angular/core';
import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-search',
  template: `
    <input (input)="query.set($any($event.target).value)" placeholder="Search products..." />

    @if (debouncedQuery.isLoading()) {
      <p>Waiting for you to stop typing...</p>
    }

    @for (result of results.value(); track result.id) {
      <div>{{ result.name }}</div>
    }
  `,
})
export class SearchComponent {
  readonly query = signal('');

  // Settles 300ms after `query` stops changing.
  // Note: debounced() takes a function that reads the signal, not the signal itself.
  readonly debouncedQuery = debounced(() => this.query(), 300);

  readonly results = httpResource<{ id: number; name: string }[]>(
    () => `/api/search?q=${this.debouncedQuery.value()}`,
    { defaultValue: [] },
  );
}

While the user is typing, debouncedQuery.isLoading() is true, and debouncedQuery.value() still holds the last settled value — so your results don't flicker on every keystroke, and httpResource only re-fires once things have actually stabilized. Since debounced() is still experimental in v22, double-check its exact signature against whatever patch version you've got installed before shipping it.

The Zoneless Future: Where This Fits in the Bigger Picture

If you've been keeping half an eye on Angular over the last couple of years, this release probably doesn't feel like it came out of nowhere — and it shouldn't. Here's the timeline:

Angular 18 introduced zoneless change detection as an experimental preview, behind provideExperimentalZonelessChangeDetection.
Angular 19 refined the zoneless APIs and added SSR support.
Angular 20.2 promoted provideZonelessChangeDetection() to stable.
Angular 21 made zoneless the default for new applications — ng new no longer wires up zone.js or calls provideZonelessChangeDetection() explicitly; it's simply the baseline. Existing apps keep zone.js until they choose to remove it.
Angular 22 makes OnPush the default change detection strategy — the piece that makes zoneless apps performant by default, not just functional.

Put together: "check everything via zone.js" is no longer the starting point for any new Angular app. Signals tell Angular what changed, OnPush skips everything that wasn't touched, and zoneless removes the layer that used to trigger a check on every async operation.

That last part is the one that trips people up, so let's make it concrete. In a zone.js app, this used to "just work":

// Worked in zone.js apps because zone.js patches setTimeout
// and triggers a CD run when the callback fires.
@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count }}</p>`,
})
export class AsyncDemoComponent {
  count = 0;

  ngOnInit() {
    setTimeout(() => {
      this.count++; // in a zoneless/OnPush app, the template silently won't update
    }, 1000);
  }
}

In a zoneless (or just plain OnPush) app, nothing tells Angular that count changed — setTimeout isn't patched, so there's no automatic CD trigger. The fix is the same one we used for the price ticker: make the state a signal.

@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count() }}</p>`,
})
export class AsyncDemoComponent {
  count = signal(0);

  ngOnInit() {
    setTimeout(() => {
      this.count.update(c => c + 1); // marks the view dirty -- re-renders correctly
    }, 1000);
  }
}

And if you want to go fully zoneless explicitly — still entirely valid, just no longer something a brand-new project needs to add by hand:

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideZonelessChangeDetection,
  provideBrowserGlobalErrorListeners,
} from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection(),
    provideBrowserGlobalErrorListeners(),
  ],
});

The rule of thumb going forward: change detection runs when a signal read in a template updates, the async pipe gets a new value, a template event fires, or something explicitly calls markForCheck() / ApplicationRef.tick(). Anything outside those four — a raw timer, a manual subscription writing to a plain field, a third-party library mutating data behind Angular's back — needs to be bridged into a signal to participate in rendering.

Migration Considerations: The ng update Walkthrough

Let's turn all of this into a checklist you can actually run through.

Step 1 — confirm your toolchain meets the new minimums:

node -v    # needs to be >= 22 (26 is supported)
npx tsc -v # needs to be >= 6.0

Step 2 — run the update. This applies every automatic migration we've covered: tagging unspecified components as Eager, renaming Default to Eager, the strictTemplates flag, the $safeNavigationMigration wrapper, the HTTP client changes, and the hydration flag.

ng update @angular/core@22 @angular/cli@22

Step 3 — build and run your full test suite. Most regressions from a change like this surface here, not in manual testing.

ng build
ng test

Step 4 — review what the migration actually touched, one concern at a time, instead of just accepting the diff:

grep -rn "ChangeDetectionStrategy.Eager" src/
grep -rn "\$safeNavigationMigration" src/
grep -rn "withNoIncrementalHydration\|withXhr" src/

That third command finds the optional-chaining wrappers and the HTTP/hydration flags — both things the migration added purely to preserve old behavior, and both good candidates to revisit once you've confirmed everything still works.

What ng update does not do for you:

It won't touch third-party node_modules packages — that's the "silent freeze" scenario from earlier. Your options are waiting for the library to update, wrapping its data source yourself with toSignal(), or pinning the dependency until you're ready to deal with it.
It won't change paramsInheritanceStrategy — if your app depends on the pre-v22 default, set it to 'emptyOnly' explicitly in your router config.
It won't convert your Eagertagged components to OnPush for you. That's a deliberate, per-component decision, and it usually starts with converting the component's state to signals.

That last point is worth walking through, because it's the actual "finish line" for each component. Here's one right after ng update — auto-migrated, behaving exactly as before:

// Right after ng update -- auto-generated, preserves old behavior.
@Component({
  selector: 'app-profile',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `<p>{{ user?.name }}</p>`,
})
export class ProfileComponent implements OnInit {
  user?: User;
  constructor(private userService: UserService) {}
  ngOnInit() {
    this.userService.getUser().subscribe(u => this.user = u);
  }
}

And here's the manual follow-up: convert the state to a signal, then delete the changeDetection line entirely.

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

// Manual follow-up -- state is now a signal, no changeDetection override needed.
@Component({
  selector: 'app-profile',
  template: `<p>{{ user()?.name }}</p>`,
})
export class ProfileComponent {
  private userService = inject(UserService);
  readonly user = toSignal(this.userService.getUser());
}

No replacement annotation needed — OnPush is the default. That component is done.

Unit Testing OnPush and Signal-Based Components

A question I hear a lot when people first work with OnPush: "does this break my tests?" Mostly, no — but there's one habit worth building.

With TestBed, fixture.detectChanges() works exactly the same under OnPush as it always has when called manually — it forces a check regardless of whether the component thinks it's dirty. The difference only shows up when you're testing that an update happens automatically, without you calling detectChanges() yourself — which is precisely where signals help.

Here's a test for the CounterComponent from earlier:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

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

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

    fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges();
  });

  it('renders the initial count', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 0');
  });

  it('updates the displayed count when the signal changes', () => {
    fixture.componentInstance.increment();
    fixture.detectChanges();

    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 1');
  });

  it('updates the count via a real click event', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');

    button.click();
    fixture.detectChanges();

    expect(button.textContent).toContain('Count: 1');
  });
});

A few things worth calling out:

We call fixture.detectChanges() after each state change — that's the test-environment equivalent of "Angular ran a CD cycle," and it's required regardless of strategy.
The third test fires a real DOM click, exercising the (click) event binding directly. This is the kind of test that used to quietly pass or quietly fail depending on which strategy a component happened to use — and now behaves consistently, because OnPush is the strategy either way.
If you're testing a component built around toSignal() and an observable (like our PriceTickerComponent), the same pattern applies: push a value through your mock service's subject, call fixture.detectChanges(), and assert on the rendered output. The signal write marks the view dirty; detectChanges() flushes it in the test.

If you're migrating your test setup to Vitest as part of this upgrade — Angular 22 continues investing here, including better fakeAsync support for teams making that move gradually — the same testing pattern applies. Only the runner and assertion syntax change, not the OnPush-related behavior itself.

Bonus Tips

A few smaller things that didn't need their own section but are worth keeping in your back pocket:

If a component "stops updating" after upgrading and you're not sure why, check whether it's coming from a third-party package first. The node_modules "silent freeze" is by far the most common surprise from this release.
You don't have to convert everything to signals on day one. Letting ng update mark your existing components as Eager and migrating component-by-component, on your own schedule, is exactly what the migration was designed to support.
Angular DevTools' signal graph is genuinely useful here, even if you're not pairing it with an AI agent — it's one of the fastest ways to see why a component did or didn't update.
When you do start converting components, prioritize the ones that already read from observables via async or manual subscriptions. Those are the most likely to have a "plain field write" hiding inside them, and toSignal() is almost always the cleanest fix.

Have you hit the "silent freeze" scenario yet, either during a test upgrade or in production? I'd genuinely love to know which library it was — drop it in the comments, it might save someone else a debugging session.

Recap

Here's the whole picture in one pass.

Angular 22 makes OnPush the default change detection strategy for any component that doesn't say otherwise. The old "check everything" behavior didn't disappear — it got renamed from Default to Eager, a name that actually describes what it does. ng update automatically tags your existing components as Eager so nothing changes at runtime on upgrade day, but it can't touch compiled code in node_modules — which is where the one real risk lives: third-party components with no explicit strategy and plain-field updates inside subscriptions can silently stop refreshing. The fix is always the same: bridge state into a signal with toSignal(), because a signal read in a template is exactly the "something changed" notification that OnPush — and zoneless apps — are built around. This release is also where the Resource API (resource, rxResource, httpResource) goes stable, and where the experimental debounced() helper shows up for search-as-you-type patterns.

If you take away one thing: go find the components that update via raw subscriptions or setTimeout, and start converting their state to signals. That single habit covers most of what this release changes for you.

What's your plan for rolling this out — run ng update and handle issues as they surface, or do a slower, component-by-component signal migration first? Tell me which one and why — I'm curious whether teams are converging on one approach.

What did you think?
Did this approach match how you're solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too — and if you've got a teammate who's about to upgrade to Angular 22, send this their way before they run into the silent-freeze surprise firsthand.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let's connect — find me on LinkedIn or GitHub and let's keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

DEV Community: Rajat

Angular Is Preparing for AI Agents: WebMCP, MCP Tooling, and Agent Skills in Angular 22 - - What Changes in NG 22 (Part 10)

How Angular 22 lets AI coding agents build your app faster, debug it live, and — with WebMCP — actually call it like a tool

Two different problems, both labeled "AI"

Agent Skills: teaching your coding agent how Angular actually works

Debugging with AI: exposing the signal graph and the DI graph

WebMCP: your app as a tool an agent can call

Declaring a tool imperatively

The declarative path: auto-registering tools from Signal Forms

Testing the logic behind a WebMCP tool

Bonus tips

Recap

Follow Me for More Angular & Frontend Goodness:

Angular 22.2 Finally Lets Your Templates Touch Private Class Members

The compiler error you have been silently working around for years is about to disappear

What Actually Changed in Angular 22.2

Nested Private Members Still Throw an Error

Private Members Work in Host Bindings Too

Why This Matters for isolatedDeclarations

Testing Components with Private State

Bonus Tips

Recap

Angular 22.1 Is Out — Here's Every Feature Worth Your Attention

A practical, code-first walkthrough of the new release cadence, the @Service() migration, linkedSignal's custom setter, untracked interceptors, and what it all means for your next sprint

1. The Big One: Angular Is Switching to a Yearly Major Release

2. Migrating to @Service() Without Touching Every File by Hand

3. linkedSignal Gets a Custom Setter

4. HTTP Interceptors No Longer Leak Into Your Effects

5. Smaller but Genuinely Useful: DevTools Improvements

Testing It All: Unit Tests for Signal-Based Standalone Components

A Bonus Tip Before You Go

Recap

What did you think?

Follow Me for More Angular & Frontend Goodness:

Angular Templates Just Got More Powerful — Here's What Angular 22 Actually Changed - What Changes in NG 22 (Part 9)

Template comments, spread syntax, arrow functions, and stricter type checking that catches bugs before they ship

Comments inside HTML elements

Spread syntax and rest arguments in templates

Arrow functions in event bindings and loops

Stricter type checking, on by default

Exhaustive @switch checks

Testing template behavior, not just describing it

Bonus tips

Recap

Follow Me for More Angular & Frontend Goodness:

Router Changes: paramsInheritanceStrategy, Stricter Guards, and the Navigation API - What Changes in NG 22 (Part 8)

paramsInheritanceStrategy, stricter route guards, and how the Router now talks to the browser's Navigation API

The problem: route params that don't travel

Angular 22's new default: params inherit automatically

CanMatch guards now require a third parameter

Finer control over stale route inputs

Checking active routes with a signal instead of a directive

The Router talking to the browser's Navigation API

Testing the new router behavior

Bonus tips

Recap

Follow Me for More Angular & Frontend Goodness:

Angular's Resource APIs Are Finally Stable - Say Goodbye to Manual Loading States - What Changes in NG 22 (Part 7)

How resource(), httpResource(), and rxResource() in Angular 22 replace your isLoading flags with a proper signal-based data model

Why resources exist in the first place

Meet httpResource()

Chaining resources without nesting subscriptions

You don't need to worry about race conditions anymore

rxResource() — for when you're not ready to leave RxJS behind

The lowest-level option: plain resource()

Testing components that use resources

Bonus tips

Recap

Follow Me for More Angular & Frontend Goodness:

Angular 22 Is Officially Signal-First: Here's Everything That Changed - Here's What Changes in NG 22 (Part 6)

A practical walkthrough of resource(), rxResource(), httpResource(), and the new debounced() utility — with working code and tests

Why Angular 22 Is a Bigger Deal Than It Looks

resource(): The Foundation

rxResource(): For When You Already Have an Observable

httpResource(): The Shortcut for HTTP Calls

debounced(): Debouncing Without RxJS

Unit Testing Signal-Based Components

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Exhaustive `@switch` checks

`CanMatch` guards now require a third parameter

How `resource()`, `httpResource()`, and `rxResource()` in Angular 22 replace your isLoading flags with a proper signal-based data model

Meet `httpResource()`

`rxResource()` — for when you're not ready to leave RxJS behind

The lowest-level option: plain `resource()`

A practical walkthrough of `resource()`, `rxResource()`, `httpResource()`, and the new `debounced()` utility — with working code and tests

The `when` Option