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

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

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