In the realm of software testing, the concept of time can be a tricky one to manage, especially when dealing with asynchronous operations and timeouts. We are continually refining our approach to handling time in unit tests, particularly concerning the use of mock clocks. We’ve found that mock clocks, while useful, often lead to headaches in test code and unrealistic timing scenarios. To address these challenges, we are exploring the exciting concept of “auto-advancing” mock clocks, which aim to streamline testing and enhance the accuracy of time-based simulations. In this blog post, we’ll delve into the intricacies of mock clocks, their limitations, and the potential benefits of auto-advancing functionality.

Why use a mock clock

We see a few reasons to install mock clocks in tests.

1. To fake the date. This makes it possible to test components which display the current time or date related information, or do some calculation with respect to the current time.
2. More frequently, to speed up time. UIs are frequently written with debounces, visible delays for users, timeouts, etc. We want to verify the state of the app after these long-running tasks complete but we don’t want the test to actually wait 30 seconds for a timeout. Instead, mock clocks can fake the progression of time without needing to modify the production code to expose some overridable timeout simply to make the test quicker.
3. To prevent timers from leaking into other tests, creating action at a distance errors. Mock clocks can uninstall after each test and either dispose of or flush any pending timers.
4. To execute all pending timers or stabilize the test. This allows the test to say, “wait until everything that’s supposed to happen has happened”. This can be useful for several reasons, including to verify that something isn’t going to happen. For example, consider testing Gmail’s “undo” send button. After clicking the button, you would want to verify that the RPC to send the email was never sent. We can also verify that there is no pending work. If the test finishes while there is more asynchronous work pending, we don’t want the pending work to continue executing during the next test case. (It’s hopelessly confusing.) The test should either (1) wait for the work to finish, (2) dispose() of the workers explicitly, or (3, least preferred) ask the fake clock to discard pending timers/frames.
5. Much less common is to make time progress in specific increments in a unit test. One example might be a toast which appears after a known delay, and disappears after another known delay. This use of mock clocks, however, is not really a separate point from the second. We already have the ability to tick the clock specific amounts of time with timeouts. It’s just slow and mock clocks provide nice APIs to speed it up. Mock clocks can make these specific increments more predictable in tests. When using real timeouts, the ordering can sometimes depend on how quickly each task can be processed.

These are pretty good reasons to use a fake clock, and pretty broadly useful when async code is in play. We do support the idea of installing a fake clock.

Common pitfalls with mock clocks

While mock clocks offer a degree of control over time in tests, they can also introduce challenges and anti-patterns, and these all apply equally to Angular’s fakeAsync test helper.

Before the widespread availability and adoption of Promises and async/await in javascript, mock clocks helped keep tests manageable by making them synchronous. In modern-day javascript, we no longer need this. Furthermore, native Promises, async-await, resize or mutation observers, RPCs, etc cannot be executed synchronously; it is impossible to write a synchronous test for such logic. Tests with mock clocks are often forced into a situation where they need to both tick the mocked time and wait for real asynchronous code to happen. This can lead to unrealistic execution orders and can mask timing-related bugs. As a tester, keeping track of this can become a real nightmare and as a result, we’ve seen plenty of “big hammer” helper functions in tests:

async function realFlush(delay?: number) {
  clock.flush();
  await new Promise<void>(resolve => void setTimeout(resolve, delay));
  clock.flush();
}

Tests also become littered with hard-coded wait times, sometimes with purpose, but often somewhat arbitrary, such as mockClock.tick(1000) or mockClock.flushPendingTimers. Not only do these ticks and flushes often lack clear justification, but they also may need to be adjusted as the codebase evolves. Adjusting a timer in the production code can cause tests to fail, including many which were not intended to depend on or observe the specific timing implementation. In many ways, mock clocks can turn these sections of the tests into change detector tests.

Finally, some test utilities take it upon themselves to tick the mock clock, potentially interfering with the test’s intended timing and causing unexpected behavior. On the flipside, asynchronous test helpers and harnesses need to be informed about any installed mock clocks and how to advance them. Forgetting to provide this (assuming the testing APIs even have an option to do so, and many do not) will cause the test helper to stall, waiting for time that never advances.

Proposal: Allow mock clocks to automatically advance time

In the majority of use cases, mock clocks are used to speed up time. In order to do this, testers are opting into behavior that also stops time. We suspect that the majority of tests don’t want or need this. Clocks don’t stop in real life so it would make sense for mock clocks to advance on their own as well, unless there is a specific desire to pause it.

If mock clocks were able to advance time in a realistic way then we could realize a future where: No one should care whether time is being faked (unless they want to).

This includes business logic, test helpers, and even most tests themselves. It would be easy to migrate to a mock clock implementation with this property. That is, it would be ideal to be able to take a test that is written against real timer APIs and install a mock clock with no other changes to the tests. Auto-advance gets us pretty close.

Use cases

Tests with mock clocks would look identical to those without. Let’s go through some examples:

Testing async functions

When testing async functions, tests only need to enable auto advancing:

// methods_under_test.ts
export async function blackBoxWithLotsOfAsyncStuff() {
  // do some work
  await new Promise(r => void setTimeout(r, 10));
  // do some more work
  await new Promise(r => void setTimeout(r, 20));
  await Promise.resolve();
  // yay, we're done!
  return 'done';
}
// methods_under_test.spec.ts
// …
beforeEach(() => clock.setTickMode('auto'));
it('is easy to test async functions with interleaved timers and microtasks', async () => {
  const result = await blackBoxWithLotsOfAsyncStuff();
  expect(result).toBe('done');
});
// …

Waiting for conditions to be satisfied

The specific timeframe that conditions occur is usually best thought of as an “implementation detail”, rather than part of the public API commitments. It’s fairly easy to imagine changes in the future that alter the timeframe, and which are completely invisible to the user (and the test!).

For example, changing a debounce time on an instant search input from 100ms to 200ms. Tests which use mock clocks today would typically trigger the input, explicitly tick (100 or 200ms), and then make assertions. Instead, tests would use a polling API to explicitly wait for a condition to be satisfied as a result of the input changing, such as the Testing Library’s async methods:

beforeEach(() => clock.setTickMode('auto'));
it('gets results when the search changes', () => {
  const input = screen.getByLabelText('search-input');
  fireEvent.change(input, {target: {value: 'signals'}});
  await waitFor(() => expect(mockAPI).toHaveBeenCalledTimes(1));
  await screen.findByText('Computed signals');
  fireEvent.change(input, {target: {value: 'control flow'}});
  await screen.findByText('Control Flow in Components - @if');
});

What’s next

We started working with test framework authors to support automatically advancing time in mock clock implementations. As of Jasmine v5.7, the clock now has the ability to advance automatically and can be enabled with Clock#autoTick. It is also released in @sinonjs/fake-timers version 15, which is used by Jest and Vitest.

// jasmine v5.7
jasmine.clock().install().autoTick();

// @sinonjs/fake-timers v15
const clock = FakeTimers.install();
clock.setTickMode({mode: 'nextAsync'});

// future Jest release
jest.useFakeTimers().setTimerTickMode({mode: 'nextAsync'});

Follow us on social media for updates. We hope that this feature is as exciting to the community as it is to us. An automatically advancing mock clock could help existing async tests be faster and more predictable, regardless of what web framework is being used, since this feature doesn’t require any other changes to the test after it’s enabled.

Handling Time and Mock Clocks in Tests was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a user navigates from one route to another, the Angular Router maps the URL path to the relevant component and displays its view. Animating this route transition can greatly enhance the user experience. In version 17, the Router now has support for the View Transitions API when navigating between routes in Chrome/Chromium browsers.

How View Transitions work

The native browser method that’s used for view transitions is document.startViewTransition. When startViewTransition() is called, the browser captures the current state of the page which includes taking a screenshot. The method takes a callback that updates the DOM and this function can be asynchronous. The new state is captured and the transition begins in the next animation frame when the promise returned by the callback resolves.

Here’s an example of the startViewTransition api:

document.startViewTransition(async () => {
  await updateTheDOMSomehow();
});

If you’re curious to read more about the details of the browser API, the Chrome Explainer is an invaluable resource.

How the Router uses view transitions

Several things happen after navigation starts in the router: route matching, loading lazy routes and components, executing guards and resolvers to name a few. Once these have completed successfully, the new routes are ready to be activated. This route activation is the DOM update that we want to perform as part of the view transition.

When the view transition feature is enabled, navigation “pauses” and a call is made to the browser’s startViewTransition method. Once the startViewTransition callback executes (this happens asynchronously, as outlined in the spec here), navigation “resumes”. The remaining steps for the router navigation include updating the browser URL and activating or deactivating the matched routes (the DOM update).

Finally, the callback passed to startViewTransition returns a Promise that resolves once Angular has finished rendering. As described above, this indicates to the browser that the new DOM state should be captured and the transition should begin.

View transitions are a progressive enhancement. If the browser does not support the API, the Router will perform the DOM updates without calling startViewTransition and the navigation will not be animated.

Enabling view transitions in the router

To enable this feature add withViewTransitions to the provideRouter function:

bootstrapApplication(MyApp, {providers: [
  provideRouter(routes, withViewTransitions()),
]});

Try the “count” example on StackBlitz

This example uses the counter application from the Chrome explainer and replaces the direct call to startViewTransition when the counter increments with a router navigation.

Using CSS to customize transitions

View transitions can be customized with CSS. We can also instruct the browser to create separate elements for the transition by setting a view-transition-name. We can expand the first example by adding view-transition-name: count to the .count style in the Counter component. Then, in the global styles, we can define a custom animation for this view transition:

/* Custom transition */
@keyframes rotate-out {
 to {
   transform: rotate(90deg);
 }
}
@keyframes rotate-in {
 from {
   transform: rotate(-90deg);
 }
}
::view-transition-old(count),
::view-transition-new(count) {
 animation-duration: 200ms;
 animation-name: -ua-view-transition-fade-in, rotate-in;
}
::view-transition-old(count) {
 animation-name: -ua-view-transition-fade-out, rotate-out;
}

It is important that the view transition animations are defined in a global style file. They cannot be defined in the component styles because the default view encapsulation will scope the styles to the component.

Try the updated “count” example on StackBlitz

Controlling transitions with onViewTransitionCreated

The withViewTransitions router feature can also be called with an options object that includes an onViewTransitionCreated callback. This callback is run in an injection context and receives a ViewTransitionInfo object that includes the ViewTransition returned from startViewTransition, as well as the ActivatedRouteSnapshot that the navigation is transitioning from and the new one that it is transitioning to.

This callback can be used for any number of customizations. For example, you might want to skip transitions under certain conditions. We use this on the new angular.dev docs site:

withViewTransitions({
 onViewTransitionCreated: ({transition}) => {
   const router = inject(Router);
   const targetUrl = router.getCurrentNavigation()!.finalUrl!;
   // Skip the transition if the only thing 
   // changing is the fragment and queryParams
   const config = { 
     paths: 'exact', 
     matrixParams: 'exact',
     fragment: 'ignored',
     queryParams: 'ignored',
   };

   if (router.isActive(targetUrl, config)) {
     transition.skipTransition();
   }
 },
}),

In this code snippet, we create a UrlTree from the ActivatedRouteSnapshot the navigation is going to. We then check with the Router to see if this UrlTree is already active, ignoring any differences in the fragment or query parameters. If it is already active, we call skipTransition which will skip the animation portion of the view transition. This is the case when clicking on an anchor link that will only scroll to another location in the same document.

Examples from the Chrome explainer adapted to Angular

We’ve recreated some of the great examples from the Chrome Team in Angular for you to explore.

Transitioning elements don’t need to be the same DOM element

• Chrome Explainer
• Angular Example on StackBlitz

Custom entry and exit animations

• Chrome Explainer
• Angular Example on StackBlitz

Async DOM updates and waiting for content

• Chrome Explainer

During this time, the page is frozen, so delays here should be kept to a minimum…in some cases it’s better to avoid the delay altogether, and use the content you already have.

The view transition feature in the Angular router does not provide a way to delay the animation. For the moment, our stance is that it’s always better to use the content you have rather than making the page non-interactive for any additional amount of time.

Handle multiple view transition styles with view transition types

• Chrome Explainer
• Angular Example on StackBlitz

Handle multiple view transition styles with a class name on the view transition root (deprecated)

• Chrome Explainer
• Angular Example on StackBlitz

Transitioning without freezing other animations

• Chrome Explainer
• Angular Example on StackBlitz

Animating with Javascript

• Chrome Explainer
• Angular Example on StackBlitz

Try out this experimental feature today!

While Angular’s support for the View Transitions API is still experimental, we’re excited for the possibilities it creates to build the next generation of web experiences for users. The team will continue working to stabilize support and you can help. Try out this feature and leave feedback on GitHub. We’ve included multiple examples for you to try out and have fun with. If you implement something cool, tag us on X and show us the cool things you create.

Until the next time thanks for being a part of the Angular community and keep building.

Check out Angular’s support for the View Transitions API was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Prior advice

Conventional wisdom might suggest that test authors should stub external dependencies like ActivatedRoute or RouterLink and spy on services and service methods like navigateByUrl. A defense for this testing strategy might be

“Relying on the real router would make them brittle. They could fail for reasons unrelated to the component.”

This isn’t entirely true, but for now we will point out one very important detail in this defense that’s often ignored. Per the documentation:

“A different battery of tests can explore whether the application navigates as expected in the presence of conditions that influence guards such as whether the user is authenticated and authorized.”

It’s important that there still exists a suite of tests that do cover the resulting behavior of executing the real code of the dependency. Unfortunately, this is most often not done. It creates a burden on developers to maintain additional suites of tests when the unit tests being written with mocks could easily cover these behaviors as well. APIs change over time, so writing and maintaining a complete set of mocks and stubs for all the dependencies is often much more difficult and brittle than just using the real ones.

Boilerplate to test with real Router instances

Testing components and services that depend on the Angular Router can be difficult. For example, a component might inject ActivatedRoute and only use it to access the Observable for queryParams. Getting the Router to create a real instance of ActivatedRoute for the test would require quite a bit of boilerplate. For example:

1. Write a Route for the component under test ( {path: ‘**', component: MyComponent} )
2. Add the Router to TestBed ( TestBed.configureTestingModule)
3. Create a wrapper component with a router-outlet to render the component
4. Create the test ComponentFixture for the wrapper component instead of MyComponent
5. Tell the Router to navigate to the Route with the MyComponent
6. Use the wrapper ComponentFixture to query for MyComponent

It’s not until step 6 that you finally have your component you can use to do test assertions. With all of this complicated boilerplate, it makes sense that test authors might want to create a shortcut and share a test stub for ActivatedRoute and override the injectable in TestBed.

RouterTestingHarness to help

The RouterTestingHarness was released in Angular 15.2 to streamline tests for components and services that depend on the Router.

// Provide the router with your test route
TestBed.configureTestingModule({
  providers: [
    provideRouter([{path: '', component: TestCmp}])
  ],
});
// Create the testing harness
const harness = await RouterTestingHarness.create();
// Navigate to the route to get your component
const activatedComponent = await harness.navigateByUrl('/', TestCmp);

Notice how little boilerplate there is now. There’s no need to define a wrapper component yourself, no creation of the wrapper fixture, and no manual query for your test component. All of this is done behind the scenes in the harness.

Let’s cover a test scenario and compare the mock/stub and spy approach to what the test looks like with new RouterTestingHarness.

Mock ActivatedRoute for accessing query parameters

Let’s test a simple component that displays the value of a query parameter named search and provides a method for having the router update that parameter:

@Component({
  standalone: true,
  imports: [AsyncPipe],
  template: `search: {{(route.queryParams | async)?.search}}`
})
class SearchCmp {
  constructor(readonly route: ActivatedRoute, readonly router: Router) {}
  searchFor(searchText: string) {
    return this.router.navigate([], {queryParams: {'search': searchText}});
  }
}

Now we write a test that ensures the template updates with the current value of the parameter. First, we need to create our stubs:

const activatedRouteStub = {queryParams: new BehaviorSubject<any>({})};
const routerStub = jasmine.createSpyObj('router', ['navigate']);
routerStub.navigate.and.callFake(
  (commands, navigationExtras) =>
    activatedRouteStub.queryParams.next(navigationExtras.queryParams));

Next, we set up the testing module and create our component:

TestBed.configureTestingModule({
  imports: [SearchCmp],
  providers: [
    {provide: Router, useValue: routerStub},
    {provide: ActivatedRoute, useValue: activatedRouteStub},
  ]
});
const fixture = TestBed.createComponent(SearchCmp);

Finally, let’s write a quick test to ensure the template updates with the current search query parameter:

await fixture.componentInstance.searchFor('books');
fixture.detectChanges();
expect(fixture.nativeElement.innerHTML).toContain('search: books');

Problems

• If there’s a RouterLink on the page, the RouterLink creates a url from the stub. Stubs are frequently not set up to fully satisfy the interface. Refactors in the Router/RouterLink can cause the test to break if they access new properties that are supposed to exist but don’t on the stub.
• Refactoring the component to access other properties of ActivatedRoute would break the test even though the component code is not broken.
• Refactoring the component to get the parameters in a new way would break the test even though the component code is not wrong.

Recall the argument from earlier:

“Relying on the real router would make them brittle.”

In fact, these tests are more brittle because they rely on implementation details of the component. There’s a good argument that these tests are actually harmful change detector tests. Refactors in the component implementation that do not affect the end behavior or rendered template but cause the tests to fail arguably indicate you have change detector tests.

In addition, if the Router behavior changes in a way that changes the outcome of the component’s interactions with the Router API, you would want the test to fail. If it doesn’t fail, the tests don’t catch the difference in behavior, and this can cause a production bug.

Using RouterTestingHarness instead

We’ll take this same example and convert it to use the new RouterTestingHarness. First, configure the testing module to provide the Router with a route using the SearchCmp:

TestBed.configureTestingModule({
  providers: [
    provideRouter([{path: '**', component: SearchCmp}])
  ],
});

Next, use the harness to get the component instance:

const harness = await RouterTestingHarness.create();
const activatedComponent = await harness.navigateByUrl('/', SearchCmp);

Finally, we make the updates and assertions as before:

await activatedComponent.searchFor(‘books’);
harness.detectChanges();
expect(harness.routeNativeElement?.innerHTML).toContain('search: books');

We have at least a couple of nice outcomes when writing the test this way:

• We don’t have to write or maintain any test stubs or override providers. The Router executes and we don’t have to worry about rewriting stubs to behave similarly.
• As an example, we could refactor the component to use matrix parameters instead and do not need to update any test stubs.

Wrap up

Using the RouterTestingHarness rather than mocking or stubbing Router dependencies will make tests more reliable. The example above only outlines one scenario, but there are many more examples where a mock or stub would make tests more brittle and/or hide actual production issues in the application due to upstream Router changes.

Write better tests without Router mocks/stubs was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Angular team has been busy making some meaningful updates to the Angular router that are available as of Angular v14.2. We’re pleased to share some recent improvements. Read on to learn more.

New Router API for standalone

We’ve introduced a way to use the Router without the need for RouterModule and improved tree shaking for reduced bundle sizes. First, let’s focus on the new router integration API.

Here’s how to use the router without a RouterModule. In the bootstrapApplication function, we provide the router configuration to the providers array using the provideRouter function. The function accepts an array of application routes. Here’s an example:

// Bootstrap the main application component with routing capabilities

const appRoutes: Routes = […];
bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(appRoutes),
  ]
});

Compare this to the existing way to set up the Router in an application that required a module:

const appRoutes: Routes = […];

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom(RouterModule.forRoot(appRoutes)),
  ]
});

Tree shaking

The new provideRouter API allows developers to tree-shake major pieces of the router API. This is the first time we’ve had the ability to enable this level of tree-shaking in the Angular router. Now teams can enjoy smaller bundle sizes.

The design of the RouteModule API prevents bundlers from being able to remove unused Router features. With the RouteModule API the following features are included in the production bundle even if not enabled:

• HashLocationStrategy — generally used for legacy routing via updating the fragment instead of the path
• preloading, scrolling, and logic for blocking app loading until navigation finishes for SSR.

The new provideRouter API changes this behavior. The features in the list above are no longer included in the production bundle if they are not enabled.

In our testing with the new API, we found that removing these unused features from the bundle resulted in an 11% reduction in the size of the router code in the application bundle when no features are enabled.

Here’s an example of opting in to preloading using the withPreloading function :

const appRoutes: Routes = [];

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(appRoutes, withPreloading(PreloadAllModules))
  ]
});

Now supporting functional router guards

Router guards require too much boilerplate…
- most Angular developers at some point, probably

We’ve received feedback from multiple developers that amounts to developers wanting less boilerplate and more productivity. Let’s cover some of the exciting new changes that move us closer to this goal.

Functional router guards with inject() are lightweight, ergonomic, and more composable than class-based guards.

Here’s an example of functional guard that takes a component as a parameter and returns whether or not a route can be deactivated based on the component’s hasUnsavedChanges property:

const route = {
  path: ‘edit’,
  component: EditCmp,
  canDeactivate: [
    (component: EditCmp) => !component.hasUnsavedChanges
  ]
};

Additionally, these functional guards can still inject dependencies with inject from @angular/core :

const route = {
  path: ‘admin’,
  canActivate: [() => inject(LoginService).isLoggedIn()]
};

The Router APIs previously required guards and resolvers to be present in Angular’s dependency injection. This resulted in unnecessary boilerplate code. Let’s consider two examples.

In the first example, here’s the code required to provide a guard using an InjectionToken:

const UNSAVED_CHANGES_GUARD = new InjectionToken<any>('my_guard', {
  providedIn: 'root',
  factory: () => (component: EditCmp) => !component.hasUnsavedChanges
});

const route = {
  path: 'edit',
  component: EditCmp,
  canDeactivate: [UNSAVED_CHANGES_GUARD]
};

In this second example, here’s the code required for providing a guards as an injectable class:

@Injectable({providedIn: 'root'})
export class LoggedInGuard implements CanActivate {
  constructor(private loginService: LoginService) {}

  canActivate() {
    return this.loginService.isLoggedIn();
  }
}

const route = {
  path: 'admin',
  canActivate: [LoggedInGuard]
};

Notice that even when we want to write a simple guard that has no dependencies as in the first example, we still have to write either an InjectionToken or an Injectable class. With functional guards developers can create guards, even guards with dependencies, with much less boilerplate.

Functional guards are composable

Functional guards are also more composable. A common feature request for the Router is to provide the option for guards to execute sequentially rather than all at once. Without this option in the Router implementing this type of behavior in an application would be difficult. This is smoother to implement with functional guards. There’s even an example test in the router code to demonstrate this behavior.

Let’s review the code to get a better understanding of how this works:

function runSerially(guards: CanActivateFn[]|
                             CanActivateChildFn[]): 
                             CanActivateFn|CanActivateChildFn {
  return (
          route: ActivatedRouteSnapshot, 
          state: RouterStateSnapshot) => {
            const injector = inject(EnvironmentInjector);
            const observables = guards.map(guard => {
              const guardResult = injector.runInContext(
                () => guard(route, state));
              return wrapIntoObservable(guardResult).pipe(first());
            });

            return concat(…observables).pipe(
                     takeWhile(v => v === true), last());
            };
}

With functional guards, you can create factory-like functions that accept a configuration and return a guard or resolver function. With this pattern, we now also have configurable guards and resolvers, another common feature request. The runSerially function is a factory-like function that accepts a list of guard functions and returns a new guard.

function runSerially(guards: CanActivateFn[]|CanActivateChildFn[]): CanActivateFn|CanActivateChildFn

First, we obtain a reference to the current injector with:

const injector = inject(EnvironmentInjector);

When functional guards want to use dependency injection (DI), they must call inject synchronously. Each guard may execute asynchronously and may inject dependencies of their own. We need the reference to the current injector immediately so we can keep running each of them inside the same injection context:

const guardResult = injector.runInContext(() => guard(route, state));

This is also exactly how the router enables the function guards feature.

Because guards can return an Observable, a Promise, or a synchronous result, we use our wrapIntoObservable helper to transform all results to an Observable and take only the first emitted value:

return wrapIntoObservable(guardResult).pipe(first());

We take all of these updated guard functions, execute them one after another (with concat) and only subscribe to the result while each of them indicate the route can be activated (i.e, returning true):

concat(…observables).pipe(takeWhile(v => v === true), last());

That’s it. We enabled running functional guards sequentially with less than 10 lines of code. We can now call it in our `Route` config like this:

{
  path: ‘hello-world’,
  component: HelloWorld,
  canActivate: [runSerially(guard1, guard2, guard3)]
}

More to Come

All of these changes are available as of Angular v14.2. We hope that you enjoy these updates to the router and we would love to hear what you think. You can find us online.

Thank you for continuing to be a part of the Angular community.

Advancements in the Angular Router was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.