{"id":33917,"date":"2026-06-03T21:29:57","date_gmt":"2026-06-03T19:29:57","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=33917"},"modified":"2026-06-03T22:49:54","modified_gmt":"2026-06-03T20:49:54","slug":"angular-22-the-most-important-new-features-at-a-glance","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/angular-22-the-most-important-new-features-at-a-glance\/","title":{"rendered":"Angular 22: The Most Important New Features at a Glance"},"content":{"rendered":"

With Angular 22, several central Signal APIs leave their experimental status: the Resource API<\/strong> and Signal Forms<\/strong> are now stable and ready for production use. In parallel, OnPush<\/code> becomes the new default change detection strategy<\/strong>, and the framework gains more ergonomic building blocks for modern, reactive applications with @Service<\/code>, injectAsync<\/code>, and debounced<\/code>.<\/p>\n

This article highlights the most important innovations in Angular 22 using concrete examples and also picks up selected highlights from Angular 21.1 and 21.2.<\/p>\n

\ud83d\udcc2 Source Code<\/a> (Branch ng22<\/em>)<\/p>\n

OnPush as the New Default Change Detection Strategy<\/h2>\n

A decision that has been discussed in the Angular community since the very beginning is now reality: OnPush<\/code> is the new default change detection strategy. This shift makes perfect sense with the rise of Signals and Zone-less Angular: anyone using Signals receives precise notifications about changes, and OnPush<\/code> takes optimal advantage of them. The result is a performant change detection that focuses specifically on the components affected by changes.<\/p>\n

If you need the previous behavior, set the strategy manually to Eager<\/code>:<\/p>\n

import { ChangeDetectionStrategy, Component } from '@angular\/core';\n\n@Component({\n  selector: 'app-legacy',\n  changeDetection: ChangeDetectionStrategy.Eager,\n  template: `...`\n})\nexport class LegacyCmp { [...] }<\/code><\/pre>\n
The Eager<\/code> setting replaces the original Default<\/code> setting, which is now deprecated. In this case, change detection checks the entire component tree for changes.<\/p>\n
To avoid breaking changes, ng update<\/code> activates the Eager<\/code> option when updating the Angular version if OnPush<\/code> was not explicitly set.<\/p>\n
Resource API Becomes Stable in Angular 22<\/h2>\n
The Resource API has so far been the missing link in the Signal ecosystem: it enables reactive, asynchronous derivation of data, typically HTTP requests that are triggered after Signal changes. Despite its central role, it remained in experimental status for a long time. That changes abruptly with Angular 22: resource<\/code>, rxResource<\/code>, and httpResource<\/code> are now stable and can be safely used in production.<\/p>\n
The most convenient entry point is the httpResource<\/code> function. It receives a lambda expression that returns an HTTP request. This expression is reactive: if a Signal used within it changes, the request is automatically restarted.<\/p>\n
import { httpResource } from '@angular\/common\/http';\nimport { ChangeDetectionStrategy, Component, signal } from '@angular\/core';\nimport { Flight } from '..\/..\/data\/flight';\n\n@Component({\n  selector: 'app-flight-search',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  [...]\n})\nexport class FlightSearch {\n  protected readonly filter = signal({ from: 'Hamburg', to: 'Graz' });\n\n  protected readonly flightsResource = httpResource<Flight[]>(\n    () => ({\n      url: 'https:\/\/demo.angulararchitects.io\/api\/flight',\n      params: {\n        from: this.filter().from,\n        to: this.filter().to,\n      },\n    }),\n    { defaultValue: [] },\n  );\n\n  protected readonly flights = this.flightsResource.value;\n  protected readonly error = this.flightsResource.error;\n  protected readonly isLoading = this.flightsResource.isLoading;\n\n  protected search(): void {\n    this.flightsResource.reload();\n  }\n}<\/code><\/pre>\n
The type parameter Flight[]<\/code> defines the expected response type. The defaultValue<\/code> argument ensures that the component is not confronted with undefined<\/code> at startup. If the resource should not trigger a request, it is sufficient to return undefined<\/code>:<\/p>\n
protected readonly flightsResource = httpResource<Flight[]>(\n  () => {\n    const filter = this.filter();\n    if (!filter.from || !filter.to) {\n      return undefined;\n    }\n    return {\n      url: 'https:\/\/demo.angulararchitects.io\/api\/flight',\n      params: { from: filter.from, to: filter.to },\n    };\n  },\n  { defaultValue: [] },\n);<\/code><\/pre>\n
The resource manages its state via Signals: value<\/code> contains the loaded data, error<\/code> provides error information, and isLoading<\/code> indicates the loading state. In addition, the resource knows a more detailed status<\/code> with the values idle<\/code>, loading<\/code>, reloading<\/code>, error<\/code>, resolved<\/code>, and local<\/code> (for locally overridden values).<\/p>\n
In the template, these signals can be used directly, for instance to display the loading state and to iterate over the loaded data:<\/p>\n
@if (flightsResource.isLoading()) {\n  <div>Loading ...<\/div>\n}\n\n@if (flightsResource.error()) {\n  <div>Error: {{ flightsResource.error() }}<\/div>\n} @else {\n  <div class="row">\n    @for (flight of flightsResource.value(); track flight.id) {\n      <app-flight-card [item]="flight" \/>\n    }\n  <\/div>\n}<\/code><\/pre>\n
Race conditions are handled automatically: if multiple requests arrive in quick succession, only the result of the most recent one is used and older ones are cancelled where still possible. This matches the behavior of switchMap<\/code> in RxJS.<\/p>\n
Incremental Hydration Now Enabled by Default<\/h2>\n
With Angular 22, provideClientHydration()<\/code> enables Incremental Hydration automatically. If you don't need it, you disable it explicitly with the new withNoIncrementalHydration()<\/code> feature. A bundled schematic migration helps with the update.<\/p>\n
Signal Forms Becomes Stable and Production-Ready<\/h2>\n
Signal Forms can now also be used in production. The path from the experimental API to the stable version was remarkably fast. This was made possible through extensive internal case studies at Google, in which typical form applications were systematically examined.<\/p>\n
The heart of Signal Forms is the form<\/code> function. It receives a Signal containing the form data as well as an optional schema with validation rules:<\/p>\n
import { linkedSignal } from '@angular\/core';\nimport { form, minLength, required } from '@angular\/forms\/signals';\n\n@Component({ [...] })\nexport class FlightEdit {\n  private readonly store = inject(FlightDetailStore);\n\n  protected readonly flight = linkedSignal(() =>\n    normalizeFlight(this.store.flight()),\n  );\n\n  protected readonly flightForm = form(this.flight, (path) => {\n    required(path.from);\n    required(path.to);\n    required(path.date);\n    minLength(path.from, 3);\n  });\n}<\/code><\/pre>\n
The result is a FieldTree<\/code>: a deeply nested Signal structure in which each property is represented as a Signal with form status (value<\/code>, dirty<\/code>, invalid<\/code>, errors<\/code>). For template binding, the FormField<\/code> directive is used:<\/p>\n
<input [formField]="flightForm.from" id="flight-from" \/>\n<div>{{ flightForm.from().errors() | json }}<\/div><\/code><\/pre>\n
New @Service<\/code> Decorator: Register Services More Concisely<\/h2>\n
A striking new addition is the new @Service<\/code> decorator. It replaces the common cases in which you previously wrote @Injectable()<\/code> or @Injectable({ providedIn: 'root' })<\/code>, and is a better match for the actual intent of providing a service:<\/p>\n
import { Service } from '@angular\/core';\n\n@Service()\nexport class FlightClient { [...] }<\/code><\/pre>\n
By default, the service is provided in the root scope. If you don't want that, you can provide the service manually instead, for example in app.config.ts<\/code>, at the component level, or at the route level. In this case, you set autoProvided<\/code> to false<\/code>:<\/p>\n
@Service({ autoProvided: false })\nexport class TabRegistry { [...] }<\/code><\/pre>\n
injectAsync<\/code>: Inject Services Lazily<\/h2>\n
With injectAsync<\/code>, dependencies can be injected lazily, that is, only when they are actually needed. This is especially useful for services that load extensive libraries and are only required upon a specific user action.<\/p>\n
import { injectAsync } from '@angular\/core';\n\n@Component({ [...] })\nexport class CheckinPage {\n  private readonly upgradeService = injectAsync(() =>\n    import('.\/upgrade-service').then((m) => m.UpgradeService),\n  );\n\n  protected async upgrade(): Promise<void> {\n    const flightNumber = this.checkinFormModel().ticketId;\n    const upgradeService = await this.upgradeService();\n    upgradeService.upgrade(flightNumber);\n  }\n}<\/code><\/pre>\n
The injectAsync<\/code> function receives a lambda expression that returns a Promise. The result is a function whose first call takes care of loading the service. The import of UpgradeService<\/code>, and thus the loading of the associated bundle, only happens on the first call to upgrade()<\/code>.<\/p>\n
For lazy loading to work, the injected service must be auto-provided, that is, either decorated with @Injectable({ providedIn: 'root' })<\/code> or with the new @Service()<\/code> decorator.<\/p>\n
Prefetching with injectAsync<\/code> and onIdle<\/code><\/h2>\n
Lazy loading inevitably means a delay on the first call. To avoid this, the bundle can be loaded in advance.<\/p>\n
For exactly this purpose, injectAsync<\/code> offers the prefetch<\/code> option: it points to a function that returns a Promise. As soon as the Promise resolves, Angular begins loading the service.<\/p>\n
This mechanism can be used together with the helper function onIdle<\/code>. It returns a Promise and resolves it as soon as the browser has nothing to do:<\/p>\n
import { injectAsync, onIdle } from '@angular\/core';\n\nprivate readonly upgradeService = injectAsync(\n  () => import('.\/upgrade-service').then((m) => m.UpgradeService),\n  { prefetch: onIdle },\n);<\/code><\/pre>\n
Internally, onIdle<\/code> delegates to requestIdleCallback<\/code><\/a> and falls back to setTimeout<\/code> if the browser doesn't support this API. If needed, a timeout can be configured after which prefetching will be triggered at the latest:<\/p>\n
injectAsync(\n  () => import('.\/upgrade-service').then((m) => m.UpgradeService),\n  { prefetch: () => onIdle({ timeout: 100 }) },\n);<\/code><\/pre>\n
If you want to adjust the behavior project-wide, you can swap out the underlying IdleService<\/code> via provideIdleServiceWith<\/code>, typically in app.config.ts<\/code>.<\/p>\n
Resource Composition via Snapshots<\/h2>\n
A fundamental principle of reactive programming is deriving values from one another. A Computed is created from one or more Signals and updates as soon as its sources change. With Resources, this kind of derivation was previously only possible indirectly: you could project their individual signals (value<\/code>, error<\/code>, isLoading<\/code>), but not the Resource as a whole. Since Angular 21.2, there is a dedicated concept for this: using so-called snapshots, a Resource can be fully transformed into a new Resource without touching the original loading logic.<\/p>\n
The starting point is the snapshot<\/code> signal of a Resource, which contains the complete current state including status and value. A snapshot therefore provides the entire state as an object with Signals. This object can be mapped to a new object with Signals derived from it. From this derived snapshot, resourceFromSnapshots<\/code> in turn builds a new Resource.<\/p>\n
For illustration, consider an example that filters the loaded data, for instance to display only luggage items above a certain minimum weight:<\/p>\n
import {\n  linkedSignal,\n  Resource,\n  resourceFromSnapshots,\n  ResourceSnapshot,\n  Signal,\n} from '@angular\/core';\n\nexport function withMinWeight(\n  input: Resource<Luggage[]>,\n  minWeight: Signal<number>,\n): Resource<Luggage[]> {\n  const derived = linkedSignal<\n    { snap: ResourceSnapshot<Luggage[]>; min: number },\n    ResourceSnapshot<Luggage[]>\n  >({\n    source: () => ({ snap: input.snapshot(), min: minWeight() }),\n    computation: ({ snap, min }) => {\n      if (snap.status === 'resolved') {\n        return { ...snap, value: snap.value.filter((item) => item.weight >= min) };\n      }\n      return snap;\n    },\n  });\n\n  return resourceFromSnapshots(derived);\n}<\/code><\/pre>\n
Via the computation<\/code> callback of the linkedSignal<\/code>, you decide how the new snapshot is composed from the source signals. If either the source resource or the minWeight<\/code> signal changes, the computation is automatically re-executed. The derived resource therefore always remains consistent with its inputs.<\/p>\n
The pattern can be used generically for arbitrary transformations. An interesting use case, which the Angular team also describes alongside snapshots, is to keep the most recently loaded value during reloading instead of displaying undefined<\/code>:<\/p>\n
export function withPreviousValue<T>(input: Resource<T>): Resource<T> {\n  const derived = linkedSignal<ResourceSnapshot<T>, ResourceSnapshot<T>>({\n    source: input.snapshot,\n    computation: (snap, previous) => {\n      if (snap.status === 'loading' && previous?.value?.status === 'resolved') {\n        return { ...snap, value: previous.value.value };\n      }\n      return snap;\n    },\n  });\n\n  return resourceFromSnapshots(derived);\n}<\/code><\/pre>\n
The previous<\/code> argument of the computation<\/code> callback contains the most recently produced snapshot of the derived resource. This way, the previous value can be selectively carried over into the new snapshot.<\/p>\n
debounced<\/code>: Debouncing for Signals and Resources<\/h2>\n
By nature, Signals know nothing of time: unlike Observables, they therefore have no concept of delay or throttling. This has so far made debouncing in pure Signal chains impossible, at least if you don't want to break this mental model.<\/p>\n
For forms, the Angular team has therefore built debouncing directly into Signal Forms, which covers a large part of the use cases. For everything beyond that, there is now the debounced<\/code> function.<\/p>\n
Unlike Signals, Resources are well aware of time. This is exactly where debounced<\/code> comes in. The function creates a Resource<\/code> whose value is updated with the specified delay. The status<\/code> of the resource indicates whether the value is still within the pending window:<\/p>\n
import { debounced } from '@angular\/core';\n\nconst filter = signal('');\nconst debouncedFilter = debounced(filter, 300); \/\/ 300ms\n\neffect(() => console.log(debouncedFilter.value()));<\/code><\/pre>\n
FormRoot<\/code> and Submission API in Signal Forms<\/h2>\n
Since Angular 21.2, the Submission API for Signal Forms has been available. It allows you to define the entire logic for submitting a form directly in the call to form<\/code>:<\/p>\n
import { FormRoot, submit } from '@angular\/forms\/signals';\n\n@Component({\n  imports: [ [...], FormRoot ],\n  [...]\n})\nexport class FlightEdit {\n  protected readonly flightForm = form(this.flight, flightSchema, {\n    submission: {\n      action: async (form) => this.save(form),\n      ignoreValidators: 'none',\n      onInvalid: (form) => this.reportValidationError(form),\n    },\n  });\n}<\/code><\/pre>\n
The action<\/code> property contains the asynchronous save logic and can return server-side validation errors as its return value, which Signal Forms then takes directly into the form state. The ignoreValidators<\/code> option controls whether failing or still pending validators block the submission (none<\/code> | pending<\/code> | all<\/code>). onInvalid<\/code> is called when validation prevents submission.<\/p>\n
In the template, the FieldTree<\/code>, which represents the entire form, is bound to the form<\/code> tag via the new FormRoot<\/code> directive. This directive takes care of three tasks: it suppresses the browser's default validation behavior (such as the native tooltips on required<\/code> fields), connects the action<\/code> from the submission configuration with the submit<\/code> event of the form, and prevents duplicate validation messages. To trigger the submit<\/code> event, an ordinary button<\/code> without an explicit type<\/code> attribute is sufficient. Within a form, it acts as a submit button by default:<\/p>\n
<form [formRoot]="flightForm">\n  [...]\n  <button>Save<\/button>\n<\/form><\/code><\/pre>\n
If additional submission actions are needed, e.g. for an approval workflow, the submit<\/code> helper function helps, which only executes the submission if the form is valid:<\/p>\n
import { submit } from '@angular\/forms\/signals';\n\nprotected async requestApproval(): Promise<void> {\n  await submit(this.flightForm, {\n    action: async (form) => {\n      await this.store.requestApproval(form().value());\n    },\n    ignoreValidators: 'none',\n    onInvalid: (form) => this.reportValidationError(form),\n  });\n}<\/code><\/pre>\n
The onInvalid<\/code> handler is also well suited for automatically setting focus to the first invalid input field after a failed validation. Signal Forms provides the focusBoundControl()<\/code> method for this:<\/p>\n
private reportValidationError(form: FieldTree<Flight>): void {\n  this.snackBar.open('Please correct the validation errors', 'OK');\n  const errors = form().errorSummary();\n  if (errors.length > 0) {\n    errors[0].fieldTree().focusBoundControl();\n  }\n}<\/code><\/pre>\n
NOTE<\/p>\n
Modern Angular<\/h3>\n<\/p>\n
\u2713 Already updated to Angular 22!<\/strong><\/p>\n
You'll find more on Signal Forms and modern Angular architecture in my new eBook Modern Angular. It covers Signals, architecture, testing, AI assistants, and practical solutions for modern business applications.<\/p>\n
\"Modern<\/a><\/p>\n
More about the book \u2192<\/a>\n<\/div>\n<\/p>\n
CSS Classes for Signal Forms<\/h2>\n
Since Angular 21.2, Signal Forms supports conditional CSS formatting, as you know it from Template-driven and Reactive Forms. Via provideSignalFormsConfig<\/code>, you first define a mapping of CSS class names to form status predicates:<\/p>\n
import { provideSignalFormsConfig } from '@angular\/forms\/signals';\n\nexport const appConfig: ApplicationConfig = {\n  providers: [\n    [...],\n    provideSignalFormsConfig({\n      classes: {\n        'ng-invalid': field => field.state().invalid(),\n        'ng-valid':   field => field.state().valid(),\n        'ng-dirty':   field => field.state().dirty(),\n        'ng-pristine': field => !field.state().dirty(),\n        'ng-pending': field => field.state().pending(),\n      }\n    }),\n  ],\n};<\/code><\/pre>\n
The corresponding CSS rules might then look like this, for example:<\/p>\n
input.ng-valid {\n  border-left: 3px solid darkseagreen;\n}\n\ninput.ng-invalid.ng-dirty {\n  border-left: 3px solid var(--color-error);\n}\n\ninput.ng-pending {\n  border-left: 3px solid var(--color-border);\n}<\/code><\/pre>\n
Signal Forms automatically applies the configured classes to the bound input fields:<\/p>\n
\"Input<\/p>\n
If you want to use exactly the same classes as with Reactive or Template-driven Forms, you can use the predefined configuration object NG_STATUS_CLASSES<\/code> from the compat namespace:<\/p>\n
import { NG_STATUS_CLASSES } from '@angular\/forms\/signals\/compat';\n\nprovideSignalFormsConfig({\n  classes: NG_STATUS_CLASSES\n}),<\/code><\/pre>\n
Interop of Signal Forms with Reactive Forms<\/h2>\n
Signal Forms integrates seamlessly with existing Reactive Forms. The bridge compatForm<\/code> from @angular\/forms\/signals\/compat<\/code> allows you to connect a Signal Form model with reactive form controls:<\/p>\n
import { compatForm, SignalFormControl } from '@angular\/forms\/signals\/compat';\n\n@Component({ [...] })\nexport class CheckinPage {\n  protected readonly address = new SignalFormControl(\n    this.addressFormModel(),\n    (path) => {\n      required(path.street);\n      required(path.zipCode);\n      required(path.country);\n    },\n  );\n\n  protected readonly checkinForm = compatForm(this.checkinFormModel, (path) => {\n    required(path.ticketId);\n  });\n}<\/code><\/pre>\n
SignalFormControl<\/code> behaves like a regular AbstractControl<\/code> and can be embedded directly into existing Reactive Forms structures. Conversely, Signal Forms also understands legacy form controls, CVA-based (Control Value Accessor) inputs, and classical validators. Signal Forms can therefore also work with existing legacy form controls. The interop bridge to CVA can be disabled per field if needed:<\/p>\n
<input ngNoCva [field]="myField"><\/code><\/pre>\n
validateStandardSchema<\/code> with Dynamic Rules<\/h2>\n
Standard Schema is a community-driven interface that validation libraries such as Zod<\/strong> and Valibot<\/strong> implement. Since Signal Forms ships with a function called validateStandardSchema<\/code> that directly understands this interface, schemas from all these libraries can be used for form validation without having to write a dedicated adapter.<\/p>\n
Since Angular 21.2, the schema can also adapt dynamically. Instead of a fixed schema object, you pass validateStandardSchema<\/code> a lambda expression that is internally converted into a computed<\/code>. If a Signal used within it changes, the Computed is automatically re-evaluated and the updated validation rules apply immediately:<\/p>\n
import { Signal } from '@angular\/core';\nimport { SchemaPathTree, validateStandardSchema } from '@angular\/forms\/signals';\nimport { z } from 'zod';\nimport { Flight } from '.\/flight';\n\nconst FlightZodSchema = z.object({\n  id: z.number().int(),\n  from: z.string().min(3).max(20),\n  to: z.string().min(3).max(20),\n  date: z.string(),\n  delayed: z.boolean(),\n});\n\nconst StrictFlightZodSchema = z.object({\n  id: z.number().int(),\n  from: z.string().min(10).max(30),\n  to: z.string().min(10).max(30),\n  [...]\n});\n\nexport function validateWithSchema(\n  path: SchemaPathTree<Flight>,\n  strict: Signal<boolean>,\n) {\n  validateStandardSchema(\n    path,\n    () => strict() ? StrictFlightZodSchema : FlightZodSchema,\n  );\n}<\/code><\/pre>\n
This allows, for example, context-dependent validation strategies. The form automatically switches between the lenient and the strict schema as soon as the strict<\/code> signal changes.<\/p>\n
disabled<\/code>, readonly<\/code>, and hidden<\/code> with the when<\/code> Property<\/h2>\n
Signal Forms knows the helper functions disabled<\/code>, readonly<\/code>, and hidden<\/code> to control input fields depending on the form state. The new feature: the condition is now passed via a when<\/code> property in the parameter object. This makes the API more consistent and makes it possible, in the error case, to also return an explanatory string instead of true<\/code>:<\/p>\n
import { disabled, hidden, readonly } from '@angular\/forms\/signals';\n\ndisabled(path.delay, {\n  when: (ctx) => (ctx.valueOf(path.delayed) ? false : 'not delayed'),\n});\n\nreadonly(path.delay, {\n  when: (ctx) => ctx.valueOf(path.delayed),\n});\n\nhidden(path.delay, {\n  when: (ctx) => ctx.valueOf(path.delayed),\n});<\/code><\/pre>\n
The ctx<\/code> parameter provides contextual access to other field values, so that complex, cross-field conditions can be expressed cleanly.<\/p>\n
Route Auto Cleanup for Environment Injectors<\/h2>\n
In Angular, services can also be configured at the route level, namely via the providers<\/code> property of a route configuration. So far, however, there has been a catch: services registered this way were not cleaned up when leaving the route, but continued to live until the application was closed. The reason lies in the historical behavior of the underlying Environment Injectors. They are the counterpart to those providers that were previously set up at the NgModule<\/code> level, and their original lifecycle behavior was to be preserved.<\/p>\n
Since Angular 21.1, this can be changed. With withExperimentalAutoCleanupInjectors<\/code>, the Environment Injectors of a route, including all service instances registered there, are automatically destroyed when leaving the route:<\/p>\n
import {\n  provideRouter,\n  withComponentInputBinding,\n  withExperimentalAutoCleanupInjectors,\n} from '@angular\/router';\n\nexport const appConfig: ApplicationConfig = {\n  providers: [\n    provideRouter(\n      routes,\n      withComponentInputBinding(),\n      withExperimentalAutoCleanupInjectors(),\n    ),\n    [...]\n  ],\n};<\/code><\/pre>\n
The feature remains experimental for the time being.<\/p>\n
Determining Active Routes with isActive<\/code> as a Signal<\/h2>\n
With isActive<\/code>, Angular 22 brings a new way to programmatically determine whether a route is active. The function returns a Signal and is automatically re-evaluated in the template as soon as the route state changes:<\/p>\n
import { isActive, Router } from '@angular\/router';\n\n@Component({ [...] })\nexport class BookingNavigation {\n  private readonly router = inject(Router);\n\n  protected readonly flightSearchActive = isActive(\n    '\/ticketing\/booking\/flight-search', this.router\n  );\n  protected readonly passengerSearchActive = isActive(\n    '\/ticketing\/booking\/passenger-search', this.router\n  );\n  protected readonly summaryActive = isActive(\n    '\/ticketing\/booking\/summary', this.router,\n    { paths: 'exact' }\n  );\n}<\/code><\/pre>\n
The optional third parameter accepts IsActiveMatchOptions<\/code> and controls how exact the comparison should be:<\/p>\n