DEV Community: Playful Programming Angular

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

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!

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

💎Angular Gems of June, 2026

📰 Agentic Engineering: How to Set Up Your Harness for Angular Development

By Alexander Thalhammer

📰 Getting to Know Angular Resource Snapshots

By Fanis Prodromou

📰 Making the Context Across 46 Repositories Semantically Searchable for AI (Part 2)

By Ryosuke Tsuji

👨‍💻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/17: PrimeNG's New Licensing, and A2UI for Angular

ng-news — Mon, 13 Jul 2026 15:18:58 +0000

PrimeNG's new licensing model and A2UI for model-controlled Angular interfaces are the headline topics this week.

Also in brief: OpenNG's community fork, transactional router resource behavior, and the current Native Federation and Module Federation options for Angular.

Future of PrimeNG

PrimeNG, a very popular UI component library, has announced that future major versions won't be available as open source anymore, except through a free Community license for individuals, students, non-profits, non-commercial open source projects, and small organizations.

That doesn't just apply to the Angular version but to the React and Vue versions as well. The reason is that the library has grown over time, which means if you do this as open source you have to spend much more time on it, and at some point, the income that they got from selling things around the library itself didn't cover the costs anymore.

The new licensing brand is PrimeUI. The launch price is USD 599 per developer. That is perpetual, so for life for the covered versions, and it includes one year of updates. It also includes PrimeUI PRO, which contains components for charts, text editor, scheduler, task board, and more. The Pro components are not part of the Community license.

PrimeUI

PrimeUI is a complete UI ecosystem — premium component libraries, advanced pro components, UI kit, and design resources to build modern web applications.

primeui.dev

That being said, OpenNG, an organization which maintains unmaintained libraries, announced that PrimeNG went closed-source, the GitHub repository was archived on June 28th, 2026, and OpenNG created a copy of the project with regenerated open issues and PRs. Their goal is to release a beta version supporting Angular 22. So we are talking here about a fork. At the time of this writing, the current name is open-prime, but OpenNG says it is too close to PrimeNG because PrimeTek plans to put trademarks on it.

OpenNG Update: Funding, Versioning, PrimeNG and ngneat projects | OpenNG posted on the topic | LinkedIn

As people have questions about the future of projects such as Spectator or PrimeNG, here is the current state of our actions. OpenNG We just renamed the initiative from OpenNG Foundation to OpenNG to avoid confusion and to respect the OpenJS Foundation trademark policy. Funding We are working on a funding model to support the maintenance of the projects and give back to contributors. We submitted the initiative to Open Collective and contacted HeroDevs for partnership. Versioning Policy We'll start over with v1.0.0 for all the packages. Each project will include a matrix compatibility table with the supported major Angular versions (including the previous package). Some packages were already not following the Angular versioning policy, and this will allow us to author a major version for breaking changes anytime. PrimeNG PrimeNG went closed-source, and the GitHub repository was archived on June 28th, 2026. Discover the announcement here. We created a copy of the project and regenerated the open issues/PRs. Out of 968 open issues, 58 have already been closed, and 23 triaged as still relevant and accepting contributions to resolve them. Triaging was made possible thanks to the contribution of the community. Our goal this week is to release a beta version supporting Angular 22, as people were already delaying updating their projects. It'll include: - a set of unreleased changes from the original repository (modernize existing components, add a few new ones) - ng add support for new projects - ng update support as unreleased changes include a few breaking changes (camelcase selectors removed, deprecated APIs removed) Our current blocker for this release is to find a proper name for the project. Currently named open-prime, it's too close to PrimeNG as PrimeTek plans to put trademarks on it. We asked the community for suggestions here. We're evaluating proposals, with the main restriction being to avoid confusion with another project (many UI frameworks are matching the proposals). ngneat projects Out of the 34 original repositories, we decided to start working on the following ones: - cashew - query - elf - spectator We have a volunteer working on cashew, currently preparing the first release. Spectator is our priority within the ngneat ecosystem, planning a release this week. We also have a contribution to expose the jasmine package as a standalone (like jest/vitest ones, planned to land in 1.1.0. We still need to triage the remaining repositories to understand if we should keep them or not. 13 of them might not be maintained anymore due to low activity or having a better alternative nowadays. GitHub: https://lnkd.in/eE7QuzZR

linkedin.com

A2UI

Devin Chasanoff from the Angular team has published an article on how to use A2UI with Angular, which enables dynamic UI that is controlled by an AI model.

The user expresses an intent through the frontend. The frontend sends that intent and relevant context to a model. This communication can also include a component catalog that the frontend knows how to render. The model can then decide whether UI components are needed, which components are appropriate, and return structured UI instructions to the application.

A2UI is a protocol used for these agent-generated UI use cases. A2UI messages can be transported over HTTP, WebSocket, or Server-Sent Events, depending on the application architecture.

Demystifying A2UI: How to Make AI Agents “Speak UI” in Your App | by Devin Chasanoff | Jun, 2026 | Angular Blog

I’ve spent a fair amount of time experimenting with A2UI, a protocol for building agentic interfaces. Why? Quite simply, because I think…

blog.angular.dev

routerResource

In other news, work on integrating resource behavior with the router seems to have begun. A PR meant for internal usage popped up, which uses a snapshot-like router resource behavior to integrate navigation-specific information.

That snapshot would freeze a resource's state, for example the value, while a navigation happens. Once the navigation succeeds, the underlying value is exposed, and if the navigation is cancelled, the frozen value would still be there during rollback recovery.

Imagine the following use case. A resource has a router parameter as its own parameter. That could be a product id which loads a product by id. If the user stays on the same component but navigates to a different product id, the resource would immediately change its state and the UI would change while the navigation happens. That could cause flickering effects, especially if the navigation gets cancelled via a guard and the product id changes back to its initial value.

With the introduced router resource behavior, that is not going to happen. Again, the PR's description explicitly states that this is not currently exposed for public use, but it is very likely the start to get resources and the router together.

Angular PR #69490: Create transactional router resource

Micro-Frontends

In other news, going with Micro-Frontends is an architectural need which we find very often in enterprises. Although they are not an Angular framework feature, there are two common community solutions in the form of Native Federation and Module Federation.

The main distinction in Angular is that Native Federation works with esbuild, so the modern Angular builder, and Module Federation traditionally works with the old webpack builder or alternative builders such as Rspack.

Native Federation is maintained by Angular Architects, and Module Federation support in Nx has been common for Angular workspaces. In the release blog for Nx 23, Nx now recommends @angular-architects/native-federation for Angular and deprecates the older Nx-specific Module Federation generators and executors.

Nx 23: 4x Faster Nx Agents, Agentic Nx Migrate, improved targetDefaults, .Net GA | Nx Blog

Nx 23 brings a smarter multi-major nx migrate, performance wins across the local engine and Nx Cloud agents, native Node.js TypeScript stripping and V8 compile cache on by default, more precise target configuration, and a big cleanup of deprecated generators, executors, and APIs.

nx.dev

Ng-News 26/16: OpenNG Foundation, spartan/ui

ng-news — Thu, 02 Jul 2026 21:47:45 +0000

OpenNG Foundation and spartan/ui 1.0 are the headline topics this week: a new home for libraries like Spectator and Elf, and spartan/ui, a stable shadcn-inspired component library for Angular.

Also in brief: Storybook's Angular modernization through AnalogJS, the end of ng-conf, and AI Dev Craft in Las Vegas.

OpenNG Foundation

Maintaining open-source libraries is hard work. Developers often do it in their spare time, committing to years of maintenance, adding new features, and responding to user requests.

Last episode, we reported that the ngneat organization was taken down for unknown reasons. While we still don't know why it happened, a new home has emerged for its popular libraries like Spectator and Elf: the OpenNG Foundation.

Gerome Grignon, known for CanIUseAngular and as the organizer of Ng-Baguette, announced the foundation, which is already hosting these libraries. Alongside Gerome, the current OpenNG team also includes Dominic Bachmann, organizer of Angular Lucerne and author of the angular-typed-router library.

OpenNG Foundation · GitHub

OpenNG Foundation has 8 repositories available. Follow their code on GitHub.

github.com

spartan/ui 1.0

spartan/ui has officially released its 1.0 version. It provides an "accessible, production-ready library of more than 55 components" with fully customizable styling.

After debuting in August 2023 with 30 primitives, it now reaches stable in 2026 with a modern architecture built around signals, standalone components, zoneless change detection, and SSR. Originally initiated by Robin Götz, a full team quickly formed around the project.

spartan/ui can be seen as the Angular equivalent to shadcn/ui, famous for its customizability. While similar open-source alternatives exist, spartan/ui was the pioneer and has a proven track record of active maintenance over the years.

Robin Goetz for Playful Programming Angular

Jun 24

Announcing spartan/ui 1.0

#angular #webdev

3 min read

AnalogJS in Storybook

Storybook’s Angular integration is getting a modernization, and it is all thanks to AnalogJS.

While modern versions of the Angular CLI use Vite under the hood as a development server, it remains a "black box." The Angular CLI is still the one managing the compilation. Because the CLI itself is not a Vite plugin, it cannot be easily plugged into other modern tools.

And that's the issue for Storybook, Vitest, but also others. They are designed to support any framework that presents itself as a Vite plugin.

AnalogJS, founded and maintained by Brandon Roberts, solves this by doing exactly that. It fully decouples Angular from the CLI's build pipeline and exposes it as a standard Vite plugin. Just activate it, and these modern tools can suddenly compile and serve Angular components out of the box without any Angular-specific configuration. It just works.

// Detect dark theme var iframe = document.getElementById('tweet-2067695792106705118-982'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2067695792106705118&theme=dark" }

ng-conf is ending

ng-conf is ending.

ng-conf was the first Angular conference, going back to 2014 with AngularJS, and it continued through to the modern Angular era all the way through 2025. This also means that there is no US-based Angular conference anymore.

In its place, a new conference called AI Dev Craft will debut in October in Las Vegas, with a call for speakers open.

// Detect dark theme var iframe = document.getElementById('tweet-2071616309742453054-891'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2071616309742453054&theme=dark" }

Announcing spartan/ui 1.0

Robin Goetz — Wed, 24 Jun 2026 00:24:58 +0000

After a long and deliberate alpha, spartan/ui is now 1.0.

We shipped the first 30 primitives in August 2023 with a simple bet: building accessible, good-looking UI in Angular is harder than it should be, and the community deserved a better starting point. Almost three years later, that bet has grown into a stable, production-ready library of more than 55 components - built on signals, ready for zoneless, and server-side-rendering compatible out of the box.

Here's what 1.0 actually means.

Stable, and ready to build on

We stayed in alpha for a long time on purpose. It let us refine the APIs in the open, with real applications putting real pressure on the design, instead of freezing a v1 we'd regret six months later.

That patience is what 1.0 cashes in. The APIs are now stable and semantically versioned, so you can depend on spartan/ui/brain and upgrade with confidence. The copy-in spartan/ui/helm layer stays exactly as it's always been - yours to own, read, and customize. No black boxes, no fighting the library to change a style.

Built for modern Angular

Every primitive is built on Angular signals and standalone components. spartan is zoneless-ready and SSR compatible out of the box, so it drops cleanly into how Angular apps are actually written today - no extra setup, no adapters.

The split that's defined spartan from day one still holds. spartan/ui/brain carries the hard, unglamorous parts - ARIA, keyboard navigation, focus management - and keeps them maintained so you don't have to. spartan/ui/helm gives you full styling control on top, copied into your project like a recipe. Accessibility you can rely on; appearance you fully own.

From 30 primitives to 55+

The alpha shipped with 30 components. 1.0 ships with more than 55 - nearly double - including many of the most-requested additions over the past two years:

Data Table - sorting, filtering, and selection, the piece people asked for most
Sidebar - composable app navigation
Calendar and Date Picker
Carousel, Autocomplete, Pagination, and Breadcrumb

And we added Blocks: ready-made, fully responsive layouts assembled from spartan components - authentication pages, sidebar layouts, and multi-step steppers you can drop in and adapt. Less scaffolding, more shipping.

You can browse the full component set and the blocks.

This was built by a community

I want to be clear about something: spartan/ui is not a one-person project, and 1.0 least of all. It exists because a group of people kept showing up - reviewing PRs, building components, fixing the edge cases nobody sees, and arguing about API design until we got it right.

A huge thank you to the people who carried the heaviest load getting us here - Merlin (@MerlinMoos), Marc (@marcjulian), Ashley (@ashley-hunter), Sammy (@thatsamsonkid), Benni (@elite-benni), and Toni (@toniskobic) - and to every single person who has opened an issue, sent a PR, answered a question in Discord, or sponsored the work. There are too many of you to name, and that's exactly the point. spartan is what it is because of you.

If you've contributed and want to say hi or get more involved, the door is open in Discord.

Powered by Zerops

spartan's development infrastructure runs on Zerops, and has for a long time. Preview environments, the docs and demo site, the day-to-day plumbing that makes maintaining an open-source library of this size sustainable - Zerops powers all of it. Their support is a real reason we were able to keep iterating in the open without the infrastructure becoming a tax on the team. Thank you.

Get started

There's never been a better time to start.

Get started with spartan/ui →

spartan is MIT-licensed and built in the open. If it saves you time, consider sponsoring its development - sponsorships fund ongoing maintenance, new components, and keeping spartan free for the whole Angular community.

Here's to 1.0 - and to everything we build on top of it next.

DEV Community: Playful Programming Angular

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

Opening it

Keeping MatDialog in sync

Why replaceUrl when closing?

When query parameters work well

Option 2: a child path

A route component that opens the dialog

Avoid hard-coding the parent when needed

When a child path works well

Option 3: an auxiliary route

Route configuration

Why auxiliary routes are special

The cost

Material dialog or plain HTML?

What about route inputs and signals?

A practical comparison

A few rules that apply to all three

Final thought

Choosing the right RxJS Operator for Action Streams

The familiar effect

First: what are we flattening?

mergeMap: run everything

concatMap: queue everything

switchMap: keep listening only to the latest

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