DEV Community: Rajat

Angular 22.2 Explained: Router Resources, Error Boundaries, and Private Template Access

Rajat — Tue, 20 Oct 2026 13:30:00 +0000

Three developer-preview features that quietly change how you load data, isolate failures, and structure components

Have you ever opened a page and watched it flicker through an empty state, a spinner, and finally real data, all because the component had to manage its own loading? Angular 22.2 gives us a cleaner way to handle this with router resources, and it ships two other changes worth knowing.

Since Angular now ships only one major release per year, the minors carry real weight. This one brings router resources, error boundaries (both in developer preview), and access to private members from templates.

If you like practical Angular breakdowns written like a chat between devs, follow me here on Medium so you do not miss the next one.

What You Will Learn

By the end of this article, you will know how to:

Load data in the router with router resources, so your component receives the final value
Isolate failing child components with @boundary and @error
Use private members directly in templates, and why #private fields no longer fit
Write unit tests for each of these features

Note: 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 the features covered here are in developer preview. Always refer to the official documentation for the most current API and syntax.

Feature 1: Angular Router Resources

The problem with loading inside the component

Imagine a holidays page. A service creates a resource, and the component consumes it. The resource only starts when the component is created, and the component must handle the loading state, where the value may not exist yet.

Here is the typical setup. First, a small service that exposes a resource:

// holiday.service.ts
import { Injectable } from '@angular/core';
import { httpResource } from '@angular/common/http';

export interface Holiday {
  id: number;
  title: "string;"
}

@Injectable({ providedIn: 'root' })
export class HolidayService {
  load() {
    return httpResource<Holiday[]>(() => '/api/holidays');
  }
}

This service is a plain injectable that returns an HTTP resource. Nothing is router-specific yet.

Moving the resource into the router

With router resources, the router starts loading during navigation and blocks until the data is ready. Your component then gets the final value.

Define the resource on the route:

// app.routes.ts
import { inject } from '@angular/core';
import { Routes } from '@angular/router';
import { HolidayService } from './holiday.service';
import { HolidaysComponent } from './holidays.component';

export const routes: Routes = [
  {
    path: 'holidays',
    component: HolidaysComponent,
    resources: () => {
      const holidayService = inject(HolidayService);
      return {
        holidays: holidayService.load(),
      };
    },
  },
];

The object literal's key (holidays) is the name under which the loaded value reaches your component. The router also passes a context with params and query params as signals. That matters when a route ID changes, because you can feed that signal into the resource and it refreshes automatically.

Receiving the value as a plain input

// holidays.component.ts
import { Component, input } from '@angular/core';
import { Holiday } from './holiday.service';

@Component({
  selector: 'app-holidays',
  template: `
    @for (holiday of holidays(); track holiday.id) {
      <article>{{ holiday.title }}</article>
    } @empty {
      <p>No holidays found.</p>
    }
  `,
})
export class HolidaysComponent {
  readonly holidays = input.required<Holiday[]>();
}

The component asks for a Holiday[], not a resource. It has no idea the data came from a resource, and the input is public because it is bound from outside.

Enabling the feature

You have to opt in explicitly in your app config:

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter, withRouterResources } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withRouterResources()),
    provideHttpClient(),
  ],
};

Now navigate Home, then Holidays. Loading starts early, inside the router navigation itself.

Where do you load data today: in the component, in a resolver, or in a store? Tell me in the comments and I will cover the migration path in a follow-up.

Unit testing a component that receives router data

Because the component just takes an input, testing is simple. No router needed:

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

describe('HolidaysComponent', () => {
  it('renders holidays passed in as input', async () => {
    const fixture = TestBed.createComponent(HolidaysComponent);
    fixture.componentRef.setInput('holidays', [
      { id: 1, title: "'Vienna' },"
      { id: 2, title: "'Lisbon' },"
    ]);
    await fixture.whenStable();

    const cards = fixture.nativeElement.querySelectorAll('article');
    expect(cards.length).toBe(2);
    expect(cards[0].textContent).toContain('Vienna');
  });

  it('shows the empty message when there are no holidays', async () => {
    const fixture = TestBed.createComponent(HolidaysComponent);
    fixture.componentRef.setInput('holidays', []);
    await fixture.whenStable();

    expect(fixture.nativeElement.textContent).toContain('No holidays found.');
  });
});

The test uses setInput to simulate what the router will provide. That is a nice side effect of this design: the component stays easy to test.

Feature 2: Angular Error Boundaries

Why one broken child hurts everyone

Say the holidays page has two children, a title component and a holiday card. If one throws, the parent has a problem too. Here is a title component that fails on purpose:

// title.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-title',
  template: `<h1>Holidays</h1>`,
})
export class TitleComponent {
  constructor() {
    throw new Error('Title failed to initialize');
  }
}

With this in place, the holidays page shows nothing at all.

Isolating the failure with @boundary and @error

Wrap the risky child in a boundary in the template:

// holidays-page.component.ts
import { Component } from '@angular/core';
import { TitleComponent } from './title.component';

@Component({
  selector: 'app-holidays-page',
  imports: [TitleComponent],
  template: `
    @boundary {
      <app-title />
    } @error {
      <h1>Holidays</h1>
    }

    <section>
      <p>The rest of the page still renders.</p>
    </section>
  `,
})
export class HolidaysPageComponent {}

If app-title throws, the boundary catches it, the @error block acts as the fallback, and the rest of the page stays visible. There are more options, such as conditional catches, but this is the basic shape.

Testing the fallback

// holidays-page.component.spec.ts
import { TestBed } from '@angular/core/testing';
import { HolidaysPageComponent } from './holidays-page.component';

describe('HolidaysPageComponent', () => {
  it('shows the fallback and keeps the page alive when the title throws', async () => {
    const fixture = TestBed.createComponent(HolidaysPageComponent);
    await fixture.whenStable();

    const element: HTMLElement = fixture.nativeElement;
    expect(element.querySelector('h1')?.textContent).toContain('Holidays');
    expect(element.textContent).toContain('The rest of the page still renders.');
  });
});

Because the child throws on purpose, this one test proves both the fallback and the isolation. Depending on how the test environment reports handled errors, you may need to adjust error handling in your test setup.

Feature 3: Private Members in Templates

Before 22.2, a template could only read members that were public or protected. That is why so much modern Angular code is full of protected.

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

@Component({
  selector: 'app-summary',
  template: `<h2>{{ title() }}</h2>`,
})
export class SummaryComponent {
  private readonly title = signal('Summer Holidays');
}

In 22.2, this just works. The reasoning from the Angular team is that the template and the TypeScript class form one unit, not two separate parts. Expect to see more private and fewer protected in modern Angular code.

There is one catch. ECMAScript private fields, the ones with hash notation, are private at runtime too, so the template cannot reach them:

export class SummaryComponent {
  // This will NOT work in the template
  #title = signal('Summer Holidays');
}

Switch to the TypeScript private keyword if the template needs the value.

Testing it

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

describe('SummaryComponent', () => {
  it('renders a private signal in the template', async () => {
    const fixture = TestBed.createComponent(SummaryComponent);
    await fixture.whenStable();

    expect(fixture.nativeElement.querySelector('h2').textContent)
      .toContain('Summer Holidays');
  });
});

Notice we test the rendered output, not the private member. That keeps tests focused on behavior.

Which of the three features will you adopt first? Vote in the comments: A) router resources, B) error boundaries, C) private in templates.

Bonus Tips

Feed route params into resources as signals. When the ID in the URL changes, the resource refreshes on its own, with no manual subscriptions.
Keep fallbacks cheap. An @error block should be simple. A fallback that can also fail defeats the purpose.
Place boundaries around risky areas only. Third-party widgets and optional panels are good candidates. Wrapping everything hides real bugs.
Migrate protected gradually. There is no need for a big-bang refactor. Switch to private when you touch a file anyway.
Skim the changelog. This release has more changes than the three covered here.

Recap

Angular 22.2 brings three notable changes. Router resources move data loading into the router, so your component receives the final value as a plain input. Error boundaries with @boundary and @error stop a single failing child from taking down the page. And private members can now be used in templates, reflecting that the template and class are one unit, though ECMAScript #private fields will not work there.

Both router resources and error boundaries have many more options than shown here. For the full picture, read the official documentation and the changelog, and look at the community's videos and articles. Related reading: [link to your related Angular article here].

If this helped you, share it with a teammate or on social media. It is the easiest way to help another dev find it.

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

Browser Error Tracking: The Errors Your SDK Never Sends

Rajat — Mon, 12 Oct 2026 13:30:00 +0000

An offline-first browser error tracking pipeline that runs inside the failure path, redacts before it stores anything, and slows one repeating failure instead of a whole page.

You are on a call with support. A customer says checkout failed twice this morning. Then it worked. You ask them for the browser console, they send a screenshot, and the console is empty, because the page has been reloaded twice since then. The network tab is gone with it. What you have is one sentence and a timestamp.

Somewhere in your dashboard, that customer has no error. Not a wrong error, not a truncated stack, just nothing. Which means the dashboard is telling you a story about happy users, and the users who are quietly giving up look exactly the same as them.

So here is the question that decides whether your browser error tracking is useful or decorative: what happens to the errors that never reach your tracker at all?

Between here and there you will build a capture pipeline that stores locally before it ever touches the network, redacts before it writes anything, slows one repeating failure without silencing the new ones, and ends in a single HTML file that a support engineer can open and read.

Keep one question in mind while you read, because I answer it near the end. Where does an error go when it is thrown before your tracker starts, and the tab closes a second later?

If debugging is the part of the job you actually like, follow me here on Medium. I publish one practical frontend piece a week and I reply to comments. If someone on your team owns the error dashboard, send them this.

Why browser error tracking fails at the worst possible moment

Quick version. Your reporter is a handful of lines that run after something already went wrong. One call at startup, one call per failure you handle yourself, and a way to get the results out. In the version I use below, that startup call captures uncaught errors, unhandled promise rejections and everything logged at warn or above into IndexedDB, and the results come out when someone presses Ctrl+Shift+Alt+D. It is the smallest piece of your error handling, which is exactly why it gets the least attention.

Real-world version. The failure modes are not exotic. They are the ordinary consequences of running code in a hostile moment.

A convenience reporter that touches error.message on a thrown value that is not an Error throws a second exception inside your catch block. A fetch call that is not keepalive gets cancelled when the tab closes, so the error you captured during pagehide never leaves the browser. A URL pasted into a payload carries whatever token a user's password reset link had in the query string. One broken polling endpoint produces the same error every five seconds until it owns your entire rate limit, and the genuinely new failure that happened at minute three is the one that gets dropped. Any script loaded from a third-party origin can be blocked by an extension or a strict Content Security Policy, and when that happens capture stops silently.

Under the hood. These are not separate bugs to fix one at a time. They come from one design decision: whether the reporting path is allowed to fail. The library I use in the examples below makes five promises to itself, and each one kills a class of the failures above.

It cannot throw, so a hostile value cannot turn reporting into a second crash. It cannot recurse, because a flag drops anything raised while the pipeline is already running. It cannot double count, because a WeakMap remembers the error objects it has already seen. It cannot flood, because a fixed-window limiter drops the excess. It cannot lose pre-init errors, because failures thrown before initTelemetry runs are normalised immediately and replayed once the application metadata exists.

Teaser. Which brings us to the smallest and most important function in the whole system, the one that people write in thirty seconds and regret for a year.

Before we get 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.

The reporter that throws while it reports

Quick version. Here is a helper that a lot of codebases have somewhere, and it looks fine.

// shared/report-error.ts
export function reportError(error: unknown): void {
  const payload = JSON.stringify({
    message: (error as Error).message,
    stack: (error as Error).stack,
    url: window.location.href,
  });

  void fetch('/telemetry/errors', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: payload,
  });
}

It compiles, it runs, and in development it even works. Then production hands it a value that is not an Error, and the same helper fails in four different ways.

(error as Error).message on a thrown string returns undefined and you log an empty record. On null it throws a TypeError, and because this ran inside your own catch block, the original failure is replaced by a new one. window.location.href includes the query string, so a reset link with a token in it is now in your telemetry. And fetch without keepalive is dropped by the browser when the page is closing, which is when the errors you most want are captured.

Real-world version. The fix is not to write a longer version of the same function. It is to route every capture through one ingestion point that owns normalisation, redaction and persistence.

// shared/telemetry.ts
import { captureError, initTelemetry, logger } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  appVersion: '2.4.1',
  environment: 'production',
});

export function reportCheckoutFailure(error: unknown, orderId: string): void {
  captureError(error, {
    tags: { flow: 'checkout', route: '/checkout/:orderId' },
    extra: { orderId },
    severity: 'error',
  });

  logger.warn('[Checkout] payment attempt failed', { orderId });
}

Note what is missing. No window.location.href, because the record picks up page context itself. No .message access, because captureError accepts unknown and normalises whatever it gets. No await, because capturing is fire-and-forget and the write is queued locally before any network is involved.

The library is @codewithrajat/rm-logvault, published on npm with the source on GitHub.

The thrown value is the first argument, which makes the helper safe to call from any catch block you already have, including the one that rethrows.

// checkout-api.ts
import { reportCheckoutFailure } from './telemetry';

export async function payForOrder(orderId: string): Promise<void> {
  try {
    await postPayment(orderId);
  } catch (error) {
    reportCheckoutFailure(error, orderId);
    throw error;
  }
}

The record that lands in IndexedDB after payForOrder('A-1024') fails looks like this, trimmed to the fields that matter.

{
  "schemaVersion": 1,
  "source": "manual",
  "severity": "error",
  "handled": true,
  "thrownType": "error",
  "name": "Error",
  "message": "Payment provider returned 502",
  "fingerprint": "3f2c81a9c4b7d0e5",
  "occurrenceCount": 1,
  "tags": { "flow": "checkout", "route": "/checkout/:orderId" },
  "extra": { "orderId": "A-1024" },
  "page": { "url": "https://shop.example.com/checkout", "route": "/checkout", "pageLoadId": "pl_8f13" },
  "uploadStatus": "pending"
}

Under the hood. Normalisation is where most of the work hides. A thrown string, a thrown number, a rejected Promise with a plain object, a Proxy whose getter raises, an AggregateError, a cause chain four levels deep: all of them have to become the same shape without ever throwing. The pipeline records thrownType so you can tell a real Error from an object someone rejected with, keeps up to three links of the cause chain, and reads at most five sub-errors from an AggregateError.

When the pipeline itself fails, it does not surface a new error to the user. It reports through an internal channel that fires once per stage, which is why a broken storage layer produces one warning instead of one warning per captured error.

If you have a value that must become a real Error before it reaches code that expects one, toError does that without stringifying anything hostile that came in with it.

Teaser. Capturing locally is cheap. Deciding when those records travel, and what happens when they cannot, is the part people get wrong next.

Where do browser errors go when the network is down?

Quick version. Nowhere, and that is the point. The default configuration stores everything in IndexedDB and makes no network request at all.

// main.ts
import { initTelemetry } from '@codewithrajat/rm-logvault';

initTelemetry({ appName: 'checkout', appVersion: '2.4.1' });

Two databases are created, rm-logvault-errors and rm-logvault-logs. Errors are capped at 500 rows kept for 7 days, logs at 2000 rows kept for 3 days. Nothing is sent anywhere, which is why this works with no backend, in an air-gapped build, and in a page with a locked-down CSP.

Real-world version. The turning point here is a design decision rather than a feature: nothing travels straight from the failure to the network. A queue that only lives in memory is not a queue, and the interesting moments are the ones where the page is going away.

The library flushes the write buffer on pagehide and on visibilitychange when the page becomes hidden, and it asks the uploader for a keepalive drain at the same time. That combination is what stops the last thirty seconds of a session from disappearing with the tab. It is also why a burst of logs can still be lost, since the buffer holds entries for up to a second before writing unless the batch size is reached first.

Storage is not guaranteed either. Private browsing modes, a full origin quota, and a corrupted database all happen, and the quota rules are set by the browser rather than by you, as covered in Storage for the web. When opening the database fails, storage moves to unavailable and the library keeps working with the console only, because losing diagnostics is much less bad than breaking the application.

// support-tools.ts
import { getTelemetryStatus } from '@codewithrajat/rm-logvault';

export function describeTelemetry(): string {
  const status = getTelemetryStatus();
  return `mode=${status.mode} storage=${status.storage} pending=${status.pending.errors}/${status.pending.logs} dropped=${status.droppedByRateLimit}`;
}

Under the hood. What sits on top of IndexedDB is an outbox. A write is a pending row. A sync run claims rows atomically, sends them, and marks them uploaded. Claiming matters for correctness, not performance: with two tabs open, two sync loops would otherwise upload the same record twice.

  captureError(error, ctx)
        |
        v
  normalize -> fingerprint -> already seen this Error object?
        |                          |
        |                    merge tags/extra onto the pending row
        v
  sanitize (redact + bound) -> IndexedDB row (pending, occurrenceCount)
        |
        v
  outbox: claim -> send -> mark uploaded | retry with backoff | mark failed
        |
        v
  HTML report (Ctrl+Shift+Alt+D) / json / jsonl / csv

Aggregation only ever touches pending rows. A row that is being uploaded is immutable, because rewriting a record after it has left the browser would make the server copy and the local copy disagree with each other and with their own fingerprint.

Teaser. None of that queue matters if the thing you are queueing is a customer's session token.

Redaction should happen before storage, not before upload

Quick version. Records are scrubbed on the way in. A key named token, email, password or authorization becomes [REDACTED] regardless of nesting, and the same happens inside free text.

// shared/telemetry.ts
import { captureError, initTelemetry } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  redaction: {
    extraSensitiveKeys: ['orderReference'],
    allowedQueryParams: ['page', 'locale'],
  },
});

captureError(new Error('card declined for user@example.com'), {
  extra: { accessToken: 'sk_live_51H8x', locale: 'en-GB' },
});

The stored record keeps the shape of your object and none of the secrets.

{
  "message": "card declined for [REDACTED]",
  "extra": { "accessToken": "[REDACTED]", "locale": "en-GB" }
}

Real-world version. Redacting on the server is the common mistake, and it is a mistake even when the server is yours. The data has already crossed the network, sat in a request log, and been handled by whatever sits in front of your API. Redacting in the browser before the write means the plaintext value never exists in any store you have to audit later.

The second common mistake is assuming the redactor only looks at keys. It also scans text, because phone=+14150000000 in a log message leaks the same value as { phone: '+14150000000' } would. The sensitive-key match is done against a lowercased key with separators stripped, so access_token, accessToken and ACCESS TOKEN all resolve to the same decision. Free text gets JWT-shaped strings, Bearer and Basic schemes, e-mail addresses, and token=... style pairs scrubbed, along with long opaque runs of 32 to 200 word characters, which is the shape of a leaked API key or a dashless UUID.

Query strings follow a different rule, because dropping every value would make a URL useless. Values survive only for parameter names on an allow-list, which by default is limit, offset, page, pageSize, size, sort, order, scope, lng, lang and type. A URL that is really an identifier gets replaced with a placeholder, and the fingerprint normalises those placeholders so /orders/8842 and /orders/9917 group as one bug.

Under the hood. The sanitizer is one instance reached through getDefaultSanitizer(), and it is wired before anything can capture, not after.

The stronger half of the privacy claim is what is never read at all, since there is no rule to get wrong when there is no read. Request and response bodies are never touched, including axios data and params. Cookies and document.cookie are never read. localStorage and sessionStorage are never read, because the vault is separate storage rather than a view over yours. Auth header values are never read, and only four named correlation headers are probed by name for a request id. Form values are never read. The only DOM element the library inspects is the shortcut's own event target, and only to decide whether to stop.

Bounding is as important as removing. Text is truncated before any pattern runs, so the regular expressions cannot be driven into a pathological backtrack. Values are walked to a depth of four, thirty keys, twenty array items, two thousand characters per string. Records are then reduced against a byte budget, 16 KB for errors and 4 KB for logs, so one enormous stack trace cannot block the write queue.

Which of your own query parameters would survive that allow-list? Open one real production URL from your application and look at what the key names are. If an identifier you did not expect is in the list, you just found a leak before an auditor did.

Teaser. A redacted record is still capable of drowning out the record that matters.

One failing poll should not bury every other error

Quick version. Identical failures aggregate into one row with an occurrenceCount, so a thousand repeats cost one row instead of a thousand.

// shared/telemetry.ts
import { captureError, flushTelemetry, initTelemetry } from '@codewithrajat/rm-logvault';
import { createMemoryRepository } from '@codewithrajat/rm-logvault/testing';

const repository = createMemoryRepository();
initTelemetry({ appName: 'checkout', repository, shortcut: false });

for (let attempt = 0; attempt < 5; attempt += 1) {
  captureError(new Error('orders refresh failed'), { tags: { poll: 'true' } });
}

await flushTelemetry();

const rows = repository.errors.all();
// rows.length === 1, rows[0].occurrenceCount === 5

Real-world version. Aggregation alone does not save you, and this is the bug I see most often in hand-rolled trackers. A global limit answers "how many errors may this page produce per minute". It does not answer "may this one error be produced again". A poll that refetches every five seconds and fails every time spends a tenth of a 120-per-minute budget on a failure that is already sitting in the report. Ten endpoints failing on that cadence exhaust the budget completely, and the new failure at minute three is the one that gets dropped, which is the exact opposite of what you want.

The fix is a second limiter, per fingerprint, consulted before the global one. Twelve repeats per minute by default. A repeat that is refused does not consume the global budget, so the budget goes to failures nobody has seen yet.

// shared/telemetry.ts
import { initTelemetry } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  errors: {
    maxEventsPerMinute: 120,
    maxRepeatsPerMinute: 12,
  },
});

A wrong version that still runs, and still looks reasonable, is deduplicating on the full stack including line numbers.

// shared/dedupe-error.ts
const seen = new Set<string>();

export function isDuplicate(error: Error): boolean {
  const key = `${error.message}:${error.stack ?? ''}`;
  if (seen.has(key)) return true;
  seen.add(key);
  return false;
}

Every deploy shifts line numbers, so every deploy creates a brand new group for a bug you already knew about. The set also grows without bound for the lifetime of the page. Dropping the stack and deduping on the message alone fails in the other direction, collapsing two unrelated failures that happen to share a message.

Have you ever lost an evening to a bug like one of these, where the tooling lied to you about what happened? Tell me what it was in the comments, because these are usually more interesting than the fix.

Under the hood. A fingerprint is built from the source, the normalised message, the top stack frames, and a path with identifiers replaced. It is hashed with cyrb53 rather than a cryptographic hash, because this value is a grouping key, not a security boundary, and the whole thing has to stay small and fast on the error path.

Two layers of dedupe run before any of that. Capturing the same Error object twice, once from a React boundary and once from window.onerror, does not create two records, because the object identity is remembered in a WeakMap. The second capture is not wasted either. It can merge severity, tags and extra onto the row that already exists, which is how a global handler's generic capture gets upgraded by the caller that actually knew where the failure came from.

message, stack, category, page and environment are deliberately not patchable. They describe the occurrence, and the first capture recorded them. Changing them afterwards would leave a stored record disagreeing with its own fingerprint.

The aggregate itself is mutable by design: a repeat widens lastSeen and increments occurrenceCount on the pending row. Repeat throttling is the same mechanism that keeps that update path from becoming a write storm.

Teaser. Everything so far assumes your code threw the error. A lot of real browser failures never reach a try block at all.

The errors a window.onerror handler cannot see

Quick version. Two of these are off by default, because capturing them changes behaviour for the host page. The third is on by default, and the snippet below sets all three so you can see where they live.

// shared/telemetry.ts
import { initTelemetry } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  errors: {
    captureResources: true,
    captureCsp: true,
    captureChunkErrors: true,
  },
});

Resource failures cover a <script> or <link> that failed to load. CSP violations arrive as securitypolicyviolation events. Chunk errors are dynamic import failures, and they are on by default because a stale chunk after a deploy is one of the most common production-only failures there is.

Real-world version. Each of these has a reason to be invisible by default.

A resource error does not bubble, so a listener on the document in the bubble phase never sees it, which is why the error event has to be caught during capture. A CSP violation is not an error at all, it is an event with a blockedURI and a directive. And a cross-origin script that throws produces the message Script error. with no stack and no details, which is a browser security decision rather than a bug in your tracker. The same rule applies to rejected promises from cross-origin scripts, which do not fire unhandledrejection at all, as documented on MDN.

Dynamic imports need one more thing, because the failure happens before any component or route handler is running. withChunkCapture wraps the loader and attaches the route pattern.

// orders.routes.ts
import { withChunkCapture } from '@codewithrajat/rm-logvault';

export const loadOrderDetail = withChunkCapture(
  '/orders/:id',
  () => import('./pages/order-detail'),
  { tags: { flow: 'order-detail' } },
);

export async function openOrder(orderId: string): Promise<void> {
  try {
    await loadOrderDetail();
  } catch {
    offerReload();
  }
}

The record from that failure carries source: 'chunk' and fatal severity, which is what makes "the deploy broke lazy loading" a query rather than a hunch.

Under the hood. Angular and React both funnel framework failures into the same ingestion point, which is the only reason the grouping works across boundaries. Angular's ErrorHandler is an injectable class, so the adapter subclasses it, reports, and then delegates to console.error so the framework's own diagnostics are unchanged. React 19 added root level error callbacks to createRoot, and the adapter exposes them as a spreadable bundle.

Workers are their own case, because a worker has its own global scope. The worker adapter listens for error and messageerror inside the worker and forwards the failure, which is the only way an uncaught exception in a worker stops being silent.

If your application knows something the library cannot, a context builder is the hook for it. Registration is by name, a second registration under the same name replaces the first, and a throwing builder falls through to the next one instead of swallowing the capture.

// shared/telemetry.ts
import { registerErrorContextBuilder } from '@codewithrajat/rm-logvault';

const unregister = registerErrorContextBuilder({
  name: 'feature-flag-failures',
  canHandle: (error) => error instanceof Error && error.message.includes('flag'),
  build: (error) => ({
    tags: { subsystem: 'feature-flags' },
    extra: { flagMessage: error instanceof Error ? error.message : 'unknown' },
  }),
});

// Later, on teardown. Safe to call twice.
unregister();

Teaser. Two of those boundaries are in frameworks you are already using, and wiring them the wrong way is how people end up with a capture from a component that React never actually failed on.

Wiring React and Angular error boundaries without replacing them

Quick version. In React, an error boundary that reports is a class component, because that is still how boundaries work.

// app-root.tsx
import { TelemetryErrorBoundary } from '@codewithrajat/rm-logvault/react';
import { App } from './app';

export function AppRoot() {
  return (
    <TelemetryErrorBoundary
      fallback={(error, reset) => (
        <div>
          <p role="alert">Something went wrong: {error.message}</p>
          <button type="button" onClick={reset}>
            Try again
          </button>
        </div>
      )}
    >
      <App />
    </TelemetryErrorBoundary>
  );
}

Real-world version. A boundary catches render failures in the tree below it. It does not catch a failure in an event handler, and React 19 added root level callbacks for the ones that never reach a boundary at all. Use both, and do not fight the framework: spread the root handlers into createRoot rather than rewriting the boundary.

// main.tsx
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import { reactRootErrorHandlers } from '@codewithrajat/rm-logvault/react';
import { AppRoot } from './app-root';

const container = document.getElementById('root');
if (container === null) throw new Error('missing #root element');

createRoot(container, reactRootErrorHandlers({ tags: { shell: 'checkout' } })).render(
  <StrictMode>
    <AppRoot />
  </StrictMode>,
);

For a failure you handle yourself, a hook keeps the context consistent and gives you a function that is safe to call from a handler or an effect.

// checkout-panel.tsx
import { useState } from 'react';
import { useErrorCapture } from '@codewithrajat/rm-logvault/react';
import { payForOrder } from './pay-for-order';

export function CheckoutPanel({ orderId }: { readonly orderId: string }) {
  const capture = useErrorCapture({ tags: { flow: 'checkout' } });
  const [status, setStatus] = useState<'idle' | 'paying' | 'failed'>('idle');

  async function pay(): Promise<void> {
    setStatus('paying');
    try {
      await payForOrder(orderId);
      setStatus('idle');
    } catch (error) {
      setStatus('failed');
      capture(error, { extra: { orderId } });
    }
  }

  return (
    <section>
      {status === 'failed' ? <p role="alert">Payment failed. Try again.</p> : null}
      <button type="button" onClick={() => void pay()}>
        Pay
      </button>
    </section>
  );
}

In Angular the integration is a provider, and the default handler stays in place underneath it.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideTelemetryErrorHandler } from '@codewithrajat/rm-logvault/angular';
import { captureError, initTelemetry } from '@codewithrajat/rm-logvault';
import { AppComponent } from './app.component';

initTelemetry({ appName: 'checkout', appVersion: '2.4.1' });

bootstrapApplication(AppComponent, {
  providers: [provideTelemetryErrorHandler({ tags: { shell: 'checkout' } })],
}).catch((error: unknown) => {
  // Bootstrap failures happen before any handler exists, so they are captured explicitly.
  captureError(error, { source: 'manual', severity: 'fatal' });
});

The provider uses a factory rather than a class provider on purpose, so it does not require emitDecoratorMetadata in your tsconfig. A component that handles a failure itself looks like this.

// order-detail.component.ts
import { Component, inject, input, signal } from '@angular/core';
import { captureError } from '@codewithrajat/rm-logvault';
import { OrdersApi } from './orders-api';
import type { OrderLine } from './order-line';

@Component({
  selector: 'app-order-detail',
  template: `
    <h2>Order {{ orderId() }}</h2>

    @if (status() === 'error') {
      <p role="alert">We could not load this order.</p>
    }

    @for (line of lines(); track line.sku) {
      <p>{{ line.sku }} x {{ line.quantity }}</p>
    }

    <button type="button" (click)="load()">Retry</button>
  `,
})
export class OrderDetailComponent {
  readonly orderId = input.required<string>();
  readonly lines = signal<readonly OrderLine[]>([]);
  readonly status = signal<'idle' | 'loading' | 'error'>('idle');

  private readonly api = inject(OrdersApi);

  async load(): Promise<void> {
    this.status.set('loading');
    try {
      this.lines.set(await this.api.load(this.orderId()));
      this.status.set('idle');
    } catch (error) {
      this.status.set('error');
      captureError(error, {
        tags: { route: '/orders/:id', flow: 'order-detail' },
        extra: { orderId: this.orderId() },
      });
    }
  }
}

Under the hood. The reason both frameworks funnel into one place is deduplication. A failure that reaches a boundary and also reaches the root is one failure, and object identity is what makes the second capture merge into the first rather than double up. That is also why both adapters swallow their own exceptions: a reporting call that throws inside componentDidCatch turns a handled render failure into an unhandled one.

The Angular adapter only reports and delegates. It never replaces the default console output, so an Angular developer's usual error messages stay exactly where they were, and the adapter works whether the application uses bootstrapApplication or an older bootstrap path.

Teaser. At this point the vault has everything. Somebody still has to get it out and read it.

From a support ticket to one self-contained HTML report

Quick version. Press Ctrl+Shift+Alt+D in the page, and a single HTML file downloads. The default shortcut is registered at startup, so there is nothing to wire.

// support-tools.ts
import { exportDiagnosticsReport, logger } from '@codewithrajat/rm-logvault';

export async function downloadReport(): Promise<void> {
  const result = await exportDiagnosticsReport({ format: 'html' });
  logger.info(`report ok=${String(result.ok)} bytes=${String(result.bytes)}`);
}

Real-world version. The shortcut gets you a file. It does not get you the right file, and it does not get you the record the support agent needs to read.

Four formats exist for four different readers. html is the one a support engineer opens, and it embeds the raw payload so the file is complete on its own. json is one document for a script. jsonl is one object per line, which is the format that survives grep and jq. csv is a flat table you can open in a spreadsheet when someone asks for a summary by route.

Two details are worth knowing before you hand the shortcut to everyone. The default gate allows it for anyone in the page, so gate it yourself with allow, and use redactAgain when the records were written before your redaction configuration changed.

// shared/telemetry.ts
import { initTelemetry, logger } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  shortcut: {
    key: 'd',
    filenamePrefix: 'checkout-diagnostics',
    allow: () => isInternalUser(),
    onExported: (ok) => {
      logger.info(`[Diagnostics] export finished ok=${String(ok)}`);
    },
  },
});

The library exposes the same shortcut as obscurity, not access control. Anyone who knows the key combination can press it, which is why the report is scrubbed twice rather than trusting the records to be safe.

Under the hood. A report is an HTML file that a user e-mails to somebody else, so it has to be unable to execute anything. Three rules make that true: record data is escaped rather than interpolated into markup, the viewer never touches innerHTML, and the file fetches nothing. The payload is embedded as escaped JSON so the page can render a table without a network request.

Export is also bounded. Records are marshalled in slices of 500 with a yield to the event loop between slices, and an export already in flight rejects a second one, because a double key press is a double click and not a request for two files.

Teaser. Local-only is a complete product on its own. The moment you want a dashboard, you add an endpoint, and that is a decision with its own failure modes.

Sending records to your backend, on purpose

Quick version. One URL is enough if your collector accepts both kinds.

// shared/telemetry.ts
import { initTelemetry } from '@codewithrajat/rm-logvault';

initTelemetry({
  appName: 'checkout',
  env: 'VITE_',
  url: '/telemetry',
  headers: () => ({ Authorization: `Bearer ${getAccessToken()}` }),
  level: 'info',
});

Supplying a URL turns uploads on and moves the mode to remote. Records are still written to IndexedDB first, so an endpoint that is down costs latency in your dashboard and nothing at all in your data.

Real-world version. Uploads introduce three questions that local-only never asked.

What happens when the request never lands. Network failures, timeouts, 408, 429 and every 5xx are retried with backoff, and a Retry-After header is honoured when the server sends one. What happens when the request lands and is refused. 400, 401, 403, 404, 405, 410, 413, 415 and 422 are terminal, and the records are marked failed so they stop consuming retry budget forever. What happens after the user re-authenticates and you want those records anyway. retryFailedTelemetry() moves failed records back to pending, which is the difference between losing everything captured during a token expiry and getting it back.

// session-recovery.ts
import { retryFailedTelemetry } from '@codewithrajat/rm-logvault';

export async function recoverSession(): Promise<number> {
  await refreshSession();
  return retryFailedTelemetry();
}

Credentials default to same-origin, never include, so a configured endpoint cannot quietly start carrying cookies to a third party. For a same-origin collector that is exactly right. For a cross-origin one, pass a header provider and let your own auth code decide what goes out.

Under the hood. The wire format is one envelope per batch, batched at 50 records and flushed every 30 seconds.

{
  "schemaVersion": 1,
  "kind": "errors",
  "sentAt": 1767225600000,
  "app": { "appName": "checkout", "appVersion": "2.4.1", "buildId": "9c1a2f4", "environment": "production" },
  "records": [{ "id": "err_01j8", "fingerprint": "3f2c81a9c4b7d0e5", "occurrenceCount": 3, "message": "Payment provider returned 502" }]
}

Your server has one obligation: answer 2xx for accepted records, and use a status your client can interpret correctly when you do not accept them. A 429 with Retry-After is respected rather than fought. A 401 is terminal on purpose, because retrying an unauthenticated request is a way to hammer your own gateway while the token is broken. The full envelope, the status table and the server obligations are in the REST contract.

If the shipped fetch transport does not fit, rest.transport accepts your own implementation with a send method, and the testing subpath ships a scriptable one so tests can exercise every branch of the outbox without a server.

Teaser. Everything above is code you can reason about, which means all of it is code you can break with a bad test setup.

Testing a browser error tracker without a browser

Quick version. The library ships test doubles on a separate subpath, and that subpath installs nothing, starts nothing and opens no database.

// telemetry-upload.test.ts
import { afterEach, expect, it } from 'vitest';
import {
  destroyTelemetry,
  initTelemetry,
  logger,
  syncTelemetry,
} from '@codewithrajat/rm-logvault';
import { createFakeTransport, createMemoryRepository } from '@codewithrajat/rm-logvault/testing';

afterEach(() => {
  destroyTelemetry();
});

it('retries a 503 instead of dropping the batch', async () => {
  const repository = createMemoryRepository();
  const transport = createFakeTransport({ status: 503, retryAfterMs: 30_000 });

  initTelemetry({
    appName: 'orders-test',
    repository,
    shortcut: false,
    rest: {
      errorsUrl: '/telemetry/errors',
      logsUrl: '/telemetry/logs',
      transport,
    },
  });

  logger.error('[Orders] load failed');
  const result = await syncTelemetry();

  expect(transport.sendCount).toBe(1);
  expect(transport.lastBody()?.records).toHaveLength(1);
  expect(result.logs.uploaded).toBe(0);
  expect(result.logs.retried).toBe(1);
});

Run it with npx vitest run. The in-memory repository also fails on demand through failWith and quotaAt, which is how you test the degradation path instead of hoping it works.

Real-world version. The test people actually need is the one that asserts a component failure produced a record with the right context. In React, Testing Library plus Vitest does it with a real boundary.

// telemetry-error-boundary.test.tsx
import { render, screen } from '@testing-library/react';
import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
import { destroyTelemetry, flushTelemetry, initTelemetry } from '@codewithrajat/rm-logvault';
import { TelemetryErrorBoundary } from '@codewithrajat/rm-logvault/react';
import { createMemoryRepository } from '@codewithrajat/rm-logvault/testing';

function BrokenWidget(): never {
  throw new Error('orders widget exploded');
}

describe('TelemetryErrorBoundary', () => {
  beforeEach(() => {
    vi.spyOn(console, 'error').mockImplementation(() => undefined);
  });

  afterEach(() => {
    destroyTelemetry();
    vi.restoreAllMocks();
  });

  it('renders the fallback and stores exactly one record', async () => {
    const repository = createMemoryRepository();
    initTelemetry({ appName: 'orders-test', repository, shortcut: false });

    render(
      <TelemetryErrorBoundary fallback={<p>Widget unavailable</p>}>
        <BrokenWidget />
      </TelemetryErrorBoundary>,
    );

    expect(screen.getByText('Widget unavailable')).toBeTruthy();

    await flushTelemetry();

    const [record] = repository.errors.all();
    expect(record?.source).toBe('react');
    expect(record?.message).toContain('orders widget exploded');
    expect(record?.componentStack).toBeTruthy();
  });
});

In Angular, the handler is an injectable, so the test is a TestBed provider test and it runs with ng test.

// checkout-error-handler.spec.ts
import { TestBed } from '@angular/core/testing';
import { ErrorHandler } from '@angular/core';
import { provideTelemetryErrorHandler } from '@codewithrajat/rm-logvault/angular';
import { destroyTelemetry, flushTelemetry, initTelemetry } from '@codewithrajat/rm-logvault';
import { createMemoryRepository } from '@codewithrajat/rm-logvault/testing';

describe('TelemetryErrorHandler', () => {
  it('stores an error Angular reported, with its context', async () => {
    const repository = createMemoryRepository();
    initTelemetry({ appName: 'checkout-test', repository, shortcut: false });

    TestBed.configureTestingModule({
      providers: [provideTelemetryErrorHandler({ tags: { shell: 'checkout' } })],
    });

    TestBed.inject(ErrorHandler).handleError(new Error('payment failed'));
    await flushTelemetry();

    const [record] = repository.errors.all();
    expect(record?.source).toBe('angular');
    expect(record?.message).toBe('payment failed');
    expect(record?.tags?.shell).toBe('checkout');

    destroyTelemetry();
  });
});

Under the hood. Both tests assert the same three things, and they are the three that break in production: the record exists, the message survived normalisation, and the context that identifies where it came from is attached.

The last double is for code that only calls capture, not for the pipeline. A recording captureError double replaces the real one in a unit test of a service, so a service test does not need the library initialised at all.

// checkout-service.test.ts
import { expect, it, vi } from 'vitest';
import { createCaptureErrorMock } from '@codewithrajat/rm-logvault/testing';

const telemetry = createCaptureErrorMock();

vi.mock('./telemetry', () => ({ captureError: telemetry.captureError }));

it('reports a failed load with the route', async () => {
  const { loadOrders } = await import('./orders-service');
  await loadOrders('42');

  expect(telemetry.messages()).toEqual(['orders 42 not found']);
  expect(telemetry.last()?.ctx?.source).toBe('router');
  telemetry.reset();
});

The reason to reach for a recording double instead of a bare vi.fn() is the assertion itself. telemetry.last()?.ctx?.source reads like the thing you are checking, while mock.calls[0][1].source reads like an implementation detail of the mock.

Teaser. Here is the whole thing in one file, plus the answer to the question I asked at the start.

The full integration, and the answer to the question from the top

This is the complete version of the running example, in one place. Every option here is optional, and the ordering comments matter more than the values.

// shared/telemetry.ts
import {
  captureError,
  destroyTelemetry,
  getTelemetryStatus,
  initTelemetry,
  logger,
} from '@codewithrajat/rm-logvault';
import type { TelemetryHandle } from '@codewithrajat/rm-logvault';

let handle: TelemetryHandle | undefined;

export function startTelemetry(): TelemetryHandle {
  if (handle !== undefined) return handle;

  handle = initTelemetry({
    // Identity. Everything on a record that says which build produced it.
    appName: 'checkout',
    appVersion: '2.4.1',
    buildId: '9c1a2f4',
    environment: 'production',

    // Local by default. Adding a URL is the only thing that turns uploads on.
    url: '/telemetry',
    headers: () => ({ Authorization: `Bearer ${getAccessToken()}` }),

    errors: {
      maxRecords: 1000,
      retentionDays: 14,
      maxEventsPerMinute: 120,
      maxRepeatsPerMinute: 12,
      captureResources: true,
      captureCsp: true,
      captureChunkErrors: true,
      beforeCapture: (record) => (record.message.includes('ResizeObserver loop') ? null : record),
    },

    logs: {
      level: 'info',
      consoleLevel: 'warn',
      maxRecords: 5000,
      retentionDays: 7,
    },

    redaction: {
      allowedQueryParams: ['page', 'locale'],
    },

    rest: {
      intervalMs: 30_000,
      batchSize: 50,
      onTerminalFailure: (status) => {
        logger.warn(`[Telemetry] batch rejected with status ${String(status)}`);
      },
    },

    shortcut: {
      filenamePrefix: 'checkout-diagnostics',
      allow: () => isInternalUser(),
    },

    // Consent is evaluated before every capture, persist and upload.
    consent: () => hasAnalyticsConsent(),

    onInternalError: (stage, error) => {
      logger.warn(`[Telemetry] internal failure in ${stage}`, error);
    },
  });

  return handle;
}

export function reportFailure(error: unknown, context: Record<string, string>): void {
  captureError(error, {
    tags: context,
    severity: 'error',
  });
}

export function stopTelemetry(): void {
  destroyTelemetry();
  handle = undefined;
}

export function telemetrySummary(): string {
  const status = getTelemetryStatus();
  return `${status.mode} ${status.storage} pending=${status.pending.errors}/${status.pending.logs}`;
}

Now the question from the top: where does an error go when it is thrown before your tracker starts, and the tab closes a second later?

Two mechanisms cover it, and they are independent. Before initTelemetry runs, a failure is normalised immediately and held in a bounded buffer of 50 entries. It is stored in its safe form rather than as a live reference to a caller's object graph, so nothing about the application is retained by accident. When initialisation completes, that buffer is replayed into the real tracker, which is why an exception thrown during module evaluation still appears in the report with the application metadata attached.

The tab closing is the other half, and it is the outbox doing the work. Records are written to IndexedDB as pending rows, pagehide and the hidden visibilitychange state both trigger a flush, and the uploader gets a keepalive drain at that moment. If the network is gone, the rows are still there when the user comes back, and the next sync pass picks them up.

The result of all of this is a support conversation that goes differently. Someone opens the report, sees a single row with a large occurrence count and a route tag, and the ninety seconds of guessing are gone.

The one thing most teams get wrong. They audit the reporter for correctness and never audit it for failure. Every code path in this article exists because the pipeline runs while the application is already broken: storage is allowed to be missing, the network is allowed to be gone, and the value being reported is allowed to be hostile. A reporter that only works when everything else works is not monitoring, it is a happy-path logger with a dashboard attached.

When this is the wrong tool. If you need session replay, stack traces symbolicated from uploaded source maps, alerting with on-call routing, or a hosted dashboard that somebody else maintains, a hosted SDK will get you there faster and this library will not pretend otherwise. It captures and stores browser-side failures and hands you a report. Turning those records into a page at 3am is a pipeline you own. That list of non-goals is written down in the README rather than left for you to discover.

Bonus tips. One per level.

Beginner: pass extra and tags explicitly instead of dumping an object into a payload. The sanitizer will scrub the values, but it cannot invent the route or the order id you never told it about.

Intermediate: set logs.consoleLevel at build time, 'off' in production and 'debug' in development. The console level and the persist level are separate, so silencing the console does not silence the vault, and initialising telemetry does not change your console output on its own.

Advanced: use errors.beforeCapture for noise you have genuinely decided to ignore, and use a registered context builder for classification your application already knows. Neither should be used to hide an error category you have not investigated yet.

Recap.

The reporter runs inside the failure path, so the first requirement is that it cannot throw, and hostile values are the normal case rather than the edge case.
Local-first storage with an outbox on top is what makes a flush at pagehide and a retry after a network outage the same mechanism.
Redaction belongs before the write, not before the upload, and the strongest version of that claim is reading less in the first place.
Aggregation stops the row count exploding, but a per-fingerprint limiter is what stops one repeating failure from eating the budget that new failures need.
A report that a support engineer can open, read and forward is the actual deliverable. Everything else is plumbing that makes it possible.

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 provideBrowserGlobalErrorListeners: The Missing Piece in Your Zoneless Error Strategy

Rajat — Tue, 06 Oct 2026 13:30:00 +0000

How one small provider can save your production app from silent, untracked errors — and why most Angular teams miss it.

Before you scroll: If you're moving your Angular app to zoneless change detection and you haven't audited your error handling strategy yet, this article is for you. Stick around — your monitoring tools might be lying to you right now.

Introduction

Have you ever deployed what felt like a rock-solid Angular app, only to get a support ticket about an error that never showed up in your monitoring dashboard? You open Sentry, Datadog, or your custom logger — and nothing. No trace. No breadcrumb. The error happened, your users saw it, but your error handler was completely silent.

If you recently migrated to zoneless Angular (or you're planning to), there's a very good chance this is already happening to you.

This article dives deep into provideBrowserGlobalErrorListeners — a relatively new Angular API that plugs a critical gap in global error handling for zoneless applications. By the time you finish reading, you will understand:

Why zone.js was quietly doing more than just change detection
What breaks in your error pipeline when you remove it
How provideBrowserGlobalErrorListeners restores that pipeline the right way
How to build a production-grade custom error handler from scratch
How to integrate it with Sentry, Datadog, or any monitoring tool
How to write unit tests that validate your error handling strategy

Let's get into it.

Got a story about a silent error in production that cost you a weekend? Drop it in the comments — I read every one of them.

What Is `provideBrowserGlobalErrorListeners`?

provideBrowserGlobalErrorListeners is a provider function introduced in Angular's core package. Its job is straightforward: it registers listeners on the browser's global window.onerror and window.unhandledrejection events, and routes those errors into Angular's ErrorHandler.

// Simplified mental model of what this provider does internally
window.addEventListener('error', (event) => {
  errorHandler.handleError(event.error);
});

window.addEventListener('unhandledrejection', (event) => {
  errorHandler.handleError(event.reason);
});

Simple enough. But why did Angular need to ship this as an explicit API? To answer that, we need to talk about the deal you were unknowingly making with zone.js.

The Hidden Contract with zone.js

When Angular apps run with zone.js (which was the default for years), your ErrorHandler worked like magic. Any async error — whether inside a Promise, a setTimeout, an RxJS observable chain, or a plain event handler — would reliably land in your ErrorHandler.handleError() method. No extra configuration needed.

That was not Angular being clever. That was zone.js doing the heavy lifting.

Here's what zone.js was actually doing under the hood:

Monkey-patching async APIs — It overwrote browser-native functions like Promise, setTimeout, setInterval, addEventListener, and others to wrap them in an execution "zone."
Tracking async execution — Every async callback ran inside a zone context that could observe its lifecycle.
Intercepting unhandled errors — When an error escaped a zone without being caught, zone.js intercepted it before it reached the browser's global scope.
Forwarding to NgZone — Angular's NgZone listened for these zone-level errors and forwarded them to ErrorHandler.

So your ErrorHandler was receiving a curated, intercepted stream of errors — not raw browser events. It never had to care about window.onerror or unhandledrejection because zone.js was translating everything into a format Angular understood.

When you remove zone.js, that translation layer disappears entirely.

What Breaks Without zone.js

When you switch to provideZonelessChangeDetection() and remove zone.js, here is exactly what changes in the error pipeline:

WITH zone.js:
Async Error
  --> zone.js intercepts
    --> NgZone catches
      --> ErrorHandler.handleError() [YOUR CODE RUNS]

WITHOUT zone.js:
Async Error
  --> Browser fires 'unhandledrejection' or 'error' event
    --> ... silence ...
      --> Console warning (if dev mode)
        --> Your ErrorHandler never sees it

This means your custom ErrorHandler — the one that logs to Sentry, sends alerts to Slack, or shows a friendly toast message — will only receive synchronous errors happening within Angular's own rendering pipeline. Everything else disappears.

Template binding errors: still caught.
Failed HTTP calls not wrapped in a catchError: gone.
Unhandled promise rejections in services: gone.
Third-party library async errors: gone.

This is not a bug in Angular. It is the explicit trade-off of going zoneless. And provideBrowserGlobalErrorListeners is the explicit way to opt back into catching those global errors.

Setting Up provideBrowserGlobalErrorListeners

Let's walk through a complete, production-ready setup.

Step 1: Bootstrap with the provider

// main.ts
import {
  bootstrapApplication,
  provideBrowserGlobalErrorListeners,
} from '@angular/core';
import { AppComponent } from './app/app.component';
import { appConfig } from './app/app.config';

bootstrapApplication(AppComponent, appConfig).catch((err) =>
  console.error(err)
);

// app.config.ts
import {
  ApplicationConfig,
  provideZonelessChangeDetection,
  provideBrowserGlobalErrorListeners,
  ErrorHandler,
} from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { GlobalErrorHandler } from './core/error-handler/global-error-handler.service';

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(),
    provideBrowserGlobalErrorListeners(), // <-- The key addition
    provideRouter(routes),
    {
      provide: ErrorHandler,
      useClass: GlobalErrorHandler,
    },
  ],
};

Notice: provideBrowserGlobalErrorListeners() does not replace your ErrorHandler. It is a bridge that feeds global browser errors into whatever ErrorHandler is registered. These two work together.

Step 2: Build a production-grade custom ErrorHandler

// core/error-handler/global-error-handler.service.ts
import { ErrorHandler, inject, Injectable, NgZone } from '@angular/core';
import { HttpErrorResponse } from '@angular/common/http';
import { ErrorLoggingService } from './error-logging.service';
import { NotificationService } from '../notifications/notification.service';

@Injectable()
export class GlobalErrorHandler implements ErrorHandler {
  private readonly loggingService = inject(ErrorLoggingService);
  private readonly notificationService = inject(NotificationService);

  handleError(error: unknown): void {
    // Separate client-side errors from HTTP errors
    if (error instanceof HttpErrorResponse) {
      this.handleHttpError(error);
    } else if (error instanceof Error) {
      this.handleClientError(error);
    } else {
      this.handleUnknownError(error);
    }
  }

  private handleHttpError(error: HttpErrorResponse): void {
    const message = this.extractHttpMessage(error);
    console.error('[HTTP Error]', error.status, message);

    this.loggingService.logError({
      type: 'http',
      status: error.status,
      message,
      url: error.url ?? 'unknown',
    });

    if (error.status === 0) {
      this.notificationService.showError('Network error. Please check your connection.');
    } else if (error.status >= 500) {
      this.notificationService.showError('Something went wrong on our end. We are working on it.');
    }
  }

  private handleClientError(error: Error): void {
    console.error('[Client Error]', error.message, error.stack);

    this.loggingService.logError({
      type: 'client',
      message: error.message,
      stack: error.stack,
    });

    // Show a generic user-facing message — never expose raw stack traces
    this.notificationService.showError('An unexpected error occurred. Please try again.');
  }

  private handleUnknownError(error: unknown): void {
    console.error('[Unknown Error]', error);

    this.loggingService.logError({
      type: 'unknown',
      message: String(error),
    });
  }

  private extractHttpMessage(error: HttpErrorResponse): string {
    if (error.error instanceof ErrorEvent) {
      return error.error.message;
    }
    return error.message;
  }
}

Step 3: Wire in your logging service

// core/error-handler/error-logging.service.ts
import { Injectable } from '@angular/core';
import { environment } from '../../environments/environment';

interface ErrorPayload {
  type: 'http' | 'client' | 'unknown';
  message: string;
  status?: number;
  url?: string;
  stack?: string;
}

@Injectable({ providedIn: 'root' })
export class ErrorLoggingService {

  logError(payload: ErrorPayload): void {
    if (!environment.production) {
      // In development, just log to console with structured data
      console.table(payload);
      return;
    }

    // In production, send to your monitoring tool
    this.sendToSentry(payload);
    this.sendToDatadog(payload);
  }

  private sendToSentry(payload: ErrorPayload): void {
    // Sentry integration example
    // Sentry.captureException(new Error(payload.message), {
    //   tags: { errorType: payload.type },
    //   extra: { status: payload.status, url: payload.url },
    // });
  }

  private sendToDatadog(payload: ErrorPayload): void {
    // Datadog RUM integration example
    // datadogRum.addError(new Error(payload.message), {
    //   errorType: payload.type,
    //   httpStatus: payload.status,
    // });
  }
}

Integrating with Sentry in a Real Application

Here's a practical, self-contained Sentry integration:

// core/error-handler/sentry-error-handler.service.ts
import * as Sentry from '@sentry/angular';
import { ErrorHandler, Injectable, inject } from '@angular/core';
import { HttpErrorResponse } from '@angular/common/http';

@Injectable()
export class SentryErrorHandler implements ErrorHandler {

  handleError(error: unknown): void {
    // Do not report 4xx HTTP errors to Sentry — those are user-facing issues
    if (error instanceof HttpErrorResponse && error.status < 500 && error.status >= 400) {
      console.warn('[Expected HTTP Error]', error.status, error.url);
      return;
    }

    const extractedError = this.extractError(error);
    Sentry.captureException(extractedError, {
      tags: {
        angular_error: 'true',
        error_type: error instanceof HttpErrorResponse ? 'http' : 'client',
      },
    });

    // Always re-throw or log locally in development
    if (!environment.production) {
      throw extractedError;
    }
  }

  private extractError(error: unknown): Error {
    if (error instanceof Error) return error;
    if (error instanceof HttpErrorResponse) {
      return new Error(`HTTP ${error.status}: ${error.message}`);
    }
    return new Error(String(error));
  }
}

And in your config:

// app.config.ts
import * as Sentry from '@sentry/angular';
import {
  ApplicationConfig,
  ErrorHandler,
  provideZonelessChangeDetection,
  provideBrowserGlobalErrorListeners,
} from '@angular/core';

Sentry.init({
  dsn: 'YOUR_SENTRY_DSN',
  environment: environment.name,
  tracesSampleRate: 0.2,
});

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(),
    provideBrowserGlobalErrorListeners(),
    {
      provide: ErrorHandler,
      useClass: SentryErrorHandler,
    },
  ],
};

Behavior Comparison: zone.js vs. Zoneless + Provider

Error Source	zone.js	Zoneless (no provider)	Zoneless + provider
Template binding error	Caught	Caught	Caught
Synchronous service error	Caught	Caught	Caught
Unhandled Promise rejection	Caught	NOT caught	Caught
setTimeout error	Caught	NOT caught	Caught
HTTP error (no catchError)	Caught	Caught via HttpClient	Caught via HttpClient
Third-party async error	Caught	NOT caught	Caught

The provider restores everything in the third column that says "NOT caught."

Conceptual Flow Diagram

Browser Runtime
│
├── Synchronous Error (template / DI)
│     └── Angular catches directly
│           └── ErrorHandler.handleError()
│
├── Unhandled Promise rejection
│     └── Browser fires: window.unhandledrejection
│           └── [provideBrowserGlobalErrorListeners intercepts]
│                 └── ErrorHandler.handleError()
│
└── Script / runtime error
      └── Browser fires: window.onerror
            └── [provideBrowserGlobalErrorListeners intercepts]
                  └── ErrorHandler.handleError()

Pitfalls and Edge Cases

1. Duplicate error reporting

If you manually add window.addEventListener('unhandledrejection', ...) anywhere in your codebase AND use provideBrowserGlobalErrorListeners, you will handle the same error twice. Audit your codebase before adding the provider.

// DANGER: This will double-report errors
window.addEventListener('unhandledrejection', (event) => {
  myLogger.log(event.reason); // fires once
});

// And then provideBrowserGlobalErrorListeners also fires
// --> ErrorHandler.handleError() also fires

Pick one approach. Let provideBrowserGlobalErrorListeners be the single point of entry.

2. SSR considerations

provideBrowserGlobalErrorListeners hooks into browser-specific globals (window.onerror, window.addEventListener). These do not exist in a Node.js environment. If you are using Angular Universal or @angular/ssr, make sure this provider is only included in your browser config, not your server config.

// app.config.browser.ts (browser-specific config)
import { mergeApplicationConfig } from '@angular/core';
import { provideBrowserGlobalErrorListeners } from '@angular/core';
import { appConfig } from './app.config';

export const appBrowserConfig = mergeApplicationConfig(appConfig, {
  providers: [
    provideBrowserGlobalErrorListeners(), // safe here — browser only
  ],
});

// app.config.server.ts (server config — do NOT include the provider here)
import { mergeApplicationConfig } from '@angular/core';
import { provideServerRendering } from '@angular/platform-server';
import { appConfig } from './app.config';

export const appServerConfig = mergeApplicationConfig(appConfig, {
  providers: [provideServerRendering()],
});

3. Swallowing errors in production

A common mistake is catching everything in handleError without re-throwing during development. This makes debugging nearly impossible.

handleError(error: unknown): void {
  this.loggingService.logError(error);

  // Always surface errors in development
  if (!environment.production) {
    throw error; // Re-throw so DevTools shows a real stack trace
  }
}

4. Angular v20+ includes it by default for new projects

From Angular v20 onwards, the CLI includes provideBrowserGlobalErrorListeners automatically in new project scaffolds. If you are upgrading an existing project, you need to add it manually — the migration guide does not always flag this.

Writing Unit Tests for Your Error Handler

Testing error handling is one of those things teams consistently skip. Here is a solid testing setup.

Testing the custom ErrorHandler

// global-error-handler.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { ErrorHandler } from '@angular/core';
import { GlobalErrorHandler } from './global-error-handler.service';
import { ErrorLoggingService } from './error-logging.service';
import { NotificationService } from '../notifications/notification.service';
import { HttpErrorResponse } from '@angular/common/http';

describe('GlobalErrorHandler', () => {
  let handler: GlobalErrorHandler;
  let loggingSpy: jasmine.SpyObj<ErrorLoggingService>;
  let notificationSpy: jasmine.SpyObj<NotificationService>;

  beforeEach(() => {
    loggingSpy = jasmine.createSpyObj('ErrorLoggingService', ['logError']);
    notificationSpy = jasmine.createSpyObj('NotificationService', ['showError']);

    TestBed.configureTestingModule({
      providers: [
        { provide: ErrorHandler, useClass: GlobalErrorHandler },
        { provide: ErrorLoggingService, useValue: loggingSpy },
        { provide: NotificationService, useValue: notificationSpy },
      ],
    });

    handler = TestBed.inject(ErrorHandler) as GlobalErrorHandler;
  });

  it('should log client-side errors and show notification', () => {
    const error = new Error('Something went wrong');
    handler.handleError(error);

    expect(loggingSpy.logError).toHaveBeenCalledWith(
      jasmine.objectContaining({ type: 'client', message: 'Something went wrong' })
    );
    expect(notificationSpy.showError).toHaveBeenCalled();
  });

  it('should handle HTTP 500 errors and show notification', () => {
    const httpError = new HttpErrorResponse({ status: 500, statusText: 'Internal Server Error' });
    handler.handleError(httpError);

    expect(loggingSpy.logError).toHaveBeenCalledWith(
      jasmine.objectContaining({ type: 'http', status: 500 })
    );
    expect(notificationSpy.showError).toHaveBeenCalled();
  });

  it('should handle HTTP 404 gracefully', () => {
    const httpError = new HttpErrorResponse({ status: 404, url: '/api/user' });
    handler.handleError(httpError);

    expect(loggingSpy.logError).toHaveBeenCalled();
  });

  it('should handle unknown error types', () => {
    handler.handleError('just a string error');

    expect(loggingSpy.logError).toHaveBeenCalledWith(
      jasmine.objectContaining({ type: 'unknown' })
    );
  });
});

Testing that unhandledrejection is caught end-to-end

// integration: verify global listener is active
it('should catch unhandled promise rejections via global listener', async () => {
  const handleErrorSpy = spyOn(TestBed.inject(ErrorHandler), 'handleError');

  // Simulate an unhandled rejection
  const rejectionEvent = new PromiseRejectionEvent('unhandledrejection', {
    promise: Promise.reject(new Error('async failure')),
    reason: new Error('async failure'),
  });

  window.dispatchEvent(rejectionEvent);

  // Allow microtask queue to flush
  await Promise.resolve();

  expect(handleErrorSpy).toHaveBeenCalledWith(
    jasmine.objectContaining({ message: 'async failure' })
  );
});

How This Fits into the Modern Angular Architecture

Angular's trajectory is clear: signals-based reactivity, standalone component architecture, and a zoneless future. provideBrowserGlobalErrorListeners is part of that story.

In the zoneless world, Angular trades implicit magic for explicit control. You get:

Smaller bundles (no zone.js overhead)
More predictable change detection
Better performance in CPU-intensive scenarios

But explicit control means you have to own things that used to be automatic. Error forwarding is one of them. provideBrowserGlobalErrorListeners is how Angular says: "we recognize you still need this — here is the explicit, supported way to get it."

Think of it as part of your application's provider composition — sitting alongside provideZonelessChangeDetection(), provideRouter(), and your custom ErrorHandler.

Traditional Approaches vs. The Right Way

Let's be direct about why you should not roll your own solution:

Option A: Raw window.onerror

// Works, but disconnected from Angular's DI system
window.onerror = (message, source, line, col, error) => {
  myLogger.log(error); // No access to Angular services here
};

Option B: Manual APP_INITIALIZER

// Fragile and verbose — you have to manage cleanup yourself
{
  provide: APP_INITIALIZER,
  useFactory: (handler: ErrorHandler) => () => {
    window.addEventListener('unhandledrejection', (e) => handler.handleError(e.reason));
    window.addEventListener('error', (e) => handler.handleError(e.error));
  },
  deps: [ErrorHandler],
  multi: true,
}

Option C: provideBrowserGlobalErrorListeners (correct approach)

// Clean, composable, officially maintained, SSR-aware
provideBrowserGlobalErrorListeners()

Option C is not just shorter — it is the only option the Angular team will maintain going forward. Options A and B create hidden state that is easy to get wrong and hard to test.

Bonus Tips

Tip 1: Filter noise before logging.
Not every error deserves a Sentry ticket. HTTP 401 (unauthorized) and 403 (forbidden) errors are often expected. Add a filter layer in your handler before calling your logging service.

Tip 2: Add context to your errors.
A raw stack trace is rarely enough. Add user context (anonymized), current route, and app version to every error payload. This dramatically speeds up debugging.

this.loggingService.logError({
  ...payload,
  route: this.router.url,
  appVersion: environment.version,
  userId: this.authService.currentUserId(), // anonymized
});

Tip 3: Use structured logging formats.
If you are building your own logging backend, structure your error payloads as JSON from the start. This makes them queryable in tools like Elasticsearch or CloudWatch.

Tip 4: Never show raw error messages to end users.
Map technical errors to user-friendly messages. "TypeError: Cannot read properties of undefined" means nothing to your users. "Something went wrong. Please refresh and try again." is actionable.

Tip 5: Test your error handler in production-like conditions.
Your development environment might mask errors that only appear in production builds. Add a dedicated test route that intentionally triggers different error types so your QA team can verify the full pipeline.

Recap

Here is everything we covered, condensed:

zone.js was intercepting async errors and routing them to Angular's ErrorHandler behind the scenes.
Removing zone.js (via provideZonelessChangeDetection) cuts that pipeline. Async errors become invisible to Angular.
provideBrowserGlobalErrorListeners explicitly re-establishes that pipeline by listening to window.onerror and window.unhandledrejection and forwarding them to your ErrorHandler.
It belongs in your bootstrapApplication providers alongside provideZonelessChangeDetection.
It does not work in SSR — keep it in browser-only config files.
Angular v20+ new projects get this automatically. Existing projects upgrading to zoneless must add it manually.
A good error strategy combines this provider with a typed custom ErrorHandler, a logging service, and meaningful user notifications.

The bottom line: if you are going zoneless and you are not using this provider, your error monitoring is broken right now — you just do not know it yet.

Let's Talk

What did you think of this one?

Have you already hit this issue in production? I would genuinely love to hear your story. Did you catch it before deployment, or did users find it first? Drop a comment below — that kind of real-world context helps everyone.

Here is a specific question to kick off the discussion:
When you migrated to zoneless (or when you do), what was the first thing you audited in your error handling pipeline? Was it HTTP errors, async promises, or something else entirely?

If this saved you from a sleepless debugging session, consider giving it a clap — it helps other developers find articles like this on Medium, and honestly, it makes my day.

Let's keep building better apps — one deliberate architecture decision at a time.

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

Stop Losing Errors to the Void: Handling Unhandled Promise Rejections Globally in JavaScript, Angular, and React

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

A practical, copy-paste guide to catching the promise rejections your app is currently swallowing without you knowing it

Have you ever had a user tell you "the button just didn't do anything" — and when you checked the console, there was a red error sitting there that nobody ever saw? That's usually an unhandled promise rejection, quietly failing in the background while your app pretends everything is fine.

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

Catch every unhandled promise rejection in a browser app, globally, in one place
Understand exactly what triggers unhandledrejection versus a regular try/catch
Wire this into an Angular app using the new control flow syntax and signals
Wire this into a React app using a clean custom hook
Write unit tests for both so this doesn't silently break later
Avoid the handful of mistakes that make this "solution" useless in production

If you've ever shipped a feature, felt good about your error handling, and then found out three weeks later that a whole class of failures was never being logged anywhere — this one's for you.

If this kind of "here's the gap in your error handling" deep-dive is useful, go ahead and hit follow — I write one of these every week, and the next one is about a related blind spot in error boundaries.

Before we dive into the examples, a quick note: the code snippets here are meant purely for understanding the concept. Some syntax may reflect patterns from earlier Angular or React versions by the time you're reading this. Always check the official docs for the current API and syntax.

What "Unhandled Promise Rejection" Actually Means

A promise rejection is "unhandled" when a promise fails and nothing in the chain has a .catch() or a try/catch around an await to deal with it. JavaScript doesn't throw immediately — it waits until the current microtask queue drains, and if the rejection still has no handler attached, the runtime fires an unhandledrejection event on the global object.

That's the key detail most people miss: it's not the same mechanism as a thrown synchronous error, and window.onerror will not catch it. These are two separate reporting channels, and a lot of "global error handling" setups only wire up one of them.

Here's the plain vanilla JS version, no framework involved:

window.addEventListener('unhandledrejection', (event) => {
  console.error('Unhandled promise rejection:', event.reason);

  // Optional: stop the browser from also logging its own default message
  event.preventDefault();

  // This is where you'd send it to Sentry, LogRocket, your own logging endpoint, etc.
});

You can also assign it as a property instead of an event listener:

window.onunhandledrejection = (event) => {
  console.error('Unhandled promise rejection:', event.reason);
};

The event-listener version is generally the better choice, because onunhandledrejection gets overwritten if two parts of your codebase both try to set it. addEventListener lets multiple listeners coexist.

There's also a companion event worth knowing: rejectionhandled. It fires if a promise was initially unhandled but later got a .catch() attached (common with async timing quirks). If you're building serious error tracking, you'll want to listen for both so you don't log false positives.

Wiring This Into an Angular App

In Angular, zone.js patches Promise under the hood, which means unhandled rejections inside the zone still bubble up to the same window unhandledrejection event — so the approach above works without modification. The cleanest way to use it is a small injectable service that exposes the last error as a signal, so any component can react to it.

// error-tracking.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class ErrorTrackingService {
  readonly lastError = signal<string | null>(null);

  constructor() {
    window.addEventListener('unhandledrejection', this.handleRejection);
  }

  private handleRejection = (event: PromiseRejectionEvent) => {
    const message = event.reason?.message ?? String(event.reason);
    console.error('Unhandled promise rejection:', event.reason);
    this.lastError.set(message);
    event.preventDefault();
  };
}

And a small component that surfaces it, using the new @if control flow and an input() signal for styling flexibility:

// error-banner.component.ts
import { Component, inject, input } from '@angular/core';
import { ErrorTrackingService } from './error-tracking.service';

@Component({
  selector: 'app-error-banner',
  template: `
    @if (errorTracking.lastError(); as error) {
      <div [class]="bannerClass()">
        {{ error }}
      </div>
    }
  `,
})
export class ErrorBannerComponent {
  protected errorTracking = inject(ErrorTrackingService);
  bannerClass = input('error-banner');
}

Because ErrorTrackingService is providedIn: 'root', its constructor runs once, the first time it's injected anywhere — which in practice means as soon as your app bootstraps and something requests it. Drop <app-error-banner /> near the root of your app and you have a working global catch-all.

Unit Testing the Angular Version

The tricky part of testing this is that PromiseRejectionEvent isn't something you can construct with a plain object — you have to build a regular Event and attach a reason property to it, then dispatch it on window:

// error-tracking.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { ErrorTrackingService } from './error-tracking.service';

describe('ErrorTrackingService', () => {
  let service: ErrorTrackingService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(ErrorTrackingService);
  });

  it('captures an unhandled promise rejection from window', () => {
    const rejectionEvent = new Event('unhandledrejection') as PromiseRejectionEvent;
    Object.defineProperty(rejectionEvent, 'reason', {
      value: new Error('Something broke'),
    });

    window.dispatchEvent(rejectionEvent);

    expect(service.lastError()).toBe('Something broke');
  });
});

Quick, answerable one for you: have you ever shipped a "silent" promise rejection to production and only found out about it from a confused user report instead of your monitoring tool? Drop the story in the comments — I want to hear how you eventually tracked it down.

Wiring This Into a React App

React doesn't patch promises, so the pattern is simpler: a custom hook that attaches the listener on mount and cleans it up on unmount.

// useUnhandledRejection.js
import { useEffect, useState, useCallback } from 'react';

export function useUnhandledRejection() {
  const [lastError, setLastError] = useState(null);

  const handleRejection = useCallback((event) => {
    const message = event.reason?.message ?? String(event.reason);
    console.error('Unhandled promise rejection:', event.reason);
    setLastError(message);
    event.preventDefault();
  }, []);

  useEffect(() => {
    window.addEventListener('unhandledrejection', handleRejection);
    return () => window.removeEventListener('unhandledrejection', handleRejection);
  }, [handleRejection]);

  return lastError;
}

And a component that uses it:

// ErrorBanner.jsx
import { useUnhandledRejection } from './useUnhandledRejection';

export function ErrorBanner() {
  const lastError = useUnhandledRejection();

  if (!lastError) return null;

  return <div className="error-banner">{lastError}</div>;
}

Mount <ErrorBanner /> once, near the top of your component tree, and every unhandled rejection anywhere in the app surfaces through it.

Unit Testing the React Version

Using React Testing Library, you dispatch the same kind of synthetic event and assert the banner shows up:

// ErrorBanner.test.jsx
import { render, screen, act } from '@testing-library/react';
import { ErrorBanner } from './ErrorBanner';

test('shows the error banner after an unhandled promise rejection', () => {
  render(<ErrorBanner />);

  act(() => {
    const event = new Event('unhandledrejection');
    event.reason = new Error('Something broke');
    window.dispatchEvent(event);
  });

  expect(screen.getByText('Something broke')).toBeInTheDocument();
});

One gotcha worth flagging here: if you're running tests under jsdom, its support for a real PromiseRejectionEvent constructor is limited, which is why both examples above build a plain Event and manually attach reason rather than trying to construct the browser-native event class directly.

Bonus Tips

A few things that tend to separate a "works in the demo" version of this from one that actually holds up in production:

Call event.preventDefault() only after you've logged the error somewhere durable — it suppresses the browser's own default console warning, which is convenient once you have your own logging in place, but a footgun if you add it before you're actually capturing anything.
Pair unhandledrejection with window.onerror (or a window.addEventListener('error', ...) listener) so you're covering both synchronous throws and rejected promises — they are genuinely separate mechanisms.
Listen for rejectionhandled too if you're building anything resembling real error monitoring, so a late .catch() doesn't get logged as a permanent failure.
If any part of your stack runs in Node (an SSR layer, an API route, a script), remember the API there is different: process.on('unhandledRejection', handler), not window.
Route the captured error into whatever tool you already use for monitoring (Sentry, LogRocket, your own backend) rather than leaving it in console.error — the whole point of this pattern is that a developer isn't watching the console when it happens.

Recap

Unhandled promise rejections fail silently by design, and neither Angular's zone patching nor React's rendering model catches them for you automatically — you have to opt in with a global window listener. Once that listener is in place, wrapping it in a service (Angular) or a hook (React) makes it reusable, testable, and easy to hook into whatever logging or monitoring tool you already rely on.

Did this approach match how you're already 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'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

Stop Leaking Memory in Angular: withExperimentalAutoCleanupInjectors Explained

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

Stop leaking memory on every route change — Angular's new `withExperimentalAutoCleanupInjectors` fixes the problem you didn't know you had

Have you ever wondered why your Angular app slowly feels heavier the longer a user navigates around? Why services that should be "route-specific" seem to stick around forever? If you've used takeUntilDestroyed() inside a route-level service and had a nagging feeling it wasn't truly cleaning up — you were right.

Angular 21.1 shipped a feature that solves exactly this: withExperimentalAutoCleanupInjectors. It's experimental, it's opt-in, and it might be the most important router addition this year.

Before we dive in, drop a quick comment: Have you ever hit a memory leak caused by route-level services in Angular? How did you handle it? I'm genuinely curious — and your experience might help someone else reading this.

What You Will Learn

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

Why Angular route injectors used to leak memory silently
What withExperimentalAutoCleanupInjectors actually does
How to enable and configure it in a modern Angular 21+ standalone app
How to work with it alongside a custom RouteReuseStrategy
Patterns like takeUntilDestroyed() and Signals that now work correctly in route-level services
How to write unit tests that verify injector cleanup behavior

The Problem Nobody Talked About (But Everyone Hit)

When you add providers to a route, or use lazy loading, Angular creates a dedicated EnvironmentInjector for that route. That injector hosts the services defined at that route level. Makes sense, right?

The problem? Until Angular 21.1, those injectors were never destroyed. Ever.

You navigate to /dashboard, Angular creates a route injector for it. You navigate away to /profile. The /dashboard injector? Still alive. Navigate to ten more routes? All ten injectors, still alive, services still ticking, subscriptions still running.

Here's what that meant in practice:

// This service lives at route level in your routes config
@Injectable()
export class DashboardPollingService {
  private data = signal<DashboardData[]>([]);

  constructor() {
    // You THINK this stops when you leave the route.
    // Before Angular 21.1? It never did.
    interval(3000)
      .pipe(takeUntilDestroyed())
      .subscribe(() => this.fetchData());
  }

  private fetchData() {
    // Keeps running forever...
  }
}

The takeUntilDestroyed() operator works by listening to the injector's destroy signal. But if the injector is never destroyed, the signal never fires. Your polling keeps running, your HTTP calls keep happening, and your memory keeps growing.

Enter `withExperimentalAutoCleanupInjectors`

Angular 21.1 introduces this as an opt-in router feature that automatically destroys EnvironmentInjectors associated with routes that are no longer active and not stored for reuse.

After each successful navigation (specifically after NavigationEnd when the router stabilizes), Angular walks the route tree and destroys injectors for any routes that are no longer part of the active tree — unless your RouteReuseStrategy says to keep them.

The cleanup is hierarchical too: if a parent route's injector gets destroyed, all descendant injectors are destroyed with it, maintaining the integrity of the injection tree.

Setting It Up: One Line in Your App Config

Here's the beautiful part. Enabling it takes a single addition to your provideRouter call:

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter, withExperimentalAutoCleanupInjectors } from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withExperimentalAutoCleanupInjectors()  // <-- that's it
    )
  ]
};

No module changes. No additional configuration. Just one function call and your route injectors now get properly cleaned up.

The Real-World Impact: Before and After

Let's look at a realistic example. Say you have a route-level service for a dashboard feature that polls for notifications and exposes a signal:

Before (broken cleanup, pre 21.1 or without the feature):

// dashboard/dashboard-notifications.service.ts
@Injectable()
export class DashboardNotificationsService implements OnDestroy {
  notifications = signal<Notification[]>([]);
  private subscription!: Subscription;

  constructor(private http: HttpClient) {
    // You had to manually manage this AND it still
    // didn't work reliably because ngOnDestroy wasn't called
    this.subscription = interval(5000).subscribe(() => this.loadNotifications());
  }

  private loadNotifications() {
    this.http.get<Notification[]>('/api/notifications').subscribe(data => {
      this.notifications.set(data);
    });
  }

  ngOnDestroy() {
    // This was never reliably called for route-level services
    this.subscription.unsubscribe();
  }
}

After (clean, Angular 21.1+ with auto cleanup):

// dashboard/dashboard-notifications.service.ts
@Injectable()
export class DashboardNotificationsService {
  notifications = signal<Notification[]>([]);
  private http = inject(HttpClient);

  constructor() {
    // takeUntilDestroyed now works correctly because
    // the injector IS destroyed when you leave the route
    interval(5000)
      .pipe(
        takeUntilDestroyed(),
        switchMap(() => this.http.get<Notification[]>('/api/notifications'))
      )
      .subscribe(data => this.notifications.set(data));
  }
}

And the route definition that makes this service route-scoped:

// app.routes.ts
import { Routes } from '@angular/router';
import { DashboardComponent } from './dashboard/dashboard.component';
import { DashboardNotificationsService } from './dashboard/dashboard-notifications.service';

export const routes: Routes = [
  {
    path: 'dashboard',
    component: DashboardComponent,
    providers: [DashboardNotificationsService]  // Route-scoped service
  },
  {
    path: 'profile',
    loadComponent: () => import('./profile/profile.component')
  }
];

When the user navigates away from /dashboard, the DashboardNotificationsService injector is destroyed, takeUntilDestroyed() fires, and your polling stops. Clean. Predictable. How it always should have worked.

Quick mid-article check-in

If this is already making you think about services in your own app that might be leaking — give this article a clap so more Angular devs can find it. And if you're wondering whether your current project is affected, keep reading — I'll show you how to verify it.

Working with Lazy-Loaded Routes

The feature works equally well with lazy-loaded routes, which is where you're most likely to benefit from it:

// app.routes.ts
export const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () => import('./admin/admin.routes').then(m => m.ADMIN_ROUTES)
    // The entire lazy chunk gets its own injector.
    // With auto-cleanup, it's destroyed when you leave.
  },
  {
    path: 'home',
    loadComponent: () => import('./home/home.component')
  }
];

// admin/admin.routes.ts
import { Routes } from '@angular/router';
import { AdminDashboardComponent } from './admin-dashboard.component';
import { AdminDataService } from './admin-data.service';

export const ADMIN_ROUTES: Routes = [
  {
    path: '',
    component: AdminDashboardComponent,
    providers: [AdminDataService]
  }
];

// admin/admin-data.service.ts
@Injectable()
export class AdminDataService {
  private users = signal<User[]>([]);
  private http = inject(HttpClient);

  readonly users$ = this.users.asReadonly();

  constructor() {
    // toSignal and toObservable now clean up correctly
    // when this route's injector is destroyed
    this.loadInitialData();
  }

  private loadInitialData() {
    this.http.get<User[]>('/api/admin/users')
      .pipe(takeUntilDestroyed())
      .subscribe(users => this.users.set(users));
  }

  refreshUsers() {
    this.http.get<User[]>('/api/admin/users')
      .pipe(take(1))
      .subscribe(users => this.users.set(users));
  }
}

Custom RouteReuseStrategy: What You Need to Implement

If your app doesn't use a custom RouteReuseStrategy, or it extends BaseRouteReuseStrategy, you're done — injectors are automatically destroyed for inactive routes. The BaseRouteReuseStrategy already implements shouldDestroyInjector returning true.

If you have a fully custom RouteReuseStrategy that doesn't extend BaseRouteReuseStrategy, you need to implement two additional methods:

`shouldDestroyInjector`

Tells the router whether to destroy the injector for a given route. Return true to allow destruction.

`retrieveStoredRouteHandles`

If your strategy stores detached route handles, this method lets the router know which routes are stored so it doesn't destroy their injectors.

// custom-route-reuse-strategy.ts
import {
  RouteReuseStrategy,
  ActivatedRouteSnapshot,
  DetachedRouteHandle,
  Route
} from '@angular/router';
import { Injectable } from '@angular/core';

@Injectable()
export class CustomRouteReuseStrategy implements RouteReuseStrategy {
  private storedHandles = new Map<string, { handle: DetachedRouteHandle; route: Route }>();

  shouldDetach(route: ActivatedRouteSnapshot): boolean {
    return route.data['reuseComponent'] === true;
  }

  store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle | null): void {
    const key = this.getRouteKey(route);
    if (handle && key) {
      this.storedHandles.set(key, { handle, route: route.routeConfig! });
    } else if (key) {
      this.storedHandles.delete(key);
    }
  }

  shouldAttach(route: ActivatedRouteSnapshot): boolean {
    const key = this.getRouteKey(route);
    return !!key && this.storedHandles.has(key);
  }

  retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle | null {
    const key = this.getRouteKey(route);
    return key ? (this.storedHandles.get(key)?.handle ?? null) : null;
  }

  shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
    return future.routeConfig === curr.routeConfig;
  }

  // Required for withExperimentalAutoCleanupInjectors:
  // Tell the router which routes have stored handles
  retrieveStoredRouteHandles(): DetachedRouteHandle[] {
    return Array.from(this.storedHandles.values()).map(entry => entry.handle);
  }

  // Required for withExperimentalAutoCleanupInjectors:
  // Decide per-route whether its injector can be destroyed
  shouldDestroyInjector(route: Route): boolean {
    // Preserve the injector if this route has a stored handle
    const hasStoredHandle = Array.from(this.storedHandles.values())
      .some(entry => entry.route === route);
    return !hasStoredHandle;
  }

  private getRouteKey(route: ActivatedRouteSnapshot): string | null {
    return route.routeConfig?.path ?? null;
  }
}

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import {
  provideRouter,
  withExperimentalAutoCleanupInjectors,
  RouteReuseStrategy
} from '@angular/router';
import { routes } from './app.routes';
import { CustomRouteReuseStrategy } from './custom-route-reuse-strategy';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withExperimentalAutoCleanupInjectors()),
    {
      provide: RouteReuseStrategy,
      useClass: CustomRouteReuseStrategy
    }
  ]
};

Signals and Reactive Primitives Now Work as Expected

One of the biggest wins here is that Angular's modern reactive primitives finally work correctly inside route-level services.

`toSignal` in a Route-Scoped Service

// products/products.service.ts
@Injectable()
export class ProductsService {
  private http = inject(HttpClient);
  private route = inject(ActivatedRoute);

  // toSignal requires an injection context.
  // It also subscribes internally — and previously never cleaned up
  // for route-level services. Now it does.
  readonly queryParam = toSignal(
    this.route.queryParamMap.pipe(map(params => params.get('category') ?? 'all')),
    { initialValue: 'all' }
  );

  readonly products = toSignal(
    this.route.queryParamMap.pipe(
      map(params => params.get('category') ?? 'all'),
      distinctUntilChanged(),
      switchMap(category => this.http.get<Product[]>(`/api/products?category=${category}`))
    ),
    { initialValue: [] }
  );
}

`toObservable` Works Correctly Too

// cart/cart.service.ts
@Injectable()
export class CartService {
  readonly items = signal<CartItem[]>([]);
  readonly totalCount = computed(() => this.items().reduce((sum, i) => sum + i.qty, 0));

  // Previously, toObservable subscriptions leaked if this service was route-scoped.
  // Now the injector cleanup handles it automatically.
  readonly totalCount$ = toObservable(this.totalCount);
}

Writing Unit Tests for Injector Cleanup

Testing that your services clean up properly is important, especially with this feature. Here's how to verify it:

// dashboard-notifications.service.spec.ts
import { TestBed, fakeAsync, tick, discardPeriodicTasks } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { DashboardNotificationsService } from './dashboard-notifications.service';

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

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [DashboardNotificationsService]
    });
    service = TestBed.inject(DashboardNotificationsService);
    httpMock = TestBed.inject(HttpTestingController);
  });

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

  it('should initialize with empty notifications', () => {
    expect(service.notifications()).toEqual([]);
  });

  it('should stop polling when the injector is destroyed', fakeAsync(() => {
    // Simulate one polling cycle
    tick(5000);

    const req = httpMock.expectOne('/api/notifications');
    req.flush([{ id: 1, message: 'Test notification' }]);

    expect(service.notifications().length).toBe(1);

    // Destroy the TestBed (simulates injector destruction)
    TestBed.resetTestingModule();

    // Tick further — no more HTTP requests should be made
    // (this would throw if polling were still active)
    discardPeriodicTasks();
  }));

  it('should update notifications signal when data arrives', fakeAsync(() => {
    tick(5000);

    const mockNotifications = [
      { id: 1, message: 'First notification' },
      { id: 2, message: 'Second notification' }
    ];

    const req = httpMock.expectOne('/api/notifications');
    req.flush(mockNotifications);

    expect(service.notifications().length).toBe(2);
    expect(service.notifications()[0].message).toBe('First notification');

    discardPeriodicTasks();
  }));
});

Testing the CustomRouteReuseStrategy with the new methods:

// custom-route-reuse-strategy.spec.ts
import { TestBed } from '@angular/core/testing';
import { ActivatedRouteSnapshot, DetachedRouteHandle, Route } from '@angular/router';
import { CustomRouteReuseStrategy } from './custom-route-reuse-strategy';

describe('CustomRouteReuseStrategy', () => {
  let strategy: CustomRouteReuseStrategy;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [CustomRouteReuseStrategy]
    });
    strategy = TestBed.inject(CustomRouteReuseStrategy);
  });

  it('should return empty array when no handles are stored', () => {
    expect(strategy.retrieveStoredRouteHandles()).toEqual([]);
  });

  it('should return stored handles via retrieveStoredRouteHandles', () => {
    const mockRoute = { routeConfig: { path: 'test', data: { reuseComponent: true } } } as ActivatedRouteSnapshot;
    const mockHandle = {} as DetachedRouteHandle;

    strategy.store(mockRoute, mockHandle);

    const handles = strategy.retrieveStoredRouteHandles();
    expect(handles.length).toBe(1);
    expect(handles[0]).toBe(mockHandle);
  });

  it('shouldDestroyInjector should return true for non-stored routes', () => {
    const route: Route = { path: 'some-route' };
    expect(strategy.shouldDestroyInjector(route)).toBe(true);
  });

  it('shouldDestroyInjector should return false for stored route handles', () => {
    const mockRoute = {
      routeConfig: { path: 'cached', data: { reuseComponent: true } }
    } as ActivatedRouteSnapshot;
    const mockHandle = {} as DetachedRouteHandle;

    strategy.store(mockRoute, mockHandle);

    // The route from routeConfig should be preserved
    const storedRoute = mockRoute.routeConfig!;
    expect(strategy.shouldDestroyInjector(storedRoute)).toBe(false);
  });

  it('should clean up stored handle on null store call', () => {
    const mockRoute = {
      routeConfig: { path: 'test', data: { reuseComponent: true } }
    } as ActivatedRouteSnapshot;
    const mockHandle = {} as DetachedRouteHandle;

    strategy.store(mockRoute, mockHandle);
    expect(strategy.retrieveStoredRouteHandles().length).toBe(1);

    strategy.store(mockRoute, null);
    expect(strategy.retrieveStoredRouteHandles().length).toBe(0);
  });
});

Bonus Tips

Tip 1: Pair with DestroyRef for fine-grained control.
Inside your route-scoped services, inject DestroyRef directly and run your own cleanup logic on top of what Angular does automatically:

@Injectable()
export class FeatureService {
  private destroyRef = inject(DestroyRef);

  constructor() {
    this.destroyRef.onDestroy(() => {
      console.log('FeatureService cleaned up — route injector was destroyed');
      // Any additional cleanup not covered by takeUntilDestroyed
    });

    interval(2000)
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(() => this.poll());
  }

  private poll() { /* ... */ }
}

Tip 2: It's experimental, not unstable.
The "experimental" label means the API might change in minor ways before stabilization. The core behavior is already solid. Add it to greenfield projects and new route features now — just watch the Angular changelog for any API updates.

Tip 3: Parent injector destruction cascades.
If a parent route's injector is destroyed, all child route injectors are destroyed regardless of their individual shouldDestroyInjector return values. Design your route hierarchy with this in mind.

Tip 4: Don't put it in a @NgModule.
This is a provider function for the functional provideRouter API. If you're still using RouterModule.forRoot(), this won't work. Time to migrate if you haven't already.

Recap: What We Covered

Here's the full picture in one place:

The problem: Route-level EnvironmentInjectors were never destroyed in Angular, causing memory leaks and making takeUntilDestroyed(), toSignal(), and toObservable() unreliable in route-scoped services.

The fix: withExperimentalAutoCleanupInjectors() — one call in provideRouter — enables automatic destruction of route injectors after navigation, when routes are no longer active and not stored for reuse.

How it works: After NavigationEnd, Angular checks each route's injector against the active route tree and the RouteReuseStrategy. Injectors for inactive, non-reused routes are destroyed. Parent destruction cascades to children.

What you need for custom strategies: Implement shouldDestroyInjector() and retrieveStoredRouteHandles() in any custom RouteReuseStrategy that doesn't extend BaseRouteReuseStrategy.

The payoff: Modern Angular APIs like Signals, takeUntilDestroyed(), toSignal(), and ngOnDestroy work correctly and reliably in route-scoped services.

Let's Talk

What did you think? Have you already hit this exact issue in production, or is this something you'll proactively add to your next project? Vote in the comments:

A: Already hit this issue and solved it manually
B: Did not know about this leak — applying the fix now
C: Still on an older Angular version and need to migrate first

If this saved you from a subtle memory leak, hit that clap button — it takes one second and helps other Angular devs find this article. You'd be doing the community a real favor.

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 CDK Got Better in Angular 22: Host Directive De-Duplication and Portal Directives Explained - What Changes in NG 22 (Part 11)

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

Why composing small, reusable directives used to break in surprising ways — and how the CDK's dynamic component rendering just got a lot more capable

Ever built two small, focused host directives, only to slap them both on the same element and get a duplicate directive error that made no sense at first glance? If you've spent time with Angular's Directive Composition API, there's a good chance you've hit exactly this wall — two directives that each quietly pull in the same shared behavior, and Angular refusing to let them coexist.

Angular 22 fixes that, and pairs it with a second, less talked-about improvement: the CDK's ComponentPortal can now attach directives to a component it renders dynamically. Both changes are aimed at the same underlying problem — composing behavior without duplicating it or baking it into components that shouldn't need to know about it. This one's a bit more advanced than the usual "here's a new signal function" post, so it'll appeal most if you write shared directives, build component libraries, or lean on the CDK's Portal API for dynamic rendering. By the end, you'll know:

Why two directives that both use hostDirectives to pull in the same shared directive used to conflict
How Angular 22's de-duplication resolves that, and the one rule you still have to follow
How ComponentPortal can now apply directives to a dynamically rendered component's host element
How the same directive can travel with a component across both CdkPortalOutlet and DomPortalOutlet
How to unit test both patterns

If you've been following the rest of this Angular 22 series — resources, the router, templates, the AI tooling — this is the entry aimed squarely at library authors and anyone building serious component composition. If none of that rings a bell yet, it's worth a look too; these patterns show up the moment your app grows past a handful of components.

One thing before we dig in: this is the kind of topic that doesn't get nearly enough coverage, so if it's useful, following me here means you catch the next one of these instead of scrolling past it 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 versions. Always refer to the official documentation for the most current API and syntax.

The problem: shared behavior, duplicated by accident

Angular's Directive Composition API lets a directive pull in another directive's behavior through hostDirectives, which is a great way to keep each directive small and focused instead of writing one directive that does everything. The trouble starts when two different higher-level directives both happen to reuse the same lower-level one — a pattern that's common the moment you're building a small internal library rather than a one-off feature.

Say you've got a shared directive that manages a transient, accessible status message on whatever element it's attached to:

import { computed, DestroyRef, Directive, inject, input, signal } from '@angular/core';

@Directive({
  selector: '[appStatusMessage]',
  host: {
    'aria-live': 'polite',
    '[attr.data-status]': 'visibleMessage()',
    '[class.show-status]': 'hasMessage()',
  },
})
export class StatusMessageDirective {
  readonly idleLabel = input('');
  private readonly temporaryMessage = signal<string | null>(null);
  private timeoutId: ReturnType<typeof setTimeout> | null = null;
  private readonly destroyRef = inject(DestroyRef);

  constructor() {
    this.destroyRef.onDestroy(() => this.clear());
  }

  protected readonly hasMessage = computed(() => this.temporaryMessage() !== null);
  protected readonly visibleMessage = computed(
    () => this.temporaryMessage() ?? this.idleLabel(),
  );

  announce(message: string, duration = 2000): void {
    this.clear();
    this.temporaryMessage.set(message);
    this.timeoutId = setTimeout(() => this.temporaryMessage.set(null), duration);
  }

  private clear(): void {
    if (this.timeoutId !== null) {
      clearTimeout(this.timeoutId);
      this.timeoutId = null;
    }
  }
}

Now build two independent, higher-level directives on top of it — one that toggles a favorite state, one that copies a share link — and have each of them compose StatusMessageDirective to announce what just happened.

import { Directive, inject, input, signal } from '@angular/core';
import { StatusMessageDirective } from './status-message.directive';

@Directive({
  selector: '[appFavoriteToggle]',
  hostDirectives: [{ directive: StatusMessageDirective, inputs: ['idleLabel: status'] }],
  host: {
    '(click)': 'toggle()',
    '[class.is-favorited]': 'favorited()',
  },
})
export class FavoriteToggleDirective {
  readonly itemId = input.required<string>();
  protected readonly favorited = signal(false);
  private readonly status = inject(StatusMessageDirective);

  protected toggle(): void {
    this.favorited.update((current) => !current);
    this.status.announce(
      this.favorited() ? 'Added to favorites' : 'Removed from favorites',
    );
  }
}

import { Directive, inject, input } from '@angular/core';
import { StatusMessageDirective } from './status-message.directive';

@Directive({
  selector: '[appShareLink]',
  hostDirectives: [{ directive: StatusMessageDirective, inputs: ['idleLabel: status'] }],
  host: {
    '(click)': 'share()',
  },
})
export class ShareLinkDirective {
  readonly url = input.required<string>();
  private readonly status = inject(StatusMessageDirective);

  protected async share(): Promise<void> {
    try {
      await navigator.clipboard.writeText(this.url());
      this.status.announce('Link copied');
    } catch {
      this.status.announce('Unable to copy link');
    }
  }
}

Both directives are small, focused, and independently useful. Naturally, you'll want to apply both to the same action bar so a card's footer can both favorite and share, sharing one status announcement region:

<div
  appFavoriteToggle
  [itemId]="item.id"
  appShareLink
  [url]="item.shareUrl"
  status="Card actions"
  class="card-actions"
>
  <button aria-label="Favorite">Favorite</button>
  <button aria-label="Share">Share</button>
</div>

Before Angular 22, this setup throws a duplicate directive error. Angular sees appFavoriteToggle bringing in StatusMessageDirective, sees appShareLink bringing in the very same directive, and concludes — incorrectly, from your point of view — that the same directive is being matched twice on one element. You weren't trying to create two separate status regions; you were composing two independent behaviors that happen to share one lower-level dependency, which is exactly the kind of thing you'd expect the Directive Composition API to support cleanly.

Angular 22 de-duplicates shared host directives

Angular 22 fixes this directly: when the same directive shows up more than once in the resolved host directive tree, Angular merges those matches into a single shared instance instead of treating them as a conflict. The two action-bar directives above now work together without any code changes on your part — the composition just works the way you'd expect.

There's one rule worth keeping in mind, though. Angular still has to reconcile the input and output aliases from every place the shared directive is composed, so if two directives expose the same underlying input under two different aliases, you're back to an error — this time NG8024, conflicting host directive binding. In the example above, both FavoriteToggleDirective and ShareLinkDirective alias idleLabel to status, which is exactly why they merge cleanly. If one of them had aliased it to something else instead, Angular wouldn't be able to decide which public name should win.

So the practical rule is simple: if multiple directives in your library reuse the same shared host directive, keep their aliases for that directive's inputs and outputs consistent across the board.

Have you run into this exact duplicate-directive error before finding out why it was happening? I'd genuinely like to know whether people worked around it by merging directives into one, or just avoided composing them on the same element entirely.

Dynamic component rendering gets more capable: directives on `ComponentPortal`

The CDK's Portal API is Angular's lower-level tool for dynamic component rendering — instead of declaring a component in a template, you describe it as a ComponentPortal and hand it to a PortalOutlet to actually create and attach. Until this release, a component rendered this way had no clean way to receive host-level behavior specific to where it was being rendered — you either baked that behavior into the component itself, which coupled it to one particular context, or you left it out.

Say you have a small NotificationPanel component that needs to behave like an accessible live region — role="status", aria-live="polite", and focus when it appears — but you render it in two different places: inline inside a page, and as a floating panel attached directly to the document body.

A directive is the right home for that host-level behavior, since it keeps NotificationPanel itself free of any assumptions about where it's rendered:

import { afterNextRender, Directive, ElementRef, inject, input } from '@angular/core';

@Directive({
  selector: '[appLiveRegion]',
  host: {
    role: 'status',
    'aria-live': 'polite',
    '[attr.aria-label]': 'label()',
    tabindex: '-1',
  },
})
export class LiveRegionDirective {
  readonly label = input('');
  private readonly elementRef = inject(ElementRef);

  constructor() {
    afterNextRender(() => this.elementRef.nativeElement.focus());
  }
}

Angular 22 lets ComponentPortal apply directives like this one directly to the component it creates. The directive configuration is passed as an additional argument alongside the existing portal options, using inputBinding() to feed values into the directive:

import { ComponentPortal } from '@angular/cdk/portal';
import { inputBinding } from '@angular/core';
import { NotificationPanel } from './notification-panel';
import { LiveRegionDirective } from './live-region.directive';

protected readonly notificationPortal = computed(() =>
  this.showNotification()
    ? new ComponentPortal(
        NotificationPanel,
        null, // viewContainerRef
        null, // injector
        null, // projectableNodes
        undefined, // bindings
        [
          {
            type: LiveRegionDirective,
            bindings: [inputBinding('label', () => 'Order status update')],
          },
        ],
      )
    : null,
);

The inline version renders through a template outlet, just like any other ComponentPortal usage:

<ng-template [cdkPortalOutlet]="notificationPortal()"></ng-template>

For the floating version, you attach the same kind of portal — with the same directive, but a different label — to a DomPortalOutlet targeting an element appended straight to the document body:

import { DomPortalOutlet } from '@angular/cdk/portal';

private openFloatingNotification(): void {
  const hostElement = this.document.createElement('div');
  hostElement.classList.add('floating-notification');
  this.document.body.append(hostElement);

  const outlet = new DomPortalOutlet(hostElement, this.appRef, this.injector);

  outlet.attach(
    new ComponentPortal(
      NotificationPanel,
      null,
      null,
      null,
      undefined,
      [
        {
          type: LiveRegionDirective,
          bindings: [inputBinding('label', () => 'Floating order update')],
        },
      ],
    ),
  );
}

Same component, same directive, two different rendering contexts, two different accessible labels — and NotificationPanel itself never has to know any of that. The portal, not the component, decides what host-level behavior fits the place it's being rendered.

Unit testing both patterns

Testing host directive composition is straightforward: mount a host component that applies both directives, trigger the interaction, and check the shared directive's effect on the DOM.

import { Component, signal } from '@angular/core';
import { TestBed } from '@angular/core/testing';
import { FavoriteToggleDirective } from './favorite-toggle.directive';
import { ShareLinkDirective } from './share-link.directive';

@Component({
  selector: 'app-test-host',
  imports: [FavoriteToggleDirective, ShareLinkDirective],
  template: `
    <div
      appFavoriteToggle
      itemId="item-1"
      appShareLink
      [url]="shareUrl()"
      status="Card actions"
    ></div>
  `,
})
class TestHost {
  protected readonly shareUrl = signal('https://example.com/item-1');
}

describe('FavoriteToggleDirective and ShareLinkDirective composition', () => {
  it('applies without a duplicate directive error and shares one status region', () => {
    const fixture = TestBed.createComponent(TestHost);
    fixture.detectChanges();

    const host = fixture.nativeElement.querySelector('[appFavoriteToggle]');
    expect(host.getAttribute('data-status')).toBe('Card actions');

    host.dispatchEvent(new Event('click'));
    fixture.detectChanges();

    expect(host.getAttribute('data-status')).toBe('Added to favorites');
  });
});

For the Portal directive, the useful thing to verify is that the directive's host attributes actually land on the dynamically rendered component, not just that the portal attaches without throwing.

import { Component, ViewChild } from '@angular/core';
import { TestBed } from '@angular/core/testing';
import { CdkPortalOutlet, ComponentPortal, PortalModule } from '@angular/cdk/portal';
import { inputBinding } from '@angular/core';
import { NotificationPanel } from './notification-panel';
import { LiveRegionDirective } from './live-region.directive';

@Component({
  selector: 'app-portal-host',
  imports: [PortalModule],
  template: `<ng-template [cdkPortalOutlet]="portal"></ng-template>`,
})
class PortalHost {
  @ViewChild(CdkPortalOutlet) outlet!: CdkPortalOutlet;

  protected readonly portal = new ComponentPortal(
    NotificationPanel,
    null,
    null,
    null,
    undefined,
    [
      {
        type: LiveRegionDirective,
        bindings: [inputBinding('label', () => 'Order status update')],
      },
    ],
  );
}

describe('NotificationPanel rendered through a portal', () => {
  it('receives the live region directive on its host element', () => {
    const fixture = TestBed.createComponent(PortalHost);
    fixture.detectChanges();

    const panel = fixture.nativeElement.querySelector('app-notification-panel');
    expect(panel.getAttribute('role')).toBe('status');
    expect(panel.getAttribute('aria-label')).toBe('Order status update');
  });
});

Both tests check the same kind of thing, really: that behavior composed from the outside actually lands on the element it's supposed to, without requiring the component underneath to know anything about it.

Bonus tips

Keep shared host directives narrow. The de-duplication fix makes sharing a common directive across multiple composed directives safe, but it's still easiest to reason about if that shared directive does one well-defined thing — a status message, a focus behavior — rather than several.
Watch for NG8024 after upgrading, not before. If you already had multiple directives quietly composing the same shared directive under different aliases, that setup was probably throwing the old duplicate-directive error already — this is a good moment to align those aliases rather than something that suddenly needs fixing.
ComponentPortal's directive argument is verbose on purpose — wrap it if you use it often. Passing null through several unused constructor arguments just to reach the new directives array gets old fast; a small helper function that fills in the boilerplate arguments is worth writing if you're doing this more than once or twice.
Pair Portal directives with ApplicationRef.bootstrap()'s new config object for micro frontends. Angular 22 also lets bootstrap() accept a configuration object, including a hostElement, which is a natural complement to Portal-based dynamic rendering when you're mounting Angular components into DOM the framework didn't create.
Don't reach for Portal directives just to avoid passing an @Input. This pattern earns its complexity when the same component genuinely needs different host behavior in different rendering contexts — for a component that always needs the same behavior everywhere, a plain input is still simpler.

Recap

Angular 22's CDK improvements are both about the same idea from different angles: composing behavior without duplicating it. Host directive de-duplication means small, focused directives that share a common dependency no longer conflict just because two higher-level directives happen to need the same lower-level one — as long as their aliases agree. And ComponentPortal accepting directives means a dynamically rendered component can pick up context-specific host behavior from wherever it's being rendered, without that behavior getting baked into the component itself.

Neither change is something you'll hit on day one with a simple app, but the moment you're building a shared directive library, or rendering the same component through more than one Portal outlet, both of these are exactly the kind of fix that turns "this shouldn't be this hard" into "oh, that's clean."

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

DEV Community: Rajat

Angular 22.2 Explained: Router Resources, Error Boundaries, and Private Template Access

Three developer-preview features that quietly change how you load data, isolate failures, and structure components

What You Will Learn

Feature 1: Angular Router Resources

The problem with loading inside the component

Moving the resource into the router

Receiving the value as a plain input

Enabling the feature

Unit testing a component that receives router data

Feature 2: Angular Error Boundaries

Why one broken child hurts everyone

Isolating the failure with @boundary and @error

Testing the fallback

Feature 3: Private Members in Templates

Testing it

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Browser Error Tracking: The Errors Your SDK Never Sends

An offline-first browser error tracking pipeline that runs inside the failure path, redacts before it stores anything, and slows one repeating failure instead of a whole page.

Why browser error tracking fails at the worst possible moment

The reporter that throws while it reports

Where do browser errors go when the network is down?

Redaction should happen before storage, not before upload

One failing poll should not bury every other error

The errors a window.onerror handler cannot see

Wiring React and Angular error boundaries without replacing them

From a support ticket to one self-contained HTML report

Sending records to your backend, on purpose

Testing a browser error tracker without a browser

The full integration, and the answer to the question from the top

Follow Me for More Angular & Frontend Goodness:

Angular's provideBrowserGlobalErrorListeners: The Missing Piece in Your Zoneless Error Strategy

How one small provider can save your production app from silent, untracked errors — and why most Angular teams miss it.

Introduction

What Is provideBrowserGlobalErrorListeners?

The Hidden Contract with zone.js

What Breaks Without zone.js

Setting Up provideBrowserGlobalErrorListeners

Step 1: Bootstrap with the provider

Step 2: Build a production-grade custom ErrorHandler

Step 3: Wire in your logging service

Integrating with Sentry in a Real Application

Behavior Comparison: zone.js vs. Zoneless + Provider

Conceptual Flow Diagram

Pitfalls and Edge Cases

1. Duplicate error reporting

2. SSR considerations

3. Swallowing errors in production

4. Angular v20+ includes it by default for new projects

Writing Unit Tests for Your Error Handler

Testing the custom ErrorHandler

Testing that unhandledrejection is caught end-to-end

How This Fits into the Modern Angular Architecture

Traditional Approaches vs. The Right Way

Bonus Tips

Recap

Suggested Titles for this Article

Let's Talk

Follow Me for More Angular & Frontend Goodness:

Stop Losing Errors to the Void: Handling Unhandled Promise Rejections Globally in JavaScript, Angular, and React

A practical, copy-paste guide to catching the promise rejections your app is currently swallowing without you knowing it

What "Unhandled Promise Rejection" Actually Means

Wiring This Into an Angular App

Unit Testing the Angular Version

Wiring This Into a React App

Unit Testing the React Version

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Stop Leaking Memory in Angular: withExperimentalAutoCleanupInjectors Explained

Stop leaking memory on every route change — Angular's new withExperimentalAutoCleanupInjectors fixes the problem you didn't know you had

What You Will Learn

The Problem Nobody Talked About (But Everyone Hit)

Enter withExperimentalAutoCleanupInjectors

Setting It Up: One Line in Your App Config

The Real-World Impact: Before and After

Quick mid-article check-in

Working with Lazy-Loaded Routes

What Is `provideBrowserGlobalErrorListeners`?

Stop leaking memory on every route change — Angular's new `withExperimentalAutoCleanupInjectors` fixes the problem you didn't know you had

Enter `withExperimentalAutoCleanupInjectors`

`shouldDestroyInjector`

`retrieveStoredRouteHandles`

`toSignal` in a Route-Scoped Service

`toObservable` Works Correctly Too

Dynamic component rendering gets more capable: directives on `ComponentPortal`

Exhaustive `@switch` checks

`CanMatch` guards now require a third parameter