DEV Community: Playful Programming Angular

Ng-News 26/22: TypeScript 7.1, Angular Native and Polymorpheus

ng-news — Thu, 15 Oct 2026 08:22:23 +0000

Angular’s compiler and TypeScript 7.1, plus Angular Native for mobile apps. Also: Polymorpheus for flexible UI components and upcoming Angular conferences.

Angular’s Compiler and TypeScript 7.1

Angular code is not directly compiled by TypeScript, but by an Angular compiler which sits on top of TypeScript.

TypeScript 7 is the current version and the first version which has been ported to Go. It promises up to 10 times faster compilation. Such a big change to TypeScript therefore also has a huge impact on the Angular compiler.

The Angular compiler uses TypeScript's programmatic API. It imports and uses it like a library. TypeScript 7.0, though, doesn't have a programmatic API, but it is compatible with TypeScript 6, which means we can continue using TypeScript 6's programmatic API. So far so good.

Angular imports TypeScript as a library and calls its programmatic API. Simplified version.

With TypeScript 7.1, a new programmatic API is expected to become available. Angular will need that one to run on 7.1.

Here's the problem. Angular's compiler is written in TypeScript but it now has to access a compiler which is written in Go. This means we have a language boundary. The new interop API will fix that, but it comes without the TypeScript transformer API, which Angular uses to rewrite our code.

That's why Angular will use another very popular tool, Oxc, which is written in Rust and already used by Vite and other widespread tools. Roughly summarized, Angular uses Oxc throughout its various steps to analyze our code and prepare compilation tasks. Angular has two major pipelines. One which prepares our code by transforming it to a final form, and another one where it runs the type-check on the templates. At both ends, we will benefit from the newly gained speed.

Simplified version of the two compiler paths, adapted from the episode animation.

At the time of this writing the PR has already been merged into main. So we might already get a version of it in the upcoming version 22.3 of Angular.

blog.angular.dev

Angular compiler PR

Angular Native

Developing native applications for mobile hasn't been the greatest joy for Angular developers. We have Ionic, but it uses a WebView as a middle layer to display web UI. NativeScript does render truly native UI for both Android and iOS. But we never had something like React Native with its production-proven Fabric renderer and an ecosystem like Expo, which supports the whole development lifecycle.

On 29 September, this changed. Angular Native was released by Ashley Hunter and has gained some traction in terms of contributors. It is an independent community project and is currently in alpha.

The great thing is that its native rendering isn't built from scratch but uses React Native under the hood. That is possible because React Native's Fabric rendering infrastructure can be driven without React. In a typical React Native app, React's reconciler determines the changes to the component tree and passes the rendering work to Fabric. Angular Native drives Fabric without React's component tree or reconciler.

Ashley Hunter made use of that separation and replaced Angular's renderer, which targets the DOM, with a native renderer that uses React Native's Fabric. Switching the renderer to a non-DOM target is not new. Chau Tran applies the same approach in Angular Three.

The framework layer changes; Fabric and the native UI layers remain. Simplified version.

For us, that means we build on a production-proven native renderer, which is well maintained, and on top we have Angular Native as a project that integrates Angular via its official renderer extension points. The integration itself, though, is still in alpha.

Since it is native and not DOM - again, Ionic uses a WebView - we also cannot just use existing components or UI libraries that depend on the browser. For native UI, we have to use the native ones. Familiar tags like div and p do work, but they are mapped to native views and text. There is an exception, though: dom-component lets us embed existing Angular web components, but then that part runs in a WebView. The logic, though, can stay as long as it doesn't depend on browser APIs.

Angular Native also went the extra mile and integrated Tailwind, the Angular router, hot reload, and a testing library. It supports the React Native build environment with the bundler Metro and Expo, which is somewhat like what Nx or Angular CLI is to Angular, but goes further with cloud builds, app-store submission, and updates. So Angular doesn't just run on top of React Native, it also unlocks access to its ecosystem of native modules and tooling. React components and hooks, though, don't just work in Angular.

ng-native.com

Polymorpheus

If you're designing a UI library for generic use, you have to support different use cases, and that can become complicated. For example, an input might start as a simple string. But then a caller needs a function which receives the context for that particular use. Or your users want to display full HTML instead - or even a whole component. Think of a tooltip, for example, where you might have a simple title. Then you use that tooltip inside a loop and need access to the current element, or you want certain formatting.

If you are the author of that tooltip, there's a lot of work that goes into that component to make it applicable to as many use cases as possible.

Alex Inkin is a lead developer behind Taiga UI, and those kinds of challenges are his bread and butter, so to speak. Alex has published an article on Angular Space where he discusses his library Polymorpheus, which is optimized exactly for these challenges, is used in Taiga UI, and can also be used by us.

Polymorpheus: a tiny tool you didn’t know you needed

Explore a little open-source library that supercharges dynamic content in Angular apps.

angularspace.com

Official Polymorpheus repository

Taiga UI

A powerful set of open source components for Angular

taiga-ui.dev

Upcoming conferences

NG Poland - 17 November 2026, Warsaw.

angularday - 20 November 2026, Verona.

Aingular TLV - 7 December 2026, Tel Aviv.

NG Switzerland - 11-12 February 2027, Lucerne area.

NG Baguette - 28 May 2027, Paris.

Ng-News 26/21: Angular 22.2: Router Resources, Error Boundaries, and Private Template Members

ng-news — Sat, 03 Oct 2026 17:04:33 +0000

Angular 22.2 introduces router resources and error boundaries, both in developer preview. We can also access TypeScript private members from a component's template.

The demo application used in this article is available at

Router Resources

Fetching data via the router is a feature which other frameworks have already had for many years. Angular already had resolvers, but it is nice that it now also supports this in the "Angular way", i.e. via the resource feature.

Modern Angular uses resources to load data asynchronously from the backend. Since creating a resource or using functions on top of it, like rxResource, starts loading immediately, we usually create the resource in a component, or the component gets it indirectly via an Angular service.

That also means that we need to provide the code to handle the state of a resource. For example, is it loading, has it been initialized, etc.?

The following example shows the component HolidaysPage, which gets the resource from a HolidayService:

holidays-page.ts

import { Component, inject } from '@angular/core';
import { HolidayCard } from './holiday-card';
import { HolidayService } from './holiday.service';
import { Title } from './title';

@Component({
  selector: 'app-holidays',
  imports: [HolidayCard, Title],
  template: `
    <app-title />
    @if (holidays.isLoading()) {
      <p>Loading holidays...</p>
    } @else if (holidays.error()) {
      <p>Could not load the holidays.</p>
    } @else if (holidays.hasValue()) {
      @for (holiday of holidays.value(); track holiday.id) {
        <app-holiday-card [holiday]="holiday" />
      }
    }
  `,
})
export class HolidaysPage {
  readonly holidays = inject(HolidayService).createHolidaysResource();
}

holiday.service.ts (resource factory)

createHolidaysResource() {
  return resource({
    loader: async () => {
      await new Promise((resolve) => setTimeout(resolve, 1200));
      return holidays;
    },
  });
}

The full service is available in StackBlitz.

Router resources are an elegant way to simplify that.

We can define a resource at the router level, where it fetches the data when the user navigates to that route. By default, it also blocks route activation, meaning the router only renders the component once the resource has successfully fetched its data. The component gets the fetched data via input binding, as if the data had been there all the time.

holidays-routes.ts

import { inject } from '@angular/core';
import { Routes } from '@angular/router';
import { HolidayService } from './holiday.service';
import { HolidaysPage } from './holidays-page';

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

holidays-page.ts

import { Component, input } from '@angular/core';
import { Holiday } from './holiday';
import { HolidayCard } from './holiday-card';
import { Title } from './title';

@Component({
  selector: 'app-holidays',
  imports: [HolidayCard, Title],
  template: `
    <app-title />
    @for (holiday of holidays(); track holiday.id) {
      <app-holiday-card [holiday]="holiday" />
    }
  `,
})
export class HolidaysPage {
  readonly holidays = input.required<Holiday[]>();
}

The holidays input matches the resource name in the route configuration. We also need to enable router resources and component input binding:

app.config.ts

import { ApplicationConfig } from '@angular/core';
import {
  provideRouter,
  withComponentInputBinding,
  withRouterResources,
} from '@angular/router';
import { routes } from './holidays-routes';

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

If multiple resources are defined across nested routes or for one specific route, their data loads in parallel, which also improves the loading time for the end user.

Router resources also have further options. They can, for example, be non-blocking, be created asynchronously, and much more. For more details, head to the official documentation.

Error Boundaries

Whenever an unhandled error is thrown during rendering or change detection, it can bubble up through the component hierarchy and interrupt rendering.

For obvious reasons, we can catch errors in TypeScript with try/catch so that we can isolate them.

For demonstration, our Title component throws an unhandled error. When it is used as a child component, it also causes problems for its parent view. In our case, the holiday cards would not be rendered, and HolidaysPage stays empty.

import { Component } from '@angular/core';

@Component({
  selector: 'app-title',
  template: '<h1>Holidays</h1>',
})
export class Title {
  constructor() {
    throw new Error('The title could not be created');
  }
}

holidays-page.ts (template)

<app-title />

@for (holiday of holidays(); track holiday.id) {
  <app-holiday-card [holiday]="holiday" />
}

Error boundaries bring the concept of a try/catch block from TypeScript to the template.

A @boundary template block wraps the risky template and isolates the error within it. Title will therefore cause no further havoc in the rest of the application.

The catch part would be @error, where we can provide a fallback template:

holidays-page.ts (template)

@boundary {
  <app-title />
} @error {
  <h1>Holidays</h1>
}

@for (holiday of holidays(); track holiday.id) {
  <app-holiday-card [holiday]="holiday" />
}

There are more options, including access to the error, resetting a boundary, and selecting a fallback conditionally. For this example, a static fallback is enough. In the companion demo, use Broken title to see that fallback while the holiday cards stay visible.

Error boundaries with @boundary • Angular

The web development framework for building modern apps.

angular.dev

Private Members in Templates

The third feature is a small change to the component class. We can now access TypeScript private members from its template:

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-private-title',
  template: '<h1>{{ title() }}</h1>',
})
export class PrivateTitle {
  private readonly title = signal('Holidays');
}

Before Angular 22.2, we would normally make a component member (property or method) used by the template public or protected. protected was the choice when the member was meant for the template rather than the component's public API, although subclasses could still access it.

Now private is also an option, and for members used only by the component and its template, it is the one I would recommend. From a conceptual perspective, the component's template and TypeScript class form one unit. Accessing a private member in the template underlines that perspective.

Angular team discussion: the component and its template form one unit

One distinction is important here. TypeScript's private modifier and ECMAScript # fields are different. A field that is private at runtime, like #title, cannot be accessed directly by the template. It still makes sense for state that should stay inside the class.

For the sake of consistency, future Angular code should therefore use TypeScript's private for members that the template needs to access.

protected, on the other hand, will likely disappear from template-only use or be used mainly for class inheritance.

Angular Addicts #53: NgRx 22, WebMCP, CopilotKit & more

Gergely Szerovay — Tue, 29 Sep 2026 07:19:56 +0000

👋Hey fellow Angular Addict

This is the 53rd issue of the Angular Addicts Newsletter, a monthly collection of carefully selected Angular resources that caught my attention. (Here are the 52nd, 51st and 50th)

📢 Release announcements

📢 Announcing NgRx v22: Resource Extensions, Dynamic Deep Signals, a Light Theme, and more!

By Marko Stanimirović

💎Angular Gems of August, 2026

👨‍💻About the author

My name is Gergely Szerovay, I worked as a data scientist and full-stack developer for many years, and I have been working as frontend tech lead, focusing on Angular based frontend development. As part of my role, I'm constantly following how Angular and the frontend development scene in general is evolving. To share my knowledge, I started the Angular Addicts monthly newsletter and publication in 2022, so that I can send you the best resources I come across each month. Whether you are a seasoned Angular Addict or a beginner, I got you covered. Let me know if you would like to be included as a writer. Let’s learn Angular together! Subscribe here 🔥

Follow me on Substack (Angular Addicts), Substack (AIBoosted.dev), Medium, Dev.to, Twitter or LinkedIn to learn more about Angular, and how to build AI apps with AI, Typescript, React and Angular!

🕹️Previous issues

If you missed the previous issues of the newsletter, you can read them here, these are the latest 3 issues:

📨 Submit your Angular resource

Have you found or written an interesting Angular-related article, tweet or other resource lately? Please let me know here in the comments or send me a DM on Twitter! I might feature it in the next Angular Addicts issue!

Route Resources in Angular: what the Router actually does with your Signal under the hood

Nicolas Frizzarin — Tue, 15 Sep 2026 06:24:17 +0000

Introduction

Route resolvers have been around in Angular for years, and they do their job, but they come with a price you pay on every navigation: they run one after the other, parent to child, and they can't be refreshed without triggering a full navigation. Angular now ships an alternative built directly on Signals, exposed through the router as a resources route property. The official guide covers the "how to use it" part pretty well: https://next.angular.dev/guide/routing/data-fetching-with-resources.

What the guide doesn't show you is what happens between the moment you write resource({...}) in your route config and the moment your component receives a value. There's an entire file dedicated to that, router_resource.ts.
This article is what I found in there (it's a depth technical article ): how blocking works, why your UI doesn't flash a loading skeleton when you navigate between two similar pages, and where a navigation cancellation can leave you stuck if you don't understand the reload guard.

I'll assume you already know what a resource() is (a value(), an isLoading(), an error(), a status(), and a reload(), all as signals). If not, go read the Resource API guide first, this article builds on top of it.

Turning it on

Route resources are gated behind a feature you have to opt into, withRouterResources():

import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter, withComponentInputBinding, withRouterResources } from '@angular/router';
import { routes } from './app.routes';
import { App } from './app';

bootstrapApplication(App, {
  providers: [
    provideRouter(routes, withComponentInputBinding(), withRouterResources()),
  ],
});

Notice withComponentInputBinding() next to it. It's not mandatory to make resources work, but without it you'll have to reach into ActivatedRoute.resources manually instead of getting your data as a plain component input(). In practice you'll almost always want both together.

Defining resources on a route

A route now accepts a resources property, a function returning a map of Resource instances:

import { inject } from '@angular/core';
import { resource } from '@angular/core';
import { Routes } from '@angular/router';
import { ProductService } from './product.service';

export const routes: Routes = [
  {
    path: 'products/:sku',
    component: ProductPage,
    resources: (ctx) => {
      const productService = inject(ProductService);
      return {
        product: resource({
          params: () => ctx.params()['sku'],
          loader: ({ params: sku }) => productService.getBySku(sku),
        }),
      };
    },
  },
];

ctx here is a ResourceContext, giving you params, queryParams, data, and a static snapshot, all as signals. The resources function itself runs in an injection context, which is why inject(ProductService) works directly at the top, without a factory wrapper.

One detail that will bite you if you skip it: pass the primitive you actually need to params, not the whole object. params: () => ctx.params() looks harmless, but the router creates a fresh params object on every navigation, so the resource sees a new reference every time and reloads even when sku didn't change. params: () => ctx.params()['sku'] fixes that, because now the resource only reacts to the primitive value.

resources can also be async, if you need a dynamic import before wiring things up:

resources: async (ctx) => {
  const { fetchProductBySku } = await import('./product-api');
  return {
    product: resource({
      params: () => ctx.params()['sku'],
      loader: ({ params: sku }) => fetchProductBySku(sku),
    }),
  };
},

Any Resource implementation is accepted, not just resource(). If your team is still RxJS-heavy, rxResource() works the same way, swapping loader for stream:

import { rxResource } from '@angular/core/rxjs-interop';

resources: (ctx) => ({
  product: rxResource({
    params: () => ctx.params()['sku'],
    stream: ({ params: sku }) => productService.getBySku$(sku),
  }),
}),

Blocking vs non-blocking, and what actually gets bound to your input

By default every resource is blocking: the router waits for it before activating the route. That has a nice consequence for your component, the input type is the resolved value T, not Resource<T>, because your component never sees a loading or error state, the router already handled that for you.

If you don't want to block navigation, wrap the resource with nonBlocking():

import { Resource, resource } from '@angular/core';
import { Routes, nonBlocking } from '@angular/router';

export const routes: Routes = [
  {
    path: 'products/:sku',
    component: ProductPage,
    resources: (ctx) => ({
      product: nonBlocking(
        resource({
          params: () => ctx.params()['sku'],
          loader: ({ params: sku }) => productService.getBySku(sku),
        }),
      ),
      reviews: resource({
        params: () => ctx.params()['sku'],
        loader: ({ params: sku }) => reviewsService.getForProduct(sku),
      }),
    }),
  },
];

Here product won't block navigation, reviews will. Your component now has to handle both shapes at once:

@Component({
  template: `
    @if (product().isLoading()) {
      <p>Loading product…</p>
    } @else if (product().hasValue()) {
      <h1>{{ product().value().name }}</h1>
    }
    <app-reviews [reviews]="reviews" />
  `,
})
export class ProductPage {
  product = input.required<Resource<Product>>();
  reviews = input.required<Review[]>();
}

nonBlocking() itself is trivial, it just tags the resource with an internal symbol so the router knows to keep the wrapped Resource<T> object as-is instead of unwrapping it:

export function nonBlocking<T, R extends Resource<T>>(res: R): R {
  (res as unknown as InternalRouterResource<T>)[BLOCKING_SYMBOL] = false;
  return res;
}

The actual unwrapping for blocking resources happens in createResourceOutletBindingEffects, in the same file. It uses reflectComponentType to read the component's declared inputs, then for every input name that matches a key in route.resources and whose BLOCKING_SYMBOL isn't explicitly false, it sets up an effect() that calls componentRef.setInput(templateName, resource.value()):

for (const {templateName} of mirror.inputs) {
  const resource = route.resources?.[templateName];
  if (!resource || !(resource as InternalRouterResource)[BLOCKING_SYMBOL]) {
    continue;
  }
  const effectRef = effect(() => {
    componentRef.setInput(templateName, resource.value());
  }, {injector: componentRef.injector});
  createdEffects.push(effectRef);
  handledKeys.push(templateName);
}

Two things worth calling out here. First, the matching is done by input name against the resource map key, so product: resource({...}) only reaches an @Input() (or input()) literally named product.

Rename one without the other and the binding silently stops working, there's no compile-time link between the two.

Second, handledKeys is returned to the caller so that the router's standard data-binding subscription (RoutedComponentInputBinder) skips those keys. Non-blocking resources are never added to handledKeys, they go through that standard data stream instead, bound as the full Resource object.

What `routerResource()` actually wraps

Every resource you hand to the resources map gets passed through routerResource() internally before the router uses it. This is the function doing the heavy lifting:

export function routerResource<T>(source: Resource<T>): Resource<T> & {reload(): boolean} {
  const injector = inject(Injector);
  const router = injector.get(Router);
  const {snapshot: snapshotSignal, frozenSnapshot} = createTransactionalSnapshot(source, router, injector);
  const res = resourceFromSnapshots(snapshotSignal) as unknown as InternalRouterResource<T>;
  res[SOURCE_RESOURCE_SYMBOL] = source;
  res[BLOCKING_SYMBOL] = (source as unknown as InternalRouterResource<T>)[BLOCKING_SYMBOL] !== false;
  // ...reload wiring omitted here, see below
  return res;
}

It doesn't touch your loader, your params function, or your original resource at all. It reads your resource's snapshot() signal (a ResourceSnapshot, the internal shape carrying status/value/error together) through createTransactionalSnapshot, and rebuilds a brand-new Resource from that snapshot stream using resourceFromSnapshots. Your original resource is kept around under SOURCE_RESOURCE_SYMBOL, purely so reload() can delegate to it later. Everything the router hands to your component is this wrapper, not your original resource instance.

The frozen snapshot: why navigating doesn't flash a loading spinner

This is the part I found genuinely clever. When you navigate from /products/1 to /products/2, both routes resolve to the same component and the same product resource key, just with a different sku param. Naively, that resource would immediately flip to isLoading() the moment the param changes, and your component would render a loading skeleton for a split second before the new product shows up. The router avoids that by freezing the resource's snapshot for the duration of the navigation.

createTransactionalSnapshot subscribes to router.events and reacts to five event types:

const sub = router.events.subscribe((e) => {
  if (e instanceof NavigationStart) {
    isRollbackRecoveryPending.set(false);
    if (frozenSnapshot() === null) {
      frozenSnapshot.set(source.snapshot());
    }
  } else if (e instanceof NavigationEnd) {
    frozenSnapshot.set(null);
    isRollbackRecoveryPending.set(false);
  } else if (e instanceof NavigationSkipped) {
    if (frozenSnapshot() !== null) {
      isRollbackRecoveryPending.set(true);
    }
  } else if (e instanceof NavigationCancel || e instanceof NavigationError) {
    const isRollback =
      e instanceof NavigationError ||
      (e instanceof NavigationCancel &&
        e.code !== NavigationCancellationCode.SupersededByNewNavigation &&
        e.code !== NavigationCancellationCode.Redirect);
    if (!isRollback) return;
    isRollbackRecoveryPending.set(true);
  }
});

And the exposed snapshot signal is simply:

snapshot: computed(() => frozenSnapshot() ?? source.snapshot()),

So the flow for a plain, successful navigation is: NavigationStart fires, the router grabs whatever the source resource's snapshot currently is (the old product, already resolved) and locks it in frozenSnapshot. From that point on, even though the underlying resource has already started loading the new sku behind the scenes, your component keeps rendering the frozen, old value — no isLoading flicker, no jump to an empty state. When NavigationEnd fires, the freeze is lifted, frozenSnapshot goes back to null, and the computed falls through to source.snapshot(), which by then holds the new product.

There's a subtlety in that if (frozenSnapshot() === null) guard on NavigationStart. If a second navigation starts while the first hasn't finished (you click fast between two product cards), the router won't re-freeze on top of an existing freeze, it keeps the original snapshot from before the first navigation began. That's intentional, it prevents freezing an intermediate, already-stale value.

Rollback recovery: the part almost nobody thinks about

Here's a scenario the guide only mentions briefly but the source code handles explicitly. Say a canActivate guard rejects a navigation to /products/2. The router cancels it and rolls the URL and route params back to /products/1. That rollback is itself a change in the params signal your resource depends on, from 2 back to 1, so your resource, doing exactly what it's supposed to, fires a new load for sku: 1 — data it already had, and had already shown a second ago.

Without extra handling, that would mean: user clicks, sees the current product freeze for a moment (NavigationStart), sees the guard reject it, then sees a loading flash for the product they were already looking at. The code guards against exactly that with isRollbackRecoveryPending:

} else if (e instanceof NavigationCancel || e instanceof NavigationError) {
  const isRollback =
    e instanceof NavigationError ||
    (e instanceof NavigationCancel &&
      e.code !== NavigationCancellationCode.SupersededByNewNavigation &&
      e.code !== NavigationCancellationCode.Redirect);
  if (!isRollback) return;
  isRollbackRecoveryPending.set(true);
}

Cancellations caused by a newer navigation superseding this one, or by an internal redirect, are not treated as a rollback (the frozen snapshot gets released normally through the navigation that superseded it). Everything else, guard rejections, NavigationError, is treated as a rollback, and the frozen snapshot is kept alive until the resource has actually settled again:

effect(() => {
  if (isRollbackRecoveryPending() && !source.isLoading()) {
    isRollbackRecoveryPending.set(false);
    frozenSnapshot.set(null);
  }
}, {injector});

The freeze only lifts once source.isLoading() is false again, which in the rollback case happens once the resource has re-fetched (or, if it's cached, re-resolved instantly) the old param value. From the user's perspective, nothing happened, the product they were looking at stayed exactly as it was, even though under the hood a full reload was silently triggered and absorbed.

Why `reload()` sometimes just returns `false`

Route resources expose .reload(), but it's not a direct passthrough to your original resource's .reload(). It's guarded:

res.reload = function (): boolean {
  if (frozenSnapshot() !== null) {
    return false;
  }
  return (source as any).reload();
};

If you call .reload() while a navigation is pending, or while the router is in the middle of a rollback recovery, the call is rejected and returns false, your original resource's reload() is never invoked. The reasoning tracks with everything above: during those windows the router is already managing the resource's lifecycle for you, and a manual reload sneaking in would fight with that transition tracking, possibly unfreezing something the router is deliberately keeping frozen. If your source resource doesn't implement reload at all (a custom Resource that only has loader, say), res.reload is just () => false unconditionally.

This is worth checking for in your own code. If you wire a refresh button to userResource?.reload() and nothing happens, the boolean return value is telling you exactly why, it's just easy to ignore a boolean you don't check.

@Component({
  template: `<button (click)="refresh()">Refresh</button>`,
})
export class ProductPage {
  private productResource = inject(ActivatedRoute).resources?.['product'];

  refresh() {
    const didReload = this.productResource?.reload();
    if (!didReload) {
      console.warn('Reload skipped, a navigation transition is in progress.');
    }
  }
}

Redirecting from inside a loader

Blocking resources can redirect before the route ever activates, by throwing a RedirectCommand:

import { inject, resource } from '@angular/core';
import { RedirectCommand, Router } from '@angular/router';

resources: (ctx) => {
  const router = inject(Router);
  return {
    product: resource({
      params: () => ctx.params()['sku'],
      loader: async ({ params: sku, abortSignal }) => {
        const product = await productService.getBySku(sku, { signal: abortSignal });
        if (!product) {
          throw new RedirectCommand(router.parseUrl('/not-found'));
        }
        return product;
      },
    }),
  };
},

Note the abortSignal in the loader arguments, forward it into your fetch call. When the router supersedes a navigation or rolls it back, it aborts the in-flight request through that signal instead of letting an orphaned request finish and update state nobody asked for anymore.

Where this gets uncomfortable

Everything above is solid engineering, but a few things are worth flagging before you rely on this in production.

It's a developer preview API (22.2 at the time of writing). The shapes of ResourceContext, nonBlocking, and the internal snapshot mechanism can change between minors. If you build a design system component library around route.resources, expect to revisit it.

Blocking-resource errors kill the entire navigation, not just the affected component. If you have three parallel blocking resources on a route and one of them throws, the router cancels the whole navigation and fires NavigationError, even if the other two resolved fine and their data would have been perfectly usable. There's no equivalent of a partial activation, you either get every blocking resource or none of them. nonBlocking() sidesteps this, but only if you're willing to accept the full Resource<T> object as your input type instead of the unwrapped value.

The input binding is name-matching, not type-checked. createResourceOutletBindingEffects matches on templateName between your resources map and your component's declared inputs. Rename an input, rename a resource key, or introduce an alias, and the binding breaks silently. TypeScript won't catch this for you, you'll find out at runtime when the input stays undefined.

Manual reload has a silent failure mode. As shown above, .reload() returns false during transitions and rollback recovery instead of throwing or queuing the request. That's the right call for correctness, but it means a "refresh" button clicked at the wrong moment does nothing, and your only way to notice is checking the boolean.

Params identity is a footgun the type system won't warn you about. Passing ctx.params() instead of ctx.params()['id'] compiles fine and works fine in your first manual test, then quietly reloads on every navigation once you actually have more than one route parameter changing shape. This is exactly the kind of bug that survives a demo and shows up three sprints later as "why does this refetch on every click."

Testing route resources properly means testing through the router. Because the freezing and rollback logic lives on router.events subscriptions tied to NavigationStart / NavigationEnd / NavigationCancel, a shallow component test that stubs your service won't exercise any of that behavior. You need a RouterTestingHarness (or equivalent) actually driving navigations to see the freeze/unfreeze cycle at all, plain TestBed.createComponent won't cut it.

Wrapping up

Route resources solve a real problem, resolvers force a sequential waterfall and can't be refreshed without a full renavigation. What the docs describe as "the router masks loading states during pending navigations" is, under the hood, a computed signal falling back between a frozen snapshot and the live one, driven by five router events and one small state machine for rollback recovery. It's not magic, it's a resource wrapper subscribing to navigation lifecycle events and freezing a value at the right moment, then releasing it at the right moment.

If you're adopting this feature now, keep it away from anything load-bearing until it graduates out of developer preview, and keep an eye on that reload() return value.

Optimus UI, NG Switzerland, and NgRx 22

ng-news — Thu, 10 Sep 2026 20:05:14 +0000

Optimus UI, NG Switzerland, and NgRx 22 headline this episode.

Also in brief: new Angular Space podcast episodes and articles, Micro Frontends, Native Federation v4, RxJS 9, and two Angular community deep dives.

Optimus UI

Let's start with Optimus UI. In episode 26-17, we explained that PrimeNG, one of the most popular UI libraries, would become more of a commercial product. Because of that, a fork was created called Optimus UI, which keeps the library fully open source without requiring any additional licence.

Optimus UI was first published as version 1. Later, version 2 followed, aligning it with Angular 22.

Optimus UI - Angular UI Component Library

Optimus UI is a community-maintained, MIT licensed suite of 80+ accessible Angular UI components.

optimus.openng.org

Optimus UI on GitHub

NG Switzerland

Dominic Bachmann, who is one of the people behind OpenNG, which hosts Optimus UI but also other projects, has now started to organize a conference in Switzerland - in Lucerne to be precise.

NG Switzerland will take place on February 11-12, 2027. The call for papers is already open and ticket sales have also started. So, for us, that makes it the first already confirmed conference for next year.

NG Switzerland — 11–12 February 2027, Lucerne, Switzerland

The Angular conference in the heart of Switzerland. 11–12 February 2027, Lucerne, Switzerland.

ng-switzerland.ch

Angular Space Podcast

Armen Vardanyan also came back from his summer holidays with his Angular Space podcast. We already had three different episodes: one about machine learning, another one about RAG, and another episode about Agentic UI, where I was also a guest.

So in the end, all three new episodes focus very much on AI topics around Angular.

Angular Space Articles

Angular Space is not just a podcast, but also a platform where different developers can publish their articles. Recently, we got four new articles by Jaroslaw Zolnowski, Paweł Ostromecki, and Emmanuel Oyibo.

How to Handle Global Errors in Modern Zoneless Angular

angularspace.com

Want to Speak at a Conferences? Here’s What I’ve Learned

angularspace.com

Code Became Cheap. Did Developer Knowledge Too?

angularspace.com

The best API integration platforms for SaaS apps and agents in 2026

A hands-on guide for Angular and TypeScript teams. compared six platforms and focused on how easily each fits into an Angular app and how much backend control you retain when an integration goes beyond the standard flow.

angularspace.com

Micro Frontends

Stefan Haas, Senior Software Engineer at Microsoft, wrote quite a detailed article on Micro Frontends in general. He explains the difference between the Federation approaches - Native Federation and Module Federation - and iframes. He argues that large enterprise companies very often go with iframes, not because of performance - they are actually paying a performance price - but because of the isolation. That is really important when multiple applications have been developed for many years and don't work together so easily.

Stefan also mentions that the Federation approaches can be combined with Web Components. But again, that doesn't give you the same level of isolation that you find with iframes.

Stefan sees Native and Module Federation as a perfect fit, especially for greenfield projects, where you can define the boundaries and make sure that everything works together. And he also mentions another, newer alternative called Web Fragments.

All in all, it is a very good and detailed guide to the Micro Frontends landscape and the pros and cons of the various approaches.

How Big Tech Builds Micro Frontends

Mention iframes to a frontend developer and watch their face. Then look at what Google Cloud Console, Spotify, Salesforce and SAP actually run inside their largest products.

stefanhaas.dev

Native Federation v4

Staying with Micro Frontends, Angular Meetup Graz also hosted a special online meetup with multiple talks around Native Federation version 4. So, if you are interested, you can check out those talks as well. The full recording is available on YouTube.

NgRx 22

NgRx 22 is finally out. The headline feature is new experimental support for resources called Resource Extensions.

For example, you can apply an extension which makes the resource keep the previous value while a new value is loading after its reactive parameters change. You could also build that behavior yourself with snapshot() and some additional state logic, but with Resource Extensions, you stay on the resource itself. This means you can still write to the value, and it doesn't lose the more specific type when you're using, for example, httpResource or other resource types. So that is a little bit more than what you normally get with snapshots.

Another tiny addition is SignalStoreFeatureType. That is a utility type for custom features which makes reusing them easier.

All of that and more is covered in the official NgRx blog post on dev.to.

Marko Stanimirović for NgRx

Aug 24

Announcing NgRx v22: Resource Extensions, Dynamic Deep Signals, a Light Theme, and more!

#ngrx #angular

7 min read

RxJS 9

And after about two and a half years, work on the next generation of RxJS has resumed. There was never a stable version 8 of RxJS, although there were 15 alpha releases and more work was done on it. But now the work continues as RxJS version 9.

The idea is that RxJS 9 builds on the native Observable from the web platform. It is not yet broadly available in browsers. If the browser does not support it, RxJS installs a fallback.

The first beta, 9.0.0-beta.0, was released on August 4, 2026, and announced on August 5.

RxJS on GitHub

RxJS 9.0.0-beta.0 release

benlesh.com

Angular Articles

And then we have two further articles. The first one is more like a comment by Andrés Gesteira on whether Angular is still opinionated. It is a very good read. He analyzes the changes that we have recently seen in the Angular style guide and presents his opinion on them. So, as I said, it is more like a comment article.

The other one is a technical deep dive by Jaime Burgos. His article takes a deep dive into @defer. This is not just about how a defer block works or about its edge cases. It is really about how it works internally and what the compiler generates. So, if you are interested in those things, definitely have a look at it.

Jaime is a very active contributor to the Angular project, so he definitely knows quite a lot about what is going on.

Is Angular Still Opinionated? The New Style Guide

Angular’s new style guide dropped file suffixes, feature-folder rules, and CLI opinions. This article asks if the framework is still opinionated.

quantum-quirks.hashnode.dev

Inside Angular's @defer: The Instructions Behind Deferrable Views

Angular Addicts #52: Angular Addicts #52: Angular 22.1, CopilotKit, MCP Apps, Signal Form Validators & more

Gergely Szerovay — Thu, 27 Aug 2026 07:40:18 +0000

👋Hey fellow Angular Addict

This is the 52nd issue of the Angular Addicts Newsletter, a monthly collection of carefully selected Angular resources that caught my attention. (Here are the 51st, 50th and 49th)

📢 Release announcements

📢 What's new in Angular 22.1?

By Cédric Exbrayat

📢 Introducing Angular support for CopilotKit: bring any Agent into your app

📢 Nx 23.1 Is Here: Per-Run Performance Reports, TypeScript 6, and Angular 22 | Nx Blog

By Juri Strumpflohner

💎Angular Gems of July, 2026

📰 Choosing Angular in the Age of Agents

By Brandon Roberts

📰 One Validator to Rule Them All — Part 2: Advanced Error Handling with multi-language support

By Gábor Kötél

📰 MCP Apps in Angular with CopilotKit: Rich Chat Interfaces Instead of Text Responses

By Manfred Steyer

📰 Faster Builds, Slower Applications? Optimizing Angular's Bundle Output

By Christopher Holder

📰 How to Add Async HTTP Validators to Angular Signal Forms

By Alain Chautard

👨‍💻About the author

Follow me on Substack (Angular Addicts), Substack (AIBoosted.dev), Medium, Dev.to, Twitter or LinkedIn to learn more about Angular, and how to build AI apps with AI, Typescript, React and Angular!

🕹️Previous issues

If you missed the previous issues of the newsletter, you can read them here, these are the latest 3 issues:

📨 Submit your Angular resource

Ng-News 26/19: Angular 22.1

ng-news — Sat, 22 Aug 2026 13:27:49 +0000

Angular 22.1 adds a custom set function for linkedSignal. It gives us something like two-way binding between signals while keeping one signal as the source of truth.

Angular 22.1

Angular 22.1 is the first minor release in the Angular 22 range. With Angular's yearly major release cycle, we can expect multiple minor releases during the year.

As a minor release, 22.1 can introduce new features without breaking existing applications. The main feature for this episode is the custom set function of linkedSignal.

Until now, linkedSignal could derive a writable value from another signal. With the custom setter, writing to that linked value can also update the source signal.

That gives us something like two-way binding between signals.

Angular 22.1 release notes

Versioning and releases • Angular

The web development framework for building modern apps.

angular.dev

A currency converter in both directions

Consider a currency converter with two input fields: one for euros and another for dollars.

When the user changes the euro value, the dollar value should update immediately. The same should work in the other direction: changing dollars should update euros.

The euro signal remains the source of truth. The dollar signal is linked to it and derives its value using the exchange rate.

Before Angular 22.1, the other direction required an effect. The effect observed changes to the dollar value and wrote the converted result back to the euro signal.

Before: synchronizing with an effect

import { Component, effect, linkedSignal, signal, untracked } from '@angular/core';
import { form, FormField, required } from '@angular/forms/signals';

@Component({
  selector: 'app-root',
  imports: [FormField],
  template: `
    <main class="mx-auto mt-16 grid max-w-md gap-4 p-4">
      <h1 class="text-2xl font-semibold">EUR ↔ USD</h1>
      <label class="grid gap-1 text-sm">
        EUR
        <input class="rounded border p-2" [formField]="eurForm" type="number" step="0.01" />
      </label>
      <label class="grid gap-1 text-sm">
        USD
        <input class="rounded border p-2" [formField]="usdForm" type="number" step="0.01" />
      </label>

      <button
        class="cursor-pointer rounded bg-blue-600 px-4 py-2 font-medium text-white hover:bg-blue-700"
        (click)="resetEur()"
      >
        Set USD to 100
      </button>
    </main>
  `,
})
export class App {
  protected readonly eurValue = signal(0);
  protected readonly eurForm = form(this.eurValue, (path) => required(path));

  protected readonly usdValue = linkedSignal({
    source: this.eurValue,
    computation: (eurValue) => this.#toMoney(eurValue * 1.16),
  });
  protected readonly usdForm = form(this.usdValue, (path) => required(path));

  constructor() {
    effect(() => {
      const usd = this.usdForm().value();

      untracked(() => {
        const eur = this.#toMoney(usd / 1.16);
        if (this.eurValue() !== eur) {
          this.eurValue.set(eur);
        }
      });
    });
  }

  resetEur() {
    this.usdValue.set(100);
    console.log(`USD ${this.usdValue()} are in EUR ${this.eurValue()}`);
  }

  #toMoney(value: number) {
    return Math.round(value * 100) / 100;
  }
}

The forward direction already belongs to linkedSignal: whenever eurValue changes, the computation derives the dollar value synchronously.

The reverse direction needs more machinery. The effect observes the dollar form, untracked prevents the write to eurValue from becoming another dependency, and the equality check avoids an unnecessary update.

There is another difference: effects run asynchronously. If code sets the dollar value and reads the euro value immediately afterwards, it can still see the old euro value until the effect runs.

After: writing back with linkedSignal

Angular 22.1 allows linkedSignal to define what should happen when someone calls set or update on it. The write-back logic can therefore live directly beside the computation.

import { Component, linkedSignal, signal } from '@angular/core';
import { form, FormField, required } from '@angular/forms/signals';

@Component({
  selector: 'app-root',
  imports: [FormField],
  template: `
    <main class="mx-auto mt-16 grid max-w-md gap-4 p-4">
      <h1 class="text-2xl font-semibold">EUR ↔ USD</h1>
      <label class="grid gap-1 text-sm">
        EUR
        <input class="rounded border p-2" [formField]="eurForm" type="number" step="0.01" />
      </label>
      <label class="grid gap-1 text-sm">
        USD
        <input class="rounded border p-2" [formField]="usdForm" type="number" step="0.01" />
      </label>

      <button
        class="cursor-pointer rounded bg-blue-600 px-4 py-2 font-medium text-white hover:bg-blue-700"
        (click)="resetEur()"
      >
        Set USD to 100
      </button>
    </main>
  `,
})
export class App {
  protected readonly eurValue = signal(0);
  protected readonly eurForm = form(this.eurValue, (path) => required(path));

  protected readonly usdValue = linkedSignal({
    source: this.eurValue,
    computation: (eurValue) => this.#toMoney(eurValue * 1.16),
    set: (value) => this.eurValue.set(this.#toMoney(this.usdValue() / 1.16)),
  });
  protected readonly usdForm = form(this.usdValue, (path) => required(path));

  resetEur() {
    this.usdValue.set(100);
    console.log(`USD ${this.usdValue()} are in EUR ${this.eurValue()}`);
  }

  #toMoney(value: number) {
    return Math.round(value * 100) / 100;
  }
}

The effect, untracked, and constructor disappear. The linkedSignal now owns both directions:

computation derives dollars whenever the euro source changes.
set handles explicit writes to the dollar signal and writes back to the euro source.
The source update causes the linked value to be recomputed synchronously.

The result is a smaller implementation in which the read and write relationship is declared in one place.

A custom setter is not a general-purpose effect

The custom set function runs whenever code explicitly writes to the linked signal. That makes it powerful enough to execute other logic and react to multiple synchronous writes individually.

Technically, that could be used to work around the glitch-free behavior of an effect. But that is not the intended pattern. The custom setter is most useful when it expresses how a write to derived state should update its source of truth.

The Angular pattern that needs no Provider

Michele Stieven — Sun, 16 Aug 2026 22:00:00 +0000

Services are often the default abstraction for reusable Angular logic. But what if the logic is local to a component, depends on its injection context, and does not represent shared application state?

Consider a dashboard widget that knows whether its host element is currently visible:

@Component({
  selector: 'app-dashboard-widget',
  template: `
    <p>{{ visible() ? 'Awake' : 'Sleeping' }}</p>
  `,
})
export class DashboardWidget {
  readonly visible = injectVisibility();
}

That information can be used to avoid work the user cannot currently see.

For example, we can avoid creating an expensive part of the template:

@if (visible()) {
  <app-expensive-chart />
}

Or pause and resume an asynchronous process:

readonly data = toSignal(
  toObservable(this.visible).pipe(
    switchMap(visible =>
      visible
        ? timer(0, 5000).pipe(
            switchMap(() => this.api.loadStatistics()),
          )
        : EMPTY
    ),
  ),
);

The same pattern can suspend polling, animations, data transformations or expensive visualizations while the component is outside the viewport.

There is no directive in the template, no lifecycle hook and, most importantly, no provider to configure.

Let’s see how we get there.

The component-scoped service

A first solution could be a service that injects the component’s ElementRef, creates an IntersectionObserver and exposes the result as a Signal.

@Injectable()
export class VisibilityService {
  private readonly host =
    inject<ElementRef<HTMLElement>>(ElementRef).nativeElement;

  private readonly destroyRef = inject(DestroyRef);
  private readonly state = signal(false);

  readonly visible = this.state.asReadonly();

  constructor() {
    const observer = new IntersectionObserver(([entry]) => {
      this.state.set(entry?.isIntersecting ?? false);
    });

    observer.observe(this.host);
    this.destroyRef.onDestroy(() => observer.disconnect());
  }
}

For the service to resolve the correct host element, however, it must be created in the component’s element injector:

@Component({
  providers: [VisibilityService],
})
export class DashboardWidget {
  readonly visible = inject(VisibilityService).visible;
}

This works, but the API has a hidden requirement: every consumer must remember to declare the provider.

Forget it, and the feature stops working.

A root service would not solve the problem either. A singleton has no single component host associated with it.

The host directive

A host directive models the responsibility more accurately:

@Component({
  hostDirectives: [VisibilityDirective],
})
export class DashboardWidget {
  readonly visible = inject(VisibilityDirective).visible;
}

The behavior is nicely encapsulated, but we still have metadata boilerplate:

hostDirectives: [VisibilityDirective]

For behavior that should also be selectable from a template, this is perfectly reasonable. But our component only needs a contextual value: a Signal tied to its own host and lifecycle.

Do we really need another injectable instance for that?

A custom inject function

Angular’s inject() API is not limited to services. It can also be used inside a function called while an injection context is active, for example during a component field initializer.

That lets us implement the entire feature as a function:

import {
  DestroyRef,
  ElementRef,
  Signal,
  assertInInjectionContext,
  inject,
  signal,
} from '@angular/core';

export function injectVisibility(
  options: IntersectionObserverInit = {},
): Signal<boolean> {
  assertInInjectionContext(injectVisibility);

  const host =
    inject<ElementRef<HTMLElement>>(ElementRef).nativeElement;

  const destroyRef = inject(DestroyRef);
  const visible = signal(false);

  const observer = new IntersectionObserver(([entry]) => {
    visible.set(entry?.isIntersecting ?? false);
  }, options);

  observer.observe(host);

  destroyRef.onDestroy(() => {
    observer.disconnect();
  });

  return visible.asReadonly();
}

Usage becomes:

@Component({
  selector: 'app-dashboard-widget',
  template: `
    <p>{{ visible() ? 'Awake' : 'Sleeping' }}</p>
  `,
})
export class DashboardWidget {
  readonly visible = injectVisibility({
    rootMargin: '200px',
  });
}

The function:

finds the consumer’s host element;
creates private state for that consumer;
connects the cleanup to its lifecycle;
returns a normal readonly Signal.

No service instance or component metadata is required.

Why the call location matters

This works because field initializers run while Angular is creating the component:

export class DashboardWidget {
  readonly visible = injectVisibility();
}

Calling the same function later does not work:

export class DashboardWidget {
  startObserving() {
    this.visible = injectVisibility(); // Error
  }
}

By then, the component creation context has ended. assertInInjectionContext() makes this constraint immediately clear to consumers of the API.

When should you use this pattern?

A custom inject function is a good fit when the feature:

depends on the caller’s injection context;
creates state local to each consumer;
needs contextual dependencies such as ElementRef or DestroyRef;
does not represent a shared service;
can expose its result through an ordinary value, Signal or Observable.

A service remains the better abstraction when it has shared state, a meaningful identity, or implementations that consumers need to replace through dependency injection.

The important distinction is not whether some code uses Angular DI.

It is whether that code needs to be an injectable object.

Sometimes the cleanest injectable Angular API is just a function.

Ng-News 26/18: Angular Annual Releases, CopilotKit Integration

ng-news — Thu, 06 Aug 2026 18:27:06 +0000

Angular is moving to one major release per year, and CopilotKit for Angular is now officially available.

Angular Release Cadence

The Angular team decided to switch the release interval of major versions from half a year to one year. That is effective immediately and it also means that we won't get Angular 23 later this year, but in May or early June 2027.

That does not mean that new features land later, because adding new features is also allowed in minor versions. The same is also true when it comes to upgrading a certain feature from experimental or developer preview status.

What changes with the major is the amount of breaking changes. They can only now happen once per year. According to the Angular team, the half-year pace was reported to be an issue for enterprises. One also has to say that one major per year also makes it easier for library developers because the amount of work for updating to the new Angular major is now half the work.

Speaking of minor releases, version 22.1 was already released and will be covered in the next episode. We can expect 4-6 minor releases instead of a maximum of three as it was before.

Versioning and releases • Angular

The web development framework for building modern apps.

angular.dev

CopilotKit for Angular

CopilotKit is behind the protocol AG-UI, which is the foundation for agent-driven UIs, including dynamic UI generated at runtime by AI - formats like A2UI run on top of it.

Their Angular support was not open source, but that changed. The code went public in June, followed by the official announcement in July.

For ng-news there are strict rules and one of them is no self-promotion, unless the speaker is part of a team, which is the case here.

The implementation for Angular was done in collaboration with Soverius AI, which is now maintaining the Angular part. Soverius AI consists of Murat Sari and me, Rainer Hahnekamp.

The Angular integration is part of the CopilotKit repository. The announcement blog links to a demo application which showcases several features, like tool calling, A2UI, Generative UI, and more.

Other content creators have already updated their content. For example, Manfred Steyer with his article series on Agentic UI.

copilotkit.ai

soverius.ai

Integrating A2UI with AG-UI and CopilotKit in Angular - ANGULARarchitects

angulararchitects.io

Give Your Angular Modal a URL: Three Router-Based Approaches

Michele Stieven — Sun, 02 Aug 2026 22:00:00 +0000

Opening a modal is easy. Giving it a URL, and making that URL behave like a real part of the application, is where things become interesting.

Let’s look at three ways to connect a modal to the modern Angular Router, including the trade-offs that are easy to miss.

Why route a modal at all?

The usual modal starts with a click handler:

<button (click)="openEditDialog(product.id)">Edit</button>

That works, but the modal exists only in memory. The browser does not know about it.

As a result:

refreshing the page closes it;
the Back button may leave the page instead of closing it;
the Forward button cannot reopen it;
you cannot bookmark or share the modal;
analytics cannot naturally distinguish the underlying page from the modal state.

Most of the times, that is completely fine. A confirmation dialog such as “Delete this draft?” probably does not need a permanent address.

But a product editor, login form, checkout step, image preview, or share panel may deserve one.

For the examples below, imagine a products page with an edit modal. I will use Angular Material’s MatDialog, but the routing strategies do not depend on Material. Near the end, we will connect the same idea to a plain HTML modal.

First rule: the URL as the source of truth

Before choosing a URL shape, we need one rule:

Navigation opens the modal, and another navigation closes it.

A common half-solution is to update the URL when the user clicks a button, then call dialog.open() separately. That creates two sources of truth. A deep link may update the URL without opening anything, while closing the dialog may leave a modal-looking URL behind.

Instead, our flow should be:

user action → router navigation → route state changes → modal opens
modal closes → router navigation → route state changes → modal stays closed

This also means the modal must react when route state changes because of Back, Forward, a redirect, or a pasted URL, not only because of our own button.

With that in mind, let’s choose where the modal state lives.

Option 1: a query parameter

The smallest change is to represent the modal with a query parameter:

/products?dialog=edit&productId=42

This says: “We are still on /products, with some optional UI state layered on top.”

Opening it

The trigger is a normal router link:

<a
  [routerLink]="[]"
  [queryParams]="{ dialog: 'edit', productId: product.id }"
  queryParamsHandling="merge"
>
  Edit
</a>

Using a link rather than a click handler gives us standard browser behaviour: users can open it in a new tab, copy its address, and use keyboard navigation.

Keeping `MatDialog` in sync

The products page observes the query parameters and owns the dialog instance:

import { Component, DestroyRef, inject } from '@angular/core';
import { ActivatedRoute, Router, RouterLink } from '@angular/router';
import { MatDialog, MatDialogRef } from '@angular/material/dialog';
import { distinctUntilChanged, map, take } from 'rxjs';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-products-page',
  imports: [RouterLink],
  templateUrl: './products-page.html',
})
export class ProductsPage {
  private readonly route = inject(ActivatedRoute);
  private readonly router = inject(Router);
  private readonly dialog = inject(MatDialog);
  private readonly destroyRef = inject(DestroyRef);

  private dialogRef?: MatDialogRef<EditProductDialog>;
  private openProductId?: string;

  constructor() {
    this.route.queryParamMap
      .pipe(
        map((params) => {
          const isEditDialog = params.get('dialog') === 'edit';
          return isEditDialog ? params.get('productId') : null;
        }),
        distinctUntilChanged(),
        takeUntilDestroyed(),
      )
      .subscribe((productId) => this.syncDialog(productId));
  }

  private syncDialog(productId: string | null): void {
    if (!productId) {
      this.openProductId = undefined;
      this.dialogRef?.close();
      this.dialogRef = undefined;
      return;
    }

    if (this.dialogRef && this.openProductId === productId) {
      return;
    }

    this.dialogRef?.close();
    this.openProductId = productId;
    const dialogRef = this.dialog.open(EditProductDialog, {
      data: { productId },
      ariaLabel: 'Edit product',
    });
    this.dialogRef = dialogRef;

    dialogRef
      .afterClosed()
      .pipe(take(1), takeUntilDestroyed(this.destroyRef))
      .subscribe(() => {
        // Ignore a previous dialog closing after a new ID replaced it.
        if (this.dialogRef !== dialogRef) {
          return;
        }

        this.dialogRef = undefined;
        this.openProductId = undefined;

        // If Back already removed the parameter, do not navigate again.
        if (this.route.snapshot.queryParamMap.get('dialog') !== 'edit') {
          return;
        }

        this.router.navigate([], {
          relativeTo: this.route,
          queryParams: {
            dialog: null,
            productId: null,
          },
          queryParamsHandling: 'merge',
          replaceUrl: true,
        });
      });
  }
}

There is a little more code here than in the usual dialog.open() example because we are handling both directions:

URL opens or replaces the dialog;
removing the parameters closes it;
closing it removes the parameters;
closing it because Back already changed the URL does not trigger a second navigation.

That final check prevents a subtle history bug.

Why `replaceUrl` when closing?

Opening the modal creates a useful history entry:

/products
/products?dialog=edit&productId=42

If the user presses Back, Angular returns to /products and our subscription closes the dialog.

If the user clicks the modal’s close button, we remove the query parameters with replaceUrl: true. This avoids adding yet another entry just for the close operation.

History policy is a product choice, though. If moving from “open” to “closed” should itself be a revisit-able step, omit replaceUrl.

When query parameters work well

This approach is a good fit when:

the modal is optional UI state on the current page;
it may appear over several primary routes;
you want a small routing change;
filters, pagination, and the modal already coexist in the query string.

Its weaknesses are equally clear:

the owning page needs modal-coordination code;
query parameters are global to the URL, so naming collisions are possible;
URLs become untidy if you encode a lot of modal data;
the modal has no route lifecycle of its own.

Pass stable identifiers in the URL, not an entire object. /products?productId=42 can be refreshed; a JavaScript object passed only through navigation memory cannot.

Option 2: a child path

Maybe editing product 42 feels less like an optional flag and more like a nested destination:

/products/42/edit

That is a strong, readable URL. The trick is keeping the products page rendered underneath it.

We can make the edit route a child of the products page:

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: 'products',
    component: ProductsPage,
    children: [
      {
        path: ':productId/edit',
        component: EditProductDialogRoute,
      },
    ],
  },
];

The parent template needs an outlet where Angular can activate that child route:

<h1>Products</h1>

<app-product-list />

<!-- The route component renders no visible page content here. -->
<router-outlet />

And the link becomes pleasantly ordinary:

<a [routerLink]="[product.id, 'edit']">Edit</a>

A route component that opens the dialog

Angular route configuration activates components; it does not execute arbitrary “open modal” functions. We therefore use a small route component as the bridge:

import { Component, DestroyRef, inject } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { ActivatedRoute, Router } from '@angular/router';
import { MatDialog, MatDialogRef } from '@angular/material/dialog';
import { distinctUntilChanged, map, take } from 'rxjs';

@Component({
  selector: 'app-edit-product-dialog-route',
  template: '',
})
export class EditProductDialogRoute {
  private readonly route = inject(ActivatedRoute);
  private readonly router = inject(Router);
  private readonly dialog = inject(MatDialog);
  private readonly destroyRef = inject(DestroyRef);

  private dialogRef?: MatDialogRef<EditProductDialog>;
  private closingBecauseRouteChanged = false;

  constructor() {
    this.route.paramMap
      .pipe(
        map((params) => params.get('productId')),
        distinctUntilChanged(),
        takeUntilDestroyed(),
      )
      .subscribe((productId) => {
        if (!productId) {
          this.router.navigateByUrl('/products', { replaceUrl: true });
          return;
        }

        this.openDialog(productId);
      });

    this.destroyRef.onDestroy(() => {
      this.closingBecauseRouteChanged = true;

      const dialogRef = this.dialogRef;
      this.dialogRef = undefined;
      dialogRef?.close();
    });
  }

  private openDialog(productId: string): void {
    // Angular can reuse this route component when only productId changes.
    // Invalidate the previous reference before closing it, so its
    // afterClosed callback cannot navigate away from the new dialog.
    const previousRef = this.dialogRef;
    this.dialogRef = undefined;
    previousRef?.close();

    const dialogRef = this.dialog.open(EditProductDialog, {
      data: { productId },
      ariaLabel: 'Edit product',
    });
    this.dialogRef = dialogRef;

    dialogRef
      .afterClosed()
      .pipe(take(1))
      .subscribe(() => {
        if (this.dialogRef !== dialogRef) {
          return;
        }

        this.dialogRef = undefined;

        if (!this.closingBecauseRouteChanged) {
          this.router.navigateByUrl('/products', { replaceUrl: true });
        }
      });
  }
}

Observing paramMap matters because Angular normally reuses the route component when only a parameter changes. Navigating directly from /products/42/edit to /products/43/edit does not run the constructor again; the subscription closes the old dialog and opens the new one.

The reference identity check then ignores the old dialog's late afterClosed() emission. Otherwise, replacing product 42 with product 43 could accidentally navigate back to /products.

The destruction handler covers a different case. If the user presses Back or navigates elsewhere while the dialog is open, Angular destroys the route component and the component closes the overlay.

The boolean prevents that programmatic close from sending the user back to /products after they have already navigated somewhere else. Without it, clicking a link to /orders could briefly navigate there and then be “corrected” back to /products by a late afterClosed() callback. Not fun.

Avoid hard-coding the parent when needed

The example navigates to /products for clarity. In a reusable feature, you may prefer relative navigation or an explicit return target.

Be careful with history.back() as a universal close implementation. It feels elegant when the modal was opened from /products, but a user may arrive directly at /products/42/edit. In that case, Back could leave your application entirely.

A deterministic parent URL is usually safer. If preserving the exact background state matters (filters included) encode that state in the URL or adopt the auxiliary-route approach below.

When a child path works well

Choose this approach when:

the modal belongs to one clear parent page;
the URL should read like a resource or operation;
guards and resolvers should apply specifically to the modal;
direct links such as /products/42/edit make sense to users.

The trade-offs:

the parent must remain active and expose a child outlet;
a small route component is needed when using MatDialog;
reusing the same modal over unrelated pages requires repeated child routes or a broader layout;
the URL alone identifies the child destination, but not an arbitrary underlying page.

This option is often the nicest compromise for resource editors.

Option 3: an auxiliary route

Angular can activate more than one route at the same time. A shell component can expose a primary outlet for the page and a named outlet for the modal:

<router-outlet />
<router-outlet name="modal" />

That lets the URL describe both states independently:

/products(modal:edit/42)

The syntax is unusual at first, but the model is precise:

primary route: products;
modal outlet: edit/42.

Route configuration

Both routes should be children of the shell that owns those outlets:

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    component: AppShell,
    children: [
      {
        path: 'products',
        component: ProductsPage,
      },
      {
        path: 'edit/:productId',
        component: EditProductDialogRoute,
        outlet: 'modal',
      },
    ],
  },
];

When a link is created inside ProductsPage, its current route is the primary child. The modal outlet, however, belongs to the parent shell. We can create the UrlTree relative to that parent:

import { ActivatedRoute, Router, UrlTree } from '@angular/router';

export class ProductsPage {
  private readonly route = inject(ActivatedRoute);
  private readonly router = inject(Router);

  editModalUrl(productId: string): UrlTree {
    return this.router.createUrlTree(
      [
        {
          outlets: {
            modal: ['edit', productId],
          },
        },
      ],
      {
        relativeTo: this.route.parent,
        queryParamsHandling: 'preserve',
      },
    );
  }
}

<a [routerLink]="editModalUrl(product.id)">Edit</a>

Closing a named outlet means navigating with that outlet set to null, again relative to the shell:

this.router.navigate(
  [
    {
      outlets: {
        modal: null,
      },
    },
  ],
  {
    relativeTo: this.route.parent,
  },
);

Our reactive EditProductDialogRoute can be reused here, including its paramMap subscription: changing /products(modal:edit/42) to /products(modal:edit/43) can reuse the same route component too. The only change is what happens after the dialog closes: instead of navigating to /products, it clears the modal outlet.

private closeOutlet(): void {
  this.router.navigate(
    [
      {
        outlets: {
          modal: null,
        },
      },
    ],
    {
      relativeTo: this.route.parent,
      queryParamsHandling: 'preserve',
      replaceUrl: true,
    },
  );
}

As with the child-path version, the route component should close its MatDialogRef when it is destroyed and avoid navigating again when destruction was caused by an existing navigation.

Why auxiliary routes are special

With query parameters, we manually interpret a value as modal state.

With a child path, the modal belongs to a specific parent route.

With an auxiliary route, the Router natively represents the page and modal as two simultaneously active branches. This is powerful when the same modal can sit above different pages:

/products(modal:cart)
/account(modal:cart)
/search?q=headphones(modal:cart)

The primary route can change independently from the modal route, if that is what the application needs.

Auxiliary routes also provide a real route lifecycle. They can have:

route parameters;
guards;
resolvers;
lazy-loaded components;
route-specific providers;
their own activation and deactivation.

The cost

The URL is not subtle:

/products(modal:edit/42)

Developers unfamiliar with auxiliary routes may find the configuration and navigation syntax surprising. Relative navigation also requires care when named outlets are nested inside feature routes.

Use this model because you genuinely have two independent routing regions, not because it is the fanciest option available.

Material dialog or plain HTML?

So far, each routed component has opened a MatDialog. That works well because Material already handles the difficult modal mechanics: overlay positioning, backdrop, focus trapping, Escape, focus restoration, and ARIA roles.

But the Router does not care how the modal is rendered.

With a named outlet, for example, the routed component can be the modal:

import { Component, inject } from '@angular/core';
import { ActivatedRoute, Router } from '@angular/router';

@Component({
  selector: 'app-edit-product-modal',
  template: `
    <div class="backdrop" (click)="close()">
      <section
        class="modal"
        role="dialog"
        aria-modal="true"
        aria-labelledby="edit-product-title"
        (click)="$event.stopPropagation()"
      >
        <h2 id="edit-product-title">Edit product</h2>

        <app-product-form />

        <button type="button" (click)="close()">Close</button>
      </section>
    </div>
  `,
})
export class EditProductModal {
  private readonly router = inject(Router);
  private readonly route = inject(ActivatedRoute);

  close(): void {
    this.router.navigate(
      [{ outlets: { modal: null } }],
      {
        relativeTo: this.route.parent,
        queryParamsHandling: 'preserve',
        replaceUrl: true,
      },
    );
  }
}

That example demonstrates the routing relationship, not a production-complete modal. A custom modal must also:

move focus inside when it opens;
trap focus while open;
close on Escape when appropriate;
restore focus when it closes;
prevent background content from being interactive;
expose a useful accessible name;
handle scrolling correctly.

The native HTML <dialog> element or Angular CDK’s dialog and accessibility utilities can remove some of that work. A visually convincing <div class="modal"> is not automatically an accessible modal.

What about route inputs and signals?

Modern Angular can bind route state directly to component inputs with withComponentInputBinding(). That can make routed modal components pleasantly small:

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

export class EditProductModal {
  readonly productId = input.required<string>();
}

This is especially useful for the child-path and auxiliary-route approaches because productId is a real route parameter.

For query parameters, direct input binding can also be convenient, but we still need coordination code if an imperative overlay such as MatDialog must open and close in response.

Signals improve how we consume route state; they do not change the architectural choice of where that state belongs in the URL.

A practical comparison

Approach	Example URL	Best fit	Main drawback
Query parameter	`/products?dialog=edit&productId=42`	Optional UI state attached to the current page	Coordination lives in the page
Child path	`/products/42/edit`	A modal that belongs to one parent resource or page	Parent layout and route bridge are required
Auxiliary route	`/products(modal:edit/42)`	Page and modal are independent routed regions	More unusual URL and router syntax

My default decision process is:

If the modal is temporary and should not survive refresh, do not route it.
If it is optional state of the current page, start with a query parameter.
If it is a destination naturally nested under one page, use a child path.
If it must coexist with several unrelated primary routes, consider an auxiliary route.

There is no universally “most Angular” answer. The URL should describe the product behaviour you want.

A few rules that apply to all three

Whichever option you choose:

Treat the URL as the source of truth.
Test pasted deep links, not only clicks from inside the app.
Test Back and Forward while the modal is open.
Close the overlay when its route is deactivated.
Prevent afterClosed() from overriding a navigation already in progress.
Put stable identifiers in the URL, then load the data from a service, store, or resolver.
Decide deliberately whether closing should push or replace a history entry.
Do not sacrifice modal accessibility just because routing works.
Add an SSR-safe fallback or render routed modal content declaratively if the route can be rendered on the server.

That second-to-last point deserves repeating. A modal with a beautiful URL but broken keyboard focus is still a broken modal.

Final thought

Routing a modal is not really about calling open() from the Router. It is about deciding whether the modal is part of your application’s navigable state.

Once that decision is clear, the implementation becomes much easier: choose the URL shape that tells the truth, let navigation drive the UI, and make closing the modal a navigation too.

Choosing the right RxJS Operator for Action Streams

Michele Stieven — Mon, 27 Jul 2026 05:03:03 +0000

If you use RxJS action streams (maybe for API calls?), you have probably paused over the same question I have:

Should this effect use mergeMap, switchMap, concatMap, or exhaustMap?

The honest answer is not “use this operator for GET and that operator for POST.” The right choice depends on what a repeated action means in your application.

I will use NgRx Effects in the first example because it is a familiar action-based API, but the ideas in this article are not tied to @ngrx/effects. They apply whenever an RxJS stream represents commands or events that start asynchronous work—for example, in an NgRx SignalStore method built with rxMethod, in a ComponentStore effect, or in your own action stream.

Let’s build a mental model that makes that choice much less mysterious.

The familiar effect

A typical effect listens for an action, calls a service, and maps the result to either a success or a failure action:

import { inject } from '@angular/core';
import { Actions, createEffect, ofType } from '@ngrx/effects';
import { catchError, map, of, switchMap } from 'rxjs';

export const loadTodos = createEffect(
  (
    actions$ = inject(Actions),
    todoService = inject(TodoService),
  ) =>
    actions$.pipe(
      ofType(TodosPageActions.load),
      switchMap(() =>
        todoService.getAll().pipe(
          map((todos) => TodosApiActions.loadSuccess({ todos })),
          catchError((error: unknown) =>
            of(TodosApiActions.loadFailure({ error })),
          ),
        ),
      ),
    ),
  { functional: true },
);

Modern NgRx supports functional effects, so the full example above uses one. From this point on, I will show only the relevant actions$.pipe(...) fragment. You can place the same pipeline inside a class-based effect, a functional effect, an rxMethod, or another RxJS-based action handler.

First: what are we flattening?

An action stream is an Observable. For every action, our service returns another Observable. We therefore have an Observable producing Observables—a higher-order Observable.

The four common flattening operators decide what happens when a new action arrives while the previous inner Observable is still running:

Operator	When another action arrives	Useful mental model
`mergeMap`	Subscribe to it too	Run in parallel
`concatMap`	Put it in a queue	One at a time, in order
`switchMap`	Unsubscribe from the previous inner Observable and switch to the new one	Latest subscription wins
`exhaustMap`	Ignore the new action while the current inner Observable is active	First one wins until completion

That last column is more useful than memorising a rule per HTTP verb.

`mergeMap`: run everything

mergeMap subscribes to every inner Observable as it arrives. Requests may run concurrently, and their responses may arrive in a different order.

This is a good fit when every operation matters and the operations are independent.

The danger is a race condition. If two responses update the same state, an older request can finish last and overwrite newer data.

`concatMap`: queue everything

concatMap waits for the current inner Observable to complete before subscribing to the next one.

Nothing is dropped, and the client starts operations in action order. The trade-off is waiting: one slow request blocks everything queued behind it.

This is often a good default for writes that must be applied in order.

`switchMap`: keep listening only to the latest

When a new action arrives, switchMap unsubscribes from the previous inner Observable and subscribes to the new one.

With Angular HttpClient, unsubscribing normally aborts the client-side request. But be careful with the wording: this does not prove that the server never received or processed it. A write may already have crossed that boundary.

This makes switchMap excellent for replaceable reads—search suggestions are the classic example—but risky as a general policy for writes.

`exhaustMap`: ignore repeated triggers

exhaustMap accepts the first action, then ignores new actions until the active inner Observable completes.

It is useful when repeated triggers are accidental or meaningless: double-clicking a login button, submitting the same form twice, or requesting the same deletion while it is already in progress.

Remember that ignored actions are not queued. They are gone.

Do not choose by HTTP verb alone

“Use switchMap for GET” sounds convenient, but it is too broad.

Ask these questions instead:

Does every action represent work that must happen?
Can two operations safely run at the same time?
Does order matter?
Is a newer action a replacement for an older one?
Should repeated actions be ignored while one is running?
Are those answers global, or only true for actions concerning the same entity?

The last question is where things get interesting.

Loading one replaceable collection

Suppose the store contains one visible list of todos. Every load action means “replace that list with the newest response.”

Here, switchMap is a natural fit:

actions$.pipe(
  ofType(TodosPageActions.load),
  switchMap(() =>
    todoService.getAll().pipe(
      map((todos) => TodosApiActions.loadSuccess({ todos })),
      catchError((error: unknown) =>
        of(TodosApiActions.loadFailure({ error })),
      ),
    ),
  ),
);

If the user refreshes twice, we usually care about the latest refresh, not both responses.

exhaustMap could also be correct—but it expresses a different product decision. It says that refresh clicks should be ignored until the current request completes. NgRx’s own effects guide uses this pattern in a collection-loading example. Neither operator is universally right; the UX decides.

Loading a collection with query parameters

Now imagine:

TodosPageActions.load({ completed: true });
TodosPageActions.load({ completed: false });

Should the first request be cancelled?

It depends on the state model.

If the store holds only the currently selected list, the second action replaces the first query. switchMap is still appropriate:

switchMap(({ completed }) =>
  todoService.getAll({ completed }).pipe(
    map((todos) =>
      TodosApiActions.loadSuccess({ completed, todos }),
    ),
    catchError((error: unknown) =>
      of(TodosApiActions.loadFailure({ completed, error })),
    ),
  ),
)

If the store caches a separate result for each query, both requests matter. mergeMap may be the better choice:

mergeMap(({ completed }) =>
  todoService.getAll({ completed }).pipe(
    map((todos) =>
      TodosApiActions.loadSuccess({ completed, todos }),
    ),
    catchError((error: unknown) =>
      of(TodosApiActions.loadFailure({ completed, error })),
    ),
  ),
)

Notice that the success action includes the query. Without it, the reducer may not know which cache entry to update.

The parameter alone did not determine the operator. The way we store the result did.

Loading individual entities

Consider these actions:

TodosPageActions.loadOne({ id: 1 });
TodosPageActions.loadOne({ id: 2 });

The requests concern different entities, so cancelling one because the other started would be surprising. mergeMap allows both to run:

mergeMap(({ id }) =>
  todoService.get(id).pipe(
    map((todo) => TodosApiActions.loadOneSuccess({ todo })),
    catchError((error: unknown) =>
      of(TodosApiActions.loadOneFailure({ id, error })),
    ),
  ),
)

But what about this?

TodosPageActions.loadOne({ id: 1 });
TodosPageActions.loadOne({ id: 1 });

Now the requests target the same entity. If they run in parallel, an older response could arrive last.

What we really want is:

different IDs: run in parallel;
the same ID: keep only the latest subscription.

That is keyed concurrency.

Keyed concurrency with `groupBy`

RxJS’s groupBy can split the action stream into one stream per ID. We can use switchMap inside each group and mergeMap across groups:

actions$.pipe(
  ofType(TodosPageActions.loadOne),
  groupBy(({ id }) => id),
  mergeMap((actionsForId$) =>
    actionsForId$.pipe(
      switchMap(({ id }) =>
        todoService.get(id).pipe(
          map((todo) =>
            TodosApiActions.loadOneSuccess({ todo }),
          ),
          catchError((error: unknown) =>
            of(TodosApiActions.loadOneFailure({ id, error })),
          ),
        ),
      ),
    ),
  ),
);

This gives us both behaviours:

requests for different entities can run concurrently;
a newer request for the same entity replaces the previous subscription.

If the discriminator is a query object, create a stable key from the meaningful fields. Do not casually use JSON.stringify unless key order and normalisation are under your control.

A `groupBy` lifetime warning

Application-level action streams are usually long-lived. Without a duration, every distinct group created by groupBy also remains available for the life of the subscription. That is harmless for a small, bounded set of keys, but an unbounded stream of unique IDs can retain an unbounded number of groups.

RxJS lets you provide a duration that closes an inactive group:

groupBy(
  ({ id }) => id,
  {
    duration: (group$) => group$.pipe(debounceTime(30_000)),
  },
)

This deserves more caution than it usually gets. If a group closes while one of its requests is still active, a later action with the same key creates a new group. The old request and the new group can then overlap, weakening the per-key guarantee.

Use a duration only when its timing is valid for your domain, or when that occasional overlap is acceptable. For strict, reusable keyed concurrency, prefer a thoroughly tested custom operator or a request-coordination layer with explicit lifecycle tracking. A five-second timeout copied from a blog post is not a correctness proof—I say that with affection as someone who once wanted it to be one.

Creating entities

For independent creates, every action normally matters. mergeMap lets them run concurrently:

actions$.pipe(
  ofType(TodosPageActions.add),
  mergeMap(({ draft }) =>
    todoService.add(draft).pipe(
      map((todo) => TodosApiActions.addSuccess({ todo })),
      catchError((error: unknown) =>
        of(TodosApiActions.addFailure({ draft, error })),
      ),
    ),
  ),
);

Use concatMap instead if creation order matters or the server requires serial execution.

Use exhaustMap if the UI represents a single submission and double-submission must be ignored. Disabling the submit button while the request is pending is still a good UX improvement, but the effect can provide a second line of defence.

switchMap is rarely the safe default for a create. Unsubscribing does not undo a record the server has already created.

Updating entities

This is where I would change a common recommendation: for writes to the same entity, “latest wins” on the client is not enough.

Imagine two edits:

TodosPageActions.update({ id: 1, changes: { title: 'First' } });
TodosPageActions.update({ id: 1, changes: { title: 'Second' } });

With switchMap, the first response may be ignored, but the server might still apply the first update after the second. The client then looks correct until the next reload reveals stale data.

A safer client-side policy is:

different IDs: update in parallel;
the same ID: queue updates in order.

actions$.pipe(
  ofType(TodosPageActions.update),
  groupBy(({ id }) => id),
  mergeMap((actionsForId$) =>
    actionsForId$.pipe(
      concatMap(({ id, changes }) =>
        todoService.update(id, changes).pipe(
          map((todo) =>
            TodosApiActions.updateSuccess({ todo }),
          ),
          catchError((error: unknown) =>
            of(TodosApiActions.updateFailure({ id, error })),
          ),
        ),
      ),
    ),
  ),
);

This preserves the order in which the client sends updates for each entity. It does not solve every distributed-systems problem: other clients can still write concurrently. If that matters, use server-side concurrency control such as version numbers, ETags, or conflict detection.

For high-frequency UI changes, another valid design is to debounce before sending writes, or to dispatch a “commit” action separately from local edits. That is a product and data-consistency decision, not merely an operator choice.

Deleting entities

For deletion, duplicate requests for the same ID are usually pointless, while deletions of different IDs can run in parallel.

That suggests exhaustMap per key:

actions$.pipe(
  ofType(TodosPageActions.delete),
  groupBy(({ id }) => id),
  mergeMap((actionsForId$) =>
    actionsForId$.pipe(
      exhaustMap(({ id }) =>
        todoService.delete(id).pipe(
          map(() =>
            TodosApiActions.deleteSuccess({ id }),
          ),
          catchError((error: unknown) =>
            of(TodosApiActions.deleteFailure({ id, error })),
          ),
        ),
      ),
    ),
  ),
);

A global exhaustMap would also suppress deletion of ID 2 while ID 1 is being deleted. That may be right for a single confirmation dialog, but it is too restrictive for many list UIs.

Also consider making deletion idempotent on the server. Client-side operator choices help the UX; server-side semantics protect the system.

A practical decision table

These are starting points, not laws:

Situation	Likely choice	Why
Latest search or filter replaces the previous one	`switchMap`	Old results are no longer useful
Refresh clicks should be ignored while loading	`exhaustMap`	Prevent duplicate in-flight loads
Independent reads or creates	`mergeMap`	All operations matter and may run together
Ordered writes	`concatMap`	Preserve client-side execution order
Latest read per entity	`groupBy` + `switchMap`	Replace only requests with the same key
Ordered writes per entity	`groupBy` + `concatMap`	Serialize the same entity, parallelise different ones
Ignore duplicate work per entity	`groupBy` + `exhaustMap`	Suppress repeats only for the same key

When uncertain, describe the desired behaviour in plain English first:

Run all of them, queue them, replace the previous one, or ignore the new one?

Then decide whether that rule applies to the whole action stream or separately per entity.

Should we hide this in a custom operator?

A custom operator can remove repetition, but it also hides the most important behaviour in the effect: concurrency.

Names such as PARALLEL, QUEUE, LATEST, and IGNORE_WHILE_BUSY are readable, but a general helper must also get error handling, typing, key lifetimes, cancellation, and per-key cleanup right. That is quite a contract.

My current preference is:

keep the standard RxJS operator visible for simple effects;
extract a keyed operator only after the pattern repeats;
give it a behavioural name;
test it with marble tests, including same-key and different-key actions;
document exactly what happens when groups expire and requests outlive them.

Abstraction should make the concurrency policy clearer, not merely make the pipe shorter.

Final thought

The best flattening operator is not determined by GET, POST, PATCH, or DELETE, nor by whether you happen to be using NgRx Effects, SignalStore, or a home-grown action stream. It is determined by which actions matter, which may overlap, and what your state considers “the same piece of work.”

Once you ask those questions, the four operators stop feeling like RxJS trivia and start looking like four very precise product decisions. And that is much easier to reason about.

Angular Addicts #51: spartan/ui 1.0, A2UI, Signal Debouncing & more

Gergely Szerovay — Thu, 16 Jul 2026 08:31:30 +0000

👋Hey fellow Angular Addict

This is the 51st issue of the Angular Addicts Newsletter, a monthly collection of carefully selected Angular resources that caught my attention. (Here are the 50th, 49th and 48th)

📢 Release announcements

📢 Announcing spartan/ui 1.0

By Robin Goetz

👨‍💻About the author

Follow me on Substack (Angular Addicts), Substack (AIBoosted.dev), Medium, Dev.to, Twitter or LinkedIn to learn more about Angular, and how to build AI apps with AI, Typescript, React and Angular!

🕹️Previous issues

If you missed the previous issues of the newsletter, you can read them here, these are the latest 3 issues:

DEV Community: Playful Programming Angular

Ng-News 26/22: TypeScript 7.1, Angular Native and Polymorpheus

Angular’s Compiler and TypeScript 7.1

Angular Native

Polymorpheus

Upcoming conferences

Ng-News 26/21: Angular 22.2: Router Resources, Error Boundaries, and Private Template Members

Router Resources

Error Boundaries

Private Members in Templates

Angular Addicts #53: NgRx 22, WebMCP, CopilotKit & more

👋Hey fellow Angular Addict

📢 Release announcements

📢 Announcing NgRx v22: Resource Extensions, Dynamic Deep Signals, a Light Theme, and more!

💎Angular Gems of August, 2026

📰 Angular Signal Forms: Custom Controls Without ControlValueAccessor

📰 Introducing CopilotKit for Angular

📰 Loop Engineering with Super Mario and Twelve AI Coding Agents

📰 How to Handle Global Errors in Modern Zoneless Angular

📰 Angular WebMCP — Your App is Now an AI Tool

📰 Signal Forms in Angular 21 - Complete Guide

👨‍💻About the author

🕹️Previous issues

📨 Submit your Angular resource

Route Resources in Angular: what the Router actually does with your Signal under the hood

Introduction

Turning it on

Defining resources on a route

Blocking vs non-blocking, and what actually gets bound to your input

What routerResource() actually wraps

The frozen snapshot: why navigating doesn't flash a loading spinner

Rollback recovery: the part almost nobody thinks about

Why reload() sometimes just returns false

Redirecting from inside a loader

Where this gets uncomfortable

Wrapping up

Optimus UI, NG Switzerland, and NgRx 22

Optimus UI

NG Switzerland

Angular Space Podcast

Angular Space Articles

Micro Frontends

Native Federation v4

NgRx 22

RxJS 9

Angular Articles

Angular Addicts #52: Angular Addicts #52: Angular 22.1, CopilotKit, MCP Apps, Signal Form Validators & more

👋Hey fellow Angular Addict

📢 Release announcements

📢 What's new in Angular 22.1?

📢 Introducing Angular support for CopilotKit: bring any Agent into your app

📢 Nx 23.1 Is Here: Per-Run Performance Reports, TypeScript 6, and Angular 22 | Nx Blog

💎Angular Gems of July, 2026

📰 Choosing Angular in the Age of Agents

📰 One Validator to Rule Them All — Part 2: Advanced Error Handling with multi-language support

📰 MCP Apps in Angular with CopilotKit: Rich Chat Interfaces Instead of Text Responses

📰 Faster Builds, Slower Applications? Optimizing Angular's Bundle Output

📰 How to Add Async HTTP Validators to Angular Signal Forms

👨‍💻About the author

🕹️Previous issues

📨 Submit your Angular resource

Ng-News 26/19: Angular 22.1

Angular 22.1

A currency converter in both directions

Before: synchronizing with an effect

After: writing back with linkedSignal

A custom setter is not a general-purpose effect

The Angular pattern that needs no Provider

The component-scoped service

The host directive

A custom inject function

Why the call location matters

When should you use this pattern?

Ng-News 26/18: Angular Annual Releases, CopilotKit Integration

Angular Release Cadence

CopilotKit for Angular

Give Your Angular Modal a URL: Three Router-Based Approaches

Why route a modal at all?

First rule: the URL as the source of truth

Option 1: a query parameter

What `routerResource()` actually wraps

Why `reload()` sometimes just returns `false`

Keeping `MatDialog` in sync

Why `replaceUrl` when closing?

`mergeMap`: run everything

`concatMap`: queue everything

`switchMap`: keep listening only to the latest

`exhaustMap`: ignore repeated triggers

Keyed concurrency with `groupBy`

A `groupBy` lifetime warning