{"id":35016,"date":"2026-09-28T17:45:57","date_gmt":"2026-09-28T15:45:57","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=35016"},"modified":"2026-09-28T17:50:59","modified_gmt":"2026-09-28T15:50:59","slug":"angular-22-2-error-boundaries-router-resources-and-more","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/angular-22-2-error-boundaries-router-resources-and-more\/","title":{"rendered":"Angular 22.2: Error Boundaries, Router Resources, and More"},"content":{"rendered":"

Angular 22.2 was released at the end of September 2026. Two additions stand out, both as developer previews: Error boundaries<\/strong> catch errors while rendering a section of a template and show a fallback view instead. Router Resources<\/strong> load route data with resources instead of resolvers, in parallel rather than one after another. This article shows both using our demo application Flights42 and then summarizes further interesting changes from the changelog.<\/p>\n

\ud83d\udcc2 Source code<\/a> (branch: 22.2<\/code>)<\/p>\n

Error Boundaries with @boundary<\/h2>\n

When a template threw an exception while rendering, there was no elegant way to limit its impact to one part of the page. The error ended up in the global ErrorHandler<\/code>, and the affected view remained incomplete. The new @boundary block lets you protect any section of a template: if an error occurs inside it during the initial render or a later change detection, Angular stops rendering that section and shows the associated @error block instead. The concept is inspired by error boundaries in React.<\/p>\n

Resources are a typical use case. If a resource's loader fails, its value()<\/code> throws the error as an exception. This behavior is intentional: if value()<\/code> silently returned an empty value in the error case, the error could easily go unnoticed. Until now, a template therefore had to check the error()<\/code> signal before accessing value()<\/code>. For the luggage detail page of the demo, that looked like this:<\/p>\n

@let resource = luggage();\n\n@if (resource.isLoading()) {\n  <p>Loading luggage \u2026<\/p>\n} @else if (resource.error()) {\n  <p>Luggage could not be loaded.<\/p>\n} @else {\n  @let item = resource.value();\n  <form> [...] <\/form>\n}<\/code><\/pre>\n
With Angular 22.2, a @boundary block takes over this job:<\/p>\n
<!-- [...]\/luggage\/feature-luggage\/luggage-detail\/luggage-detail.html -->\n\n@boundary {\n  @let resource = luggage();\n  @let item = resource.value();\n\n  @if (resource.isLoading()) {\n    <p>Loading luggage \u2026<\/p>\n  } @else {\n    <form> [...] <\/form>\n  }\n} @error {\n  <p>Luggage could not be loaded.<\/p>\n}\n\n<p class="mt-40">\n  <a routerLink="\/luggage">Back to overview<\/a>\n<\/p><\/code><\/pre>\n
The component receives the resource as an input from the router. More on that in a moment. The template now simply reads the value without checking the error state first. If value()<\/code> throws, the boundary catches the exception and renders the @error block. The link back to the overview is outside the boundary and therefore stays visible in any case. Navigating to the detail page in the demo with an invalid id, e.g. \/luggage\/9999<\/code>, makes the loader throw an error, and the page shows the message from the @error block.<\/p>\n
A boundary can span any part of the template and also protects the components used within it: if a child component throws while rendering or during change detection, the error also ends up in the closest enclosing boundary. Boundaries can be nested. Two points are worth noting: the boundary doesn't catch errors in projected content, that is, in <ng-content><\/code>, and errors inside the @error block itself propagate to the next outer boundary.<\/p>\n
Handling Caught Errors<\/h2>\n
The @error block provides the error via the implicit variable $error<\/code>, similar to $index<\/code> in @for. It can be renamed with let<\/code>, and when<\/code> allows several blocks for different kinds of errors. For the optimists, there is also the implicit function $reset<\/code>, which simply tries rendering once more:<\/p>\n
@boundary {\n  <app-chart \/>\n} @error (let err; retry = $reset; when isNetworkError(err)) {\n  <p>{{ err.message }}<\/p>\n  <button (click)="retry()">Retry<\/button>\n} @error {\n  <p>Something went wrong.<\/p>\n}<\/code><\/pre>\n
A caught error doesn't silently disappear into the fallback view. Angular additionally reports it to the ErrorHandler<\/code>, namely to its new optional method onViewError<\/code> if implemented, otherwise to handleError<\/code>. Without a custom ErrorHandler<\/code>, the error therefore still shows up in the console.<\/p>\n
Errors can also be caught when creating components and views dynamically: createComponent<\/code> and the corresponding methods of ViewContainerRef<\/code> accept an onError<\/code> callback. Besides the error, both onViewError<\/code> and onError<\/code> receive an ErrorDetails<\/code> object that names the affected component and, if present, the catching boundary along with its reset<\/code> function. Error boundaries ship in 22.2 as a developer preview.<\/p>\n
NOTE<\/p>\n
Modern Angular<\/h3>\n<\/p>\n
\u2713 Already updated to Angular 22!<\/strong><\/p>\n
You'll find more on resources, Signals, 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
Router Resources<\/h2>\n
Resolvers load data before a route is activated and return an Observable or Promise for it. In Angular's Signal world, that felt out of place. Router Resources now solve this and also bring a performance benefit: the router starts all resources of a navigation at the same time, whereas it processes resolvers one after another along the route hierarchy. If, for example, the parent route needs 2 seconds for its data and the child route 3, the user waits 5 seconds for the navigation with resolvers. With Router Resources, it takes only 3 seconds, as long as the slowest resource.<\/p>\n
The feature is enabled via withRouterResources<\/code>:<\/p>\n
\/\/ src\/app\/app.config.ts\n\nimport {\n  provideRouter,\n  withComponentInputBinding,\n  withRouterResources,\n} from '@angular\/router';\n\n[...]\n\nprovideRouter(routes, withComponentInputBinding(), withRouterResources()),<\/code><\/pre>\n
A route declares its data in the resources<\/code> property. The function runs in an injection context and receives a ResourceContext<\/code> with params<\/code>, queryParams<\/code>, fragment<\/code>, and data<\/code> as Signals. The route for editing a passenger loads the record before the component appears:<\/p>\n
\/\/ src\/app\/domains\/ticketing\/ticketing.routes.ts\n\n{\n  path: 'passenger-edit\/:id',\n  component: PassengerEdit,\n  resources: (ctx) => ({\n    passenger: createSimplePassengerResource(ctx.params),\n  }),\n},<\/code><\/pre>\n
The factory function derives the id from the parameters and creates an ordinary httpResource<\/code>:<\/p>\n
\/\/ [...]\/feature-booking\/passenger-edit\/simple-passenger-resource.ts\n\nexport function createSimplePassengerResource(params: Signal<Params>) {\n  const passengerClient = inject(PassengerClient);\n  const id = computed(() => Number(params()['id'] ?? 0));\n  return passengerClient.findPassengerResourceById(id);\n}<\/code><\/pre>\n
Such a resource is blocking<\/strong>: like with a resolver, the router waits until the value is available. Thanks to withComponentInputBinding<\/code>, the component receives the unwrapped value as an input, exactly as it did from the resolver before. In the prereleases of 22.2, a resource with a default value didn't block, because from the router's point of view a value was already present. The final release looks solely at the loading state. A default value is therefore no longer an obstacle.<\/p>\n
Non-Blocking Router Resources<\/h2>\n
Navigation shouldn't always wait. With nonBlocking<\/code>, the router activates the route immediately and hands the still-loading resource as a whole to the component. The luggage detail page from the first section uses exactly that:<\/p>\n
\/\/ src\/app\/domains\/luggage\/feature-luggage\/luggage.routes.ts\n\nimport { nonBlocking, Routes } from '@angular\/router';\n\n[...]\n\n{\n  path: ':id',\n  component: LuggageDetail,\n  resources: (ctx) => ({\n    luggage: nonBlocking(createLuggageResource(ctx.params)),\n  }),\n},<\/code><\/pre>\n
\/\/ [...]\/feature-luggage\/luggage-detail\/luggage-detail.ts\n\n@Component({ [...] })\nexport class LuggageDetail {\n  readonly luggage = input.required<Resource<Luggage>>();\n}<\/code><\/pre>\n
This makes isLoading<\/code>, error<\/code>, and value<\/code> available in the template, and the error boundary from the first section takes care of the error case.<\/p>\n
Router Resources can do more: via the ActivatedRoute<\/code>, a resource can be reloaded without a new navigation, and a RedirectCommand<\/code> thrown in the loader redirects to another route when data is missing. These details, as well as the interplay with Signal Stores, are covered in the article Router Resources: Loading Data with the Angular Router<\/a>.<\/p>\n
More at a Glance<\/h2>\n
Besides the two big new features, error boundaries and Router Resources, Angular 22.2 comes with numerous refinements. They touch the router, the compiler, testing, Signal Forms, and the CLI. The most interesting ones at a glance:<\/p>\n