DEV Community: Brian Treese

Angular 22 hostDirectives De-Duplication Explained

Brian Treese — Fri, 03 Jul 2026 07:00:00 +0000

Host directives are a great way to compose reusable behavior in Angular, but they had one frustrating edge case: two directives could not safely reuse the same shared host directive on the same element. In this post, we'll build a copy button with tooltip behavior, press feedback, and clipboard support, then look at how Angular 22 now de-duplicates shared host directives so this kind of composition works the way you'd expect.

The Problem: Shared Behavior Can Collide

In this demo, we have a simple invite link with a button beside it:

The button needs three behaviors:

On hover, show a tooltip that says "Copy invite link"
On press, temporarily change the message to "Release to copy"
After copying, show "Copied!"

This is exactly the kind of thing the Directive Composition API is good at.

Instead of creating one large directive that handles everything, we can split the behavior into smaller directives:

A shared tooltip directive
A copy button directive
A pressable directive

That keeps each directive focused, reusable, and easier to reason about.

But before Angular 22, this setup could break when more than one directive reused the same shared host directive.

Creating the Shared Tooltip Directive

Let's start with the shared tooltip behavior.

This directive owns the tooltip message, host attributes, and temporary message state:

import {
  computed,
  DestroyRef,
  Directive,
  inject,
  input,
  signal,
} from '@angular/core';

@Directive({
  selector: '[appTooltip]',
  host: {
    class: 'has-tooltip',
    '[attr.aria-label]': 'visibleMessage()',
    '[attr.data-tooltip]': 'visibleMessage()',
    '[class.show-tooltip]': 'showingTemporaryMessage()',
  },
})
export class TooltipDirective {
  readonly message = input.required<string>();
  private readonly destroyRef = inject(DestroyRef);
  private readonly temporaryMessage = signal<string | null>(null);
  private timeoutId: ReturnType<typeof setTimeout> | null = null;

  constructor() {
    this.destroyRef.onDestroy(() => this.clearTimeout());
  }

  protected readonly showingTemporaryMessage = computed(() => {
    return this.temporaryMessage() !== null;
  });

  protected readonly visibleMessage = computed(() => {
    return this.temporaryMessage() ?? this.message();
  });

  showMessage(message: string): void {
    this.clearTimeout();
    this.temporaryMessage.set(message);
  }

  clearMessage(): void {
    this.clearTimeout();
    this.temporaryMessage.set(null);
  }

  showTemporaryMessage(message: string, duration = 1200): void {
    this.showMessage(message);

    this.timeoutId = setTimeout(() => {
      this.temporaryMessage.set(null);
      this.timeoutId = null;
    }, duration);
  }

  private clearTimeout(): void {
    if (this.timeoutId !== null) {
      clearTimeout(this.timeoutId);
      this.timeoutId = null;
    }
  }
}

There are a few important details here.

The directive has a required message input using Angular’s input() API.

It also adds several host bindings:

host: {
  class: 'has-tooltip',
  '[attr.aria-label]': 'visibleMessage()',
  '[attr.data-tooltip]': 'visibleMessage()',
  '[class.show-tooltip]': 'showingTemporaryMessage()',
}

The aria-label gives the button an accessible name.

The data-tooltip attribute gives the CSS text to render via the attr() function.

And show-tooltip lets us force the tooltip to appear when a temporary message is being shown.

The key point is that this directive does not know anything about copying text or press states.

It only owns tooltip behavior.

Composing Tooltip Behavior Into a Copy Button

Next, we have a directive for the copy behavior:

import { Directive, inject, input } from '@angular/core';
import { TooltipDirective } from './tooltip';

@Directive({
  selector: '[appCopyButton]',
  hostDirectives: [
    {
      directive: TooltipDirective,
      inputs: ['message: tooltip'],
    },
  ],
  host: {
    '(click)': 'copy()',
  },
})
export class CopyButtonDirective {
  readonly copyText = input.required<string>();
  readonly copiedMessage = input.required<string>();
  readonly copyFailedMessage = input.required<string>();
  readonly copiedDuration = input(2500);
  private readonly tooltip = inject(TooltipDirective);

  protected async copy(): Promise<void> {
    try {
      await navigator.clipboard.writeText(this.copyText());
      this.tooltip.showTemporaryMessage(this.copiedMessage(), this.copiedDuration());
    } catch {
      this.tooltip.showTemporaryMessage(
        this.copyFailedMessage(),
        this.copiedDuration()
      );
    }
  }
}

This directive composes the TooltipDirective using hostDirectives:

hostDirectives: [
  {
    directive: TooltipDirective,
    inputs: ['message: tooltip'],
  },
],

That means when appCopyButton is applied to an element, Angular also applies the tooltip behavior to that same host element.

The directive also exposes the tooltip directive’s message input as tooltip.

So instead of writing this:

<button appTooltip message="Copy invite link"></button>

We can expose a more purposeful API through the copy directive:

<button appCopyButton tooltip="Copy invite link"></button>

Then, when the button is clicked, the directive writes the text to the clipboard using the Clipboard API.

If it works, it temporarily shows the copied message.

If it fails, it shows the failed message.

Reusing the Same Tooltip in a Pressable Directive

Now let’s add a second behavior directive.

This one handles the pressed state:

import { Directive, inject, input, signal } from '@angular/core';
import { TooltipDirective } from './tooltip';

@Directive({
  selector: '[appPressable]',
  hostDirectives: [
    {
      directive: TooltipDirective,
      inputs: ['message: tooltip'],
    },
  ],
  host: {
    '(pointerdown)': 'press()',
    '(pointerup)': 'release()',
    '(pointerleave)': 'release()',
    '(blur)': 'release()',
    '[class.is-pressed]': 'isPressed()',
  },
})
export class PressableDirective {
  readonly pressedMessage = input.required<string>();
  protected readonly isPressed = signal(false);
  private readonly tooltip = inject(TooltipDirective);

  protected press() {
    this.isPressed.set(true);
    this.tooltip.showMessage(this.pressedMessage());
  }

  protected release() {
    this.isPressed.set(false);
    this.tooltip.clearMessage();
  }
}

This directive also composes the same TooltipDirective.

When the user presses the button, it sets the pressed state and updates the tooltip message.

When the user releases, leaves, or blurs the button, it clears the temporary message.

So now we have two higher-level behavior directives:

CopyButtonDirective
  └── TooltipDirective

PressableDirective
  └── TooltipDirective

That’s the important part.

Both directives reuse the same lower-level tooltip behavior.

And that’s where older Angular versions could run into trouble.

Applying Both Directives to the Same Button

In the app component, we import both behavior directives:

import { Component, signal } from '@angular/core';
import { CopyButtonDirective } from './directives/copy-button';
import { PressableDirective } from './directives/pressable';

@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.css',
  imports: [CopyButtonDirective, PressableDirective],
})
export class App {
  protected inviteUrl = signal('https://example.com/articles/angular-host-directives');
}

Then, in the template, we layer both behaviors onto the same button:

<button
  appPressable
  pressedMessage="Release to copy"
  appCopyButton
  tooltip="Copy invite link"
  copiedMessage="Copied!"
  copyFailedMessage="Unable to copy"
  [copyText]="inviteUrl()"
  class="icon-button">
  <span aria-hidden="true">🔗</span>
</button>

This is still just a button.

But now it has independent behaviors layered onto it:

appPressable handles press feedback
appCopyButton handles clipboard behavior
both share the tooltip behavior

This is the kind of composition that should be possible with host directives.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Why This Used to Break

Before Angular 22, this setup would throw a duplicate directive error:

The problem was not the button itself.

The problem was the resolved directive tree.

Angular saw that appPressable brought in TooltipDirective.

It also saw that appCopyButton brought in TooltipDirective.

So from Angular’s point of view, the same directive was being matched more than once on the same element.

Conceptually, the composition looked like this:

button
  ├── appPressable
  │   └── TooltipDirective
  └── appCopyButton
      └── TooltipDirective

We were not trying to create two separate tooltips.

We were trying to compose two higher-level behaviors that happened to share one lower-level behavior.

That’s a common pattern, especially if you’re building reusable Angular libraries.

Angular 22 De-Duplicates Shared Host Directives

Angular 22 fixes this by de-duplicating shared host directives.

Now, when the same directive appears more than once in the resolved host directive tree, Angular can merge those matches into a single directive instance.

So instead of treating this as two separate tooltip directives, Angular recognizes that both composition paths are asking for the same directive.

Now the button works as expected:

Hover shows "Copy invite link"
Pressing changes the message to "Release to copy"
Releasing and copying changes the message to "Copied!"

The code does not need to change.

The composition just works.

One Important Caveat: Aliases Still Matter

There is one detail worth calling out.

Both directives expose the tooltip message input using the same alias:

inputs: ['message: tooltip']

That matters.

Angular can merge duplicate host directive matches, but it still has to merge their input and output mappings.

So this is fine:

inputs: ['message: tooltip']

But you can't do this in the other directive:

inputs: ['message: other-tooltip']

If one directive exposed the same input as tooltip and another exposed it as something else, Angular would not know which public API should win.

That’s when you can run into a conflicting host directive binding error.

So the rule is simple: If multiple directives reuse the same shared host directive and expose the same input or output, use the same alias.

Why This Makes hostDirectives More Practical

After upgrading to v22, this button can safely combine both higher-level behaviors.

Angular de-duplicates the shared host directive.

And the button gets tooltip behavior, press feedback, and clipboard copy behavior without a duplicate directive error.

That makes directive composition feel a lot more practical.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Angular 22: Better Tab Animations in Material

Brian Treese — Fri, 26 Jun 2026 07:00:00 +0000

Angular Material tabs already make it easy to organize content into separate views, but the animation controls have always had one slightly annoying limitation: the tab indicator and the tab body shared the same animation duration. In Angular 22, that changes. Now, mat-tab-group can use separate values for the tab header and tab body animation durations, giving us more fine-grained control over the animation.

The Problem With Shared Tab Animation Durations

Let's say we have a simple client workspace dashboard:

This app uses Angular Material tabs to separate the client overview, projects, invoices, and recent activity:

<mat-tab-group>
  <mat-tab label="Overview">
    ...
  </mat-tab>

  <mat-tab label="Projects">
    ...
  </mat-tab>

  <mat-tab label="Invoices">
    ...
  </mat-tab>

  <mat-tab label="Activity">
    ...
  </mat-tab>
</mat-tab-group>

Nothing fancy here.

It's just a normal mat-tab-group with several mat-tab items inside it.

Each tab has a label that shows up in the tab header, and each tab also has content that gets displayed in the tab body.

But when we switch between these tabs, there are actually two different animations happening:

The active tab indicator moves in the tab header
The tab content slides in the tab body

Those two animations are related, but they don't always need the same timing.

The tab indicator should usually feel quick and responsive because it confirms the user's click.

The tab body can often move a little slower, especially when the content is heavier or more visual.

That’s where the old API created a tradeoff.

The Old Way: One Duration for Everything

Angular Material has supported the animationDuration input on mat-tab-group for a long time.

So, if we wanted to slow down the tab transition, we could do this:

<mat-tab-group animationDuration="1500ms">
  ...
</mat-tab-group>

This works.

The tab body would transition much slower, which can make larger content panels feel more intentional.

But there's a catch.

That same duration also affects the header indicator animation.

So the content would feel smooth, but the selected tab indicator would feel like it's dragging behind the click.

That makes the UI feel less responsive.

Making the Indicator Faster Creates the Opposite Problem

We can try to fix the sluggish tab indicator by lowering the duration:

<mat-tab-group animationDuration="150ms">
  ...
</mat-tab-group>

Now the selected tab indicator would feel much better.

It would move quickly, so the user would get immediate feedback.

But now the tab body animation would be too fast.

The content would snap into place, and we would lose the smoother transition we wanted in the first place.

So we would be stuck with a compromise:

make the body animation feel smooth, but the header feel slow
make the header feel fast, but the body feel abrupt

The issue is that the header and body are different parts of the UI.

They have different jobs.

So they should be able to have different animation durations.

And now in Angular 22, they can.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Angular 22: Separate Header and Body Durations

Angular Material tabs now allows the animationDuration input to accept either the original shared duration value or an object with separate header and body values.

So instead of this:

<mat-tab-group animationDuration="150ms">
  ...
</mat-tab-group>

We can bind to an object:

<mat-tab-group [animationDuration]="{
  header: '150ms',
  body: '1500ms'
}">
  ...
</mat-tab-group>

This gives us much better control.

The header value controls the tab header animation, which includes the active indicator.

The body value controls the tab content animation.

So now the indicator can stay fast, while the body content can transition more slowly.

When This Is Actually Useful

This is a small API improvement, but it solves a real UI polish problem.

For simple tabs with lightweight content, the default behavior is probably fine.

But separate durations can help when:

the tab body contains heavier dashboard content
you want a more polished transition between larger panels
the active tab indicator feels delayed
you want to disable or reduce one animation without affecting the other
you're trying to make tabs feel more responsive without making the content snap

The key idea is that feedback and transition are not always the same thing.

The header animation is feedback.

The body animation is transition.

Now Angular Material lets us tune them separately.

It's not a huge feature, but it removes a real UI compromise.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Angular 22: linkedSignal() Can Now Write Back to State

Brian Treese — Fri, 19 Jun 2026 07:00:00 +0000

Angular's linkedSignal() just got a small upgrade with a big practical payoff. It can now read from larger signal state and write back to it with a custom setter, giving us a clean field-level API without creating disconnected duplicate state.

Note: At the time of writing, the feature you're about to see is only available in Angular 22.1.0-next.0.

The Problem: Editing Nested Signal State

Let's start with a simple profile settings screen:

We have a signed-in user, and a product updates setting that controls how many marketing emails this user can receive each week.

In the template, we bind the input to a field-level signal maxMarketingEmailsPerWeek():

<input
  #emailLimit
  type="number"
  min="0"
  [value]="maxMarketingEmailsPerWeek()"
  (input)="setMaxMarketingEmailsPerWeek(emailLimit.value)" />

Then we have a couple of buttons that update that value from their own methods sendFewerEmails() and sendMoreEmails():

<button
  type="button"
  [disabled]="maxMarketingEmailsPerWeek() === 0"
  (click)="sendFewerEmails()">
  Send fewer emails
</button>

<button
  type="button"
  (click)="sendMoreEmails()">
  Send more emails
</button>

Nothing too unusual here.

But the important part is that this value does not live in its own isolated signal.

The actual source of truth is a larger profile object.

protected readonly profile = signal<UserProfile>({
  id: 1,
  name: 'Brian Treese',
  email: 'brian@example.com',
  maxMarketingEmailsPerWeek: 2,
});

A profile object like this might come from an API, a resource, a store, a parent component, or some other state layer.

We don't always have a separate signal for every property.

Sometimes the UI needs to edit one field, while the real state is a larger object.

Before Angular 22: Reading Was Clean, Writing Wasn't

Before this update, we could use linkedSignal() to read the field from the parent signal:

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek
);

This gives us a field-level signal for the maxMarketingEmailsPerWeek property.

So the template can read it directly:

[value]="maxMarketingEmailsPerWeek()"

But writing back to the parent profile signal still required a separate method.

First, the input handler received the raw DOM value as a string, converted it to a number, prevented negative values, and then called a updateMaxMarketingEmailsPerWeek() method:

protected setMaxMarketingEmailsPerWeek(value: string) {
  this.updateMaxMarketingEmailsPerWeek(Math.max(0, Number(value) || 0));
}

Then that method updated the parent profile signal:

protected updateMaxMarketingEmailsPerWeek(value: number) {
  this.profile.update(profile => ({
    ...profile,
    maxMarketingEmailsPerWeek: value,
  }));
}

The buttons needed to call the same method too:

protected sendFewerEmails() {
  this.updateMaxMarketingEmailsPerWeek(
    Math.max(0, this.maxMarketingEmailsPerWeek() - 1)
  );
}

protected sendMoreEmails() {
  this.updateMaxMarketingEmailsPerWeek(
    this.maxMarketingEmailsPerWeek() + 1
  );
}

This works fine.

But the code is more spread out than it needs to be.

The linked signal handles the read side, while the write-back logic lives somewhere else.

That's the part Angular 22 lets us clean up.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Angular 22: Add a Custom set() to linkedSignal()

Now linkedSignal() can take a custom set function.

That means we can keep the read logic and write-back logic together:

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek,
  {
    set: value => {
      this.profile.update(profile => ({
        ...profile,
        maxMarketingEmailsPerWeek: value,
      }));
    },
  }
);

Now this linked signal knows how to read from the profile (which it already did):

() => this.profile().maxMarketingEmailsPerWeek

And it also knows how to write back to the profile:

set: value => {
  this.profile.update(profile => ({
    ...profile,
    maxMarketingEmailsPerWeek: value,
  }));
}

That's the key idea.

The linked signal becomes a writable field-level API that is still backed by the larger profile object.

This is not a second source of truth and it's not magic two-way binding.

It's just an explicit write-back function for a focused piece of state.

Step 1: Use set() on the linkedSignal()

Now that the linked signal has custom write behavior, the input handler can be simplified.

Instead of calling the separate helper method, we can call set() directly on the linked signal.

Before:

protected setMaxMarketingEmailsPerWeek(value: string) {
  this.updateMaxMarketingEmailsPerWeek(Math.max(0, Number(value) || 0));
}

After:

protected setMaxMarketingEmailsPerWeek(value: string) {
  this.maxMarketingEmailsPerWeek.set(Math.max(0, Number(value) || 0));
}

The function still handles the DOM input conversion, but once we have the final value, we just set the field-level signal.

Because we added the custom setter, that value writes back to the full profile object.

Step 2: Use update() Too

This also works with update().

So the button methods can be simplified too.

Instead of this:

protected sendFewerEmails() {
  this.updateMaxMarketingEmailsPerWeek(
    Math.max(0, this.maxMarketingEmailsPerWeek() - 1)
  );
}

protected sendMoreEmails() {
  this.updateMaxMarketingEmailsPerWeek(
    this.maxMarketingEmailsPerWeek() + 1
  );
}

We can update the linked signal directly:

protected sendFewerEmails() {
  this.maxMarketingEmailsPerWeek.update(value => Math.max(0, value - 1));
}

protected sendMoreEmails() {
  this.maxMarketingEmailsPerWeek.update(value => value + 1);
}

This is the part I really like.

Both set() and update() flow through the custom setter, so they both write back to the parent profile signal.

update() is not bypassing the custom setter.

It calculates the next value, then sends that value through the same write-back path.

And now the old updateMaxMarketingEmailsPerWeek() helper method has no job.

Always a nice moment.

We can delete it.

The Final Result

After this change, the component is easier to reason about.

We have the source of truth:

protected readonly profile = signal<UserProfile>({
  id: 1,
  name: 'Brian Treese',
  email: 'brian@example.com',
  maxMarketingEmailsPerWeek: 2,
});

Then we have the field-level linked signal:

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek,
  {
    set: value => {
      this.profile.update(profile => ({
        ...profile,
        maxMarketingEmailsPerWeek: value,
      }));
    },
  }
);

And the UI actions can work directly with that field-level signal:

protected setMaxMarketingEmailsPerWeek(value: string) {
  this.maxMarketingEmailsPerWeek.set(Math.max(0, Number(value) || 0));
}

protected sendFewerEmails() {
  this.maxMarketingEmailsPerWeek.update(value => Math.max(0, value - 1));
}

protected sendMoreEmails() {
  this.maxMarketingEmailsPerWeek.update(value => value + 1);
}

The behavior is the same, but the state management is cleaner because the read and write behavior now live together.

Final Thoughts

This is a small API change, but it's a practical improvement for real Angular state management.

Before, linkedSignal() gave us a clean way to read a value from larger state, but writing back to it still needed to happen somewhere else.

Now the linked signal can own both sides.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

New in Angular 22: Directives for CDK Component Portals

Brian Treese — Fri, 12 Jun 2026 07:00:00 +0000

Angular 22 lets ComponentPortal apply directives to a dynamically rendered component’s host element. In this post, we’ll use that to add a custom directive to the same help component rendered through both CdkPortalOutlet and DomPortalOutlet.

Note: This example focuses on a few accessibility concepts applied through a directive. It’s not meant to be a complete accessibility pattern for every dynamic panel.

The Problem: Dynamic Components Need Host Behavior Too

In this example, we have a simple checkout screen with a “Need help?” area in the sidebar:

When the user clicks the button, we render a payment help message:

This is done dynamically using the Angular CDK Portal API.

It works, but currently, there’s a problem.

The component is rendered dynamically, but the host element doesn’t describe what it is.

For this example, we’ll expose the help panel as a named region.

That means it needs:

A role="region"
An accessible name with aria-label
A way to receive focus when it opens

This gets more interesting because we render the same help component in two different places.

First, we render it inline in the checkout sidebar with CdkPortalOutlet.

Then, we render it again as a floating support panel attached directly to the document body with DomPortalOutlet:

Same component. Different outlet. Different context.

So we need context-specific host behavior, but we don’t want to bake that directly into PaymentHelpComponent.

How the Inline Portal Works

The inline version uses CdkPortalOutlet in the checkout template.

<ng-template [cdkPortalOutlet]="helpPortal()"></ng-template>

Then, in the component, we create the portal only when the help panel should be shown:

protected readonly showHelp = signal(false);

protected readonly helpPortal = computed(() =>
  this.showHelp()
    ? new ComponentPortal(PaymentHelpComponent)
    : null,
);

A ComponentPortal says: “create this Angular component dynamically, and let a portal outlet render it.”

In this case, the destination is part of the Angular template.

The help component gets created inside the checkout sidebar.

How `DomPortalOutlet` Renders the Floating Portal

The floating version is different.

Instead of rendering into a template outlet, we create a DOM element manually and attach a portal there.

private openSupport() {
  this.hostElement = this.document.createElement('div');
  this.hostElement.classList.add('floating-help');
  this.document.body.append(this.hostElement);

  this.outlet = new DomPortalOutlet(
    this.hostElement,
    this.appRef,
    this.injector,
  );

  this.outlet.attach(
    new ComponentPortal(PaymentHelpComponent),
  );

  this.supportOpen.set(true);
}

This is useful when the content should not be constrained by the current component layout.

The floating support panel is appended to the document body, positioned globally, and managed through the portal outlet.

So now we have two rendering strategies:

// Inline checkout help
new ComponentPortal(PaymentHelpComponent)

// Floating global help
new ComponentPortal(PaymentHelpComponent)

Both render the same component.

Both have the same accessibility problem.

And both need the same host-level behavior.

Create a Directive for the Portal Host

Instead of adding this behavior to the help component itself, we can create a directive.

import {
  afterNextRender,
  Directive,
  ElementRef,
  inject,
  input,
} from '@angular/core';

@Directive({
  selector: '[appPortalPanel]',
  host: {
    role: 'region',
    '[attr.aria-label]': 'ariaLabel()',
    tabindex: '-1',
  },
})
export class PortalPanelDirective {
  readonly ariaLabel = input('');
  private readonly elementRef = inject(ElementRef);

  constructor() {
    afterNextRender(() => {
      this.elementRef.nativeElement.focus();
    });
  }
}

This directive does three things.

First, it adds the region role.

role: 'region',

Then it binds the aria-label from an input.

'[attr.aria-label]': 'ariaLabel()',

And finally, it adds tabindex="-1" so the panel can receive programmatic focus without adding it to the normal tab order.

tabindex: '-1',

The focus behavior happens after Angular finishes rendering.

afterNextRender(() => {
  this.elementRef.nativeElement.focus();
});

This is the behavior we want, but the important part is where we apply it.

We don't want to modify PaymentHelpComponent.

That component should stay focused on its own content.

No role. No aria-label. No focus logic.

That’s all contextual behavior, so we’ll attach it from the portal instead.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Add a Directive to `ComponentPortal`

Angular 22 adds directive support to ComponentPortal.

That means we can apply one or more directives to the dynamically-created component host.

Here's what it looks like:

protected readonly helpPortal = computed(() =>
  this.showHelp()
    ? new ComponentPortal(
      PaymentHelpComponent,
      null,
      null,
      null,
      undefined,
      [
        {
          type: PortalPanelDirective,
          bindings: [
            inputBinding('ariaLabel', () => 'Payment help for checkout'),
          ],
        },
      ],
    )
    : null,
);

Yes, the constructor call is a little verbose because the new directive support is currently the sixth argument.

So we pass through the earlier optional arguments:

new ComponentPortal(
  PaymentHelpComponent,
  null,      // viewContainerRef
  null,      // injector
  null,      // projectableNodes
  undefined, // bindings
  [
    // Directives
  ],
)

The key part is the directives array:

[
  {
    type: PortalPanelDirective,
    bindings: [
      inputBinding('ariaLabel', () => 'Payment help for checkout'),
    ],
  },
]

The type tells Angular which directive to apply.

The bindings array lets us configure that directive.

In this case, we use inputBinding() to pass a value into the directive’s ariaLabel input.

So when Angular creates PaymentHelpComponent, it also applies PortalPanelDirective to the component host.

That gives us the role, label, tabindex, and focus behavior without changing the help component at all.

Reuse the Same Directive with `DomPortalOutlet`

Now we can apply the same idea to the floating support launcher.

this.outlet.attach(
  new ComponentPortal(
    PaymentHelpComponent,
    null,
    null,
    null,
    undefined,
    [
      {
        type: PortalPanelDirective,
        bindings: [
          inputBinding('ariaLabel', () => 'Floating payment help'),
        ],
      },
    ],
  ),
);

This is the same component.

It uses the same directive.

But now the label is different because the rendering context is different.

inputBinding('ariaLabel', () => 'Floating payment help')

That’s the real benefit.

The component stays reusable, and the portal decides what host behavior makes sense for the place where the component is being rendered.

The Result: Host Behavior Travels with the Portal

After this change, the inline checkout help panel receives the host behavior automatically.

When it opens, it gets focus.

And when we inspect the generated host element, it now includes the attributes we need:

<app-payment-help
  role="region"
  aria-label="Payment help for checkout"
  tabindex="-1">
</app-payment-help>

The floating panel gets the same behavior too:

<app-payment-help
  role="region"
  aria-label="Floating payment help"
  tabindex="-1">
</app-payment-help>

So even though these panels are rendered through different portal outlets, the portal carries the directive configuration with it.

Final Thoughts

ComponentPortal is no longer just about dynamically rendering a component.

In Angular 22, it can also bring the host behavior that component needs for a specific context.

That’s especially useful when the same component can appear in multiple places.

The component stays clean.

The directive stays reusable.

And the portal becomes the place where dynamic rendering and context-specific behavior come together.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Angular Material Dialogs Now Support Real Component Bindings

Brian Treese — Fri, 05 Jun 2026 07:00:00 +0000

Angular Material dialogs just got a practical upgrade. In Angular 22, dialogs can now bind directly to component inputs, outputs, and model inputs. That means we can build one reusable component, use it inline, and then open that same component inside a dialog without creating a special wrapper component.

The Problem

In this demo, we have a reusable notification settings component.

It needs three things:

readonly user = input<User | null>(null);
readonly enabled = model(false);
readonly saved = output<NotificationSettingsSaved>();

So inline, we can use it like this:

<app-notification-settings
  [user]="user()"
  [(enabled)]="notificationsEnabled"
  (saved)="saveNotificationSettings($event)"
/>

This is normal Angular component communication.

The parent passes in the user, keeps the notification value synced, and listens for the save event.

But when we open that same component in an Angular Material dialog, things are different:

protected openSettingsDialog() {
  this.dialog.open(NotificationSettingsComponent, {
    width: '28rem',
    panelClass: 'settings-dialog',
  });
}

The component renders, but it is disconnected:

It does not receive the user input.

It does not sync the enabled model input value.

And the parent does not listen for the saved output.

So the goal is simple: use the same component API inside the dialog that we already use inline.

The Reusable Component

Here’s the notification settings component:

@Component({
  selector: 'app-notification-settings',
  imports: [MatButtonModule, MatSlideToggleModule],
  templateUrl: './notification-settings.html',
  styleUrl: './notification-settings.css',
})
export class NotificationSettingsComponent {
  readonly user = input<User | null>(null);
  readonly enabled = model(false);
  readonly saved = output<NotificationSettingsSaved>();

  protected save() {
    if (this.user()) {
      this.saved.emit({
        userId: this.user()!.id,
        enabled: this.enabled(),
      });
    }
  }
}

And here’s the template:

<section class="settings-card">
  <div>
    <h2>Notification Settings</h2>

    @if (user()) {
      <p>
        Manage email notifications for
        <strong>{{ user()!.name }}</strong>.
      </p>
    }
  </div>

  <mat-slide-toggle
    [checked]="enabled()"
    (change)="enabled.set($event.checked)">
    Email notifications
  </mat-slide-toggle>

  <button matButton="filled" (click)="save()">
    Save Settings
  </button>
</section>

The important thing here is that this component knows nothing about dialogs.

It does not inject MAT_DIALOG_DATA.

It does not need MatDialogRef.

It is just a regular Angular component with inputs, a model input, and an output.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Add Dialog Bindings

In Angular 22, MatDialog supports a new bindings array.

This lets us bind to the component that gets rendered inside the dialog using inputBinding(), outputBinding(), and twoWayBinding():

import {
  inputBinding,
  outputBinding,
  twoWayBinding,
} from '@angular/core';

// ...

protected openSettingsDialog() {
  this.dialog.open(NotificationSettingsComponent, {
    width: '28rem',
    panelClass: 'settings-dialog',
    bindings: [
      inputBinding('user', this.user),
      outputBinding<NotificationSettingsSaved>('saved', settings => {
        this.saveNotificationSettings(settings);
      }),
      twoWayBinding('enabled', this.notificationsEnabled),
    ],
  });
}

What Each Binding Does

This passes the current user into the dialog component:

inputBinding('user', this.user)

It is the programmatic version of this:

[user]="user()"

This listens for the save event:

outputBinding<NotificationSettingsSaved>('saved', settings => {
  this.saveNotificationSettings(settings);
})

It is the programmatic version of this:

(saved)="saveNotificationSettings($event)"

And this keeps the model input synced:

twoWayBinding('enabled', this.notificationsEnabled)

It is the programmatic version of this:

[(enabled)]="notificationsEnabled"

So now the dialog component receives the user, starts with the correct notification value, updates the parent signal when the toggle changes, and emits the same save event as the inline version.

The Final Result

Now we can use the same component in both places.

Inline:

<app-notification-settings
  [user]="user()"
  [(enabled)]="notificationsEnabled"
  (saved)="saveNotificationSettings($event)"
/>

And inside a dialog:

this.dialog.open(NotificationSettingsComponent, {
  width: '28rem',
  panelClass: 'settings-dialog',
  bindings: [
    inputBinding('user', this.user),
    outputBinding<NotificationSettingsSaved>('saved', settings => {
      this.saveNotificationSettings(settings);
    }),
    twoWayBinding('enabled', this.notificationsEnabled),
  ],
});

No wrapper component.

No dialog-specific API.

No manual component instance wiring.

Just one reusable component with a clean Angular API.

Final Thoughts

This is a small feature, but it makes dynamic components feel much more like components used directly in a template.

With inputBinding(), outputBinding(), and twoWayBinding(), Angular Material dialogs can now work with the same component contracts we already use everywhere else.

Build the component normally, then let the dialog bind to it.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

The Angular @switch Upgrades You Should Know About

Brian Treese — Fri, 29 May 2026 07:00:00 +0000

Angular's @switch block has become a lot more useful recently. With exhaustive type checking, Angular can now catch missing template states when a TypeScript union or enum changes. And with grouped cases, we can remove duplicate markup when multiple states render the same UI. In this post, I'll show both improvements using a real-world example.

The Problem: UI States Can Drift from Your Types

Let's start with a common pattern.

We have a support queue where each ticket has a status:

There are four possible statuses, and we’re modeling them with a TypeScript union:

type TicketStatus =
  | 'new'
  | 'in-progress'
  | 'resolved'
  | 'closed';

interface Ticket {
  id: number;
  title: string;
  customer: string;
  status: TicketStatus;
}

Then, we have a signal containing a list of tickets:

protected readonly tickets = signal<Ticket[]>([
  {
    id: 1024,
    title: 'User cannot reset password',
    customer: 'Acme Corp',
    status: 'new',
  },
  {
    id: 1025,
    title: 'Billing page shows incorrect total',
    customer: 'Northstar Health',
    status: 'in-progress',
  },
  {
    id: 1026,
    title: 'Exported report is missing rows',
    customer: 'Velocity Labs',
    status: 'resolved',
  },
  {
    id: 1027,
    title: 'Login button disabled after failed attempt',
    customer: 'Summit Bank',
    status: 'closed',
  },
  {
    id: 1028,
    title: 'Production checkout error for enterprise account',
    customer: 'Atlas Retail',
    status: 'new',
  }
]);

So far, this is simple enough.

The status is strongly typed, and every ticket has to use one of the values from the TicketStatus union.

Now let's look at the template.

A Basic Angular @switch Block

In the template, we're looping over the tickets with @for and rendering each one as a card.

Inside each card, we use an Angular @switch block to render the status badge:

@switch (ticket.status) {
  @case ('new') {
    <span class="badge active">Active</span>
  }
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved') {
    <span class="badge done">Done</span>
  }
  @case ('closed') {
    <span class="badge done">Done</span>
  }
}

Then, a little lower in the card, we have another @switch block for the status message:

@switch (ticket.status) {
  @case ('new') {
    <p class="status-message active">
      This ticket is new and needs to be triaged.
    </p>
  }
  @case ('in-progress') {
    <p class="status-message active">
      Someone is actively working on this issue.
    </p>
  }
  @case ('resolved') {
    <p class="status-message done">
      The issue has been resolved and is waiting for confirmation.
    </p>
  }
  @case ('closed') {
    <p class="status-message done">
      This ticket is closed and no further action is needed.
    </p>
  }
}

This works, but there's a subtle problem.

Neither @switch block has a default case.

That means if the status ever becomes something other than these four values, Angular won't render anything for that part of the UI.

No badge.

No message.

Just a quiet little bug.

And those are the worst kind.

Adding a New Union Value

Now let's say the product changes.

We need to support urgent tickets, so we add a new status called "escalated":

type TicketStatus =
  | 'new'
  | 'in-progress'
  | 'resolved'
  | 'closed'
  | 'escalated';

Then we update one of the tickets to use the new status:

{
  id: 1028,
  title: 'Production checkout error for enterprise account',
  customer: 'Atlas Retail',
  status: 'escalated',
}

TypeScript is happy.

The app still compiles.

And at first glance, everything looks fine.

But when the escalated ticket renders, the card is incomplete:

The ticket title and customer show up, but the badge and message are missing because neither @switch block handles the new value.

The type changed.

The data changed.

But the template didn't keep up.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Exhaustive @switch Checking with @default never

This is where the newer @switch behavior helps.

Instead of adding a normal fallback UI, we can add this:

@default never;

This tells Angular that if the @switch reaches the default case, there should be no possible value left to handle.

So the badge @switch becomes this:

@switch (ticket.status) {
  @case ('new') {
    <span class="badge active">Active</span>
  }
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved') {
    <span class="badge done">Done</span>
  }
  @case ('closed') {
    <span class="badge done">Done</span>
  }
  @default never;
}

Now Angular can type-check the @switch exhaustively.

Since TicketStatus includes escalated, but the template doesn't handle it yet, Angular reports an error:

That's the win.

Instead of silently rendering broken UI, Angular forces us to update the template when the union type changes.

This is especially useful for UI states like:

ticket statuses
order states
payment states
deployment states
user invite states
feature flag states

Any time a known set of values drives intentional UI, exhaustive checking is worth considering.

To fix the error, we just need to add the missing escalated case in both @switch blocks.

Cleaning Up Duplicate @case Blocks

Now that the @switch is safer, let's make it cleaner.

In the badge @switch, new and in-progress both render the same badge:

@case ('new') {
  <span class="badge active">Active</span>
}
@case ('in-progress') {
  <span class="badge active">Active</span>
}

And resolved and closed both render the same badge too:

@case ('resolved') {
  <span class="badge done">Done</span>
}
@case ('closed') {
  <span class="badge done">Done</span>
}

That duplication isn't terrible in a small example, but it gets annoying fast in real templates.

Modern Angular lets us combine consecutive cases that render the same block.

So we can rewrite the badge @switch like this:

@switch (ticket.status) {
  @case ('new')
  @case ('in-progress') {
    <span class="badge active">Active</span>
  }
  @case ('resolved')
  @case ('closed') {
    <span class="badge done">Done</span>
  }
  @case ('escalated') {
    <span class="badge escalated">Escalated</span>
  }
  @default never;
}

Angular treats those consecutive @case statements as multiple conditions for the same template block.

So new and in-progress both render the Active badge, while resolved and closed both render the Done badge.

We get the same UI, but without repeating the same markup in multiple cases.

Fewer places to forget something later.

Safer Templates, Cleaner Code

That’s the real upgrade.

The UI stays the same, but the template becomes safer, cleaner, and easier to maintain.

Exhaustive checking helps Angular catch missing states, and grouped cases help remove duplicate markup.

Small change, safer template.

Get Ahead of Angular's Next Shift

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Better Loading Buttons in Angular Material v22

Brian Treese — Fri, 22 May 2026 07:00:00 +0000

Angular Material v22 adds a small but surprisingly useful improvement to buttons: built-in progress indicator support. Instead of manually swapping button text with a spinner and dealing with layout jumpiness, we can let the Material button directive manage the loading UI for us. In this post, I'll show you the old manual approach, why it creates a small UX issue, and how Angular Material v22 cleans it up.

A Simple Example

Let's start with a simple reports page:

We have a list of reports, and each report has a "Download" button using the matButton directive:

<section>
  <ul class="report-list">
    @for (report of reports(); track report.id) {
      <li class="report-row">
        <div class="report-info">
          <span class="report-name">{% raw %}{{ report.name }}{% endraw %}</span>
          <span class="report-meta">{% raw %}{{ report.date }} · {{ report.size }}{% endraw %}</span>
        </div>

        <button
          matButton="outlined"
          [disabled]="downloadingId() !== null"
          (click)="download(report)">
          Download
        </button>
      </li>
    }
  </ul>
</section>

Nothing unusual here.

But the loading UI is where this usually gets a little clunky.

The Old Way: Swap the Label for a Spinner

Before this new Angular Material v22 feature, a common approach was to conditionally replace the button label with a spinner.

First, we need to import the progress spinner in our component:

import { MatProgressSpinner } from '@angular/material/progress-spinner';

@Component({
  selector: 'app-report-list',
  templateUrl: './report-list.component.html',
  styleUrl: './report-list.component.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [MatButton, MatProgressSpinner],
})
export class ReportListComponent {
  // ...
}

Then we can update the button template to include the progress spinner conditionally when the report is downloading and the label when it isn't:

<button
  matButton="outlined"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  @if (downloadingId() === report.id) {
    <mat-progress-spinner
      mode="indeterminate"
      [diameter]="20"
      aria-label="Downloading"
    />
  } @else {
    Download
  }
</button>

Since this download doesn't expose a real percentage, mode="indeterminate" is the right fit here.

The diameter keeps the spinner small enough to fit inside the button, and the aria-label gives assistive technologies meaningful loading-state text since the visible label is being replaced.

And this works fine:

When the report is downloading, we show a spinner.

When it isn't, we show the label.

But there's still a UX issue.

The button shrinks when the label disappears and only the spinner remains.

That's because we're swapping the button's content entirely.

The text has one width, the spinner has another, and the button resizes to fit whatever is currently rendered.

It's not broken, but it feels a little janky.

And we had to write the conditional content logic ourselves.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

The Angular Material v22 Way: Use `showProgress` and `progressIndicator`

Angular Material v22 gives us another option.

Instead of swapping the label and spinner manually, both can live inside the button at the same time:

<button
  matButton="outlined"
  [showProgress]="downloadingId() === report.id"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  <mat-progress-spinner
    progressIndicator
    mode="indeterminate"
    [diameter]="20"
    aria-label="Downloading"
  />
  Download
</button>

There are two important pieces here.

First, the button gets the showProgress input, which is new in Angular Material v22:

[showProgress]="downloadingId() === report.id"

This tells the matButton directive when the progress UI should be shown.

In this case, we only want progress on the button for the report currently being downloaded.

Then, the spinner gets the progressIndicator attribute:

<mat-progress-spinner progressIndicator />

This marks the spinner as the button's projected progress indicator.

So instead of us writing an @if block to decide what appears, Angular Material controls that progress indicator slot for us.

Why This Feels Better

The important detail is that the normal button content stays in the layout, even when the progress indicator is visible.

So the button still knows how wide the "Download" label is, even while the spinner is being displayed.

That means we avoid the width jump caused by replacing the content completely.

The end result is a loading button that feels stable instead of jumpy.

This Does Not Have to Be a Material Spinner

One nice part of this API is that progressIndicator is a projection slot.

That means the projected content doesn't have to be mat-progress-spinner specifically.

You could use a custom loading element if that fits your design system better.

The main thing is to make sure the progress indicator still communicates meaningful loading-state information, especially when the visible button label is hidden or visually replaced.

Cleaner Loading Buttons in Angular Material

This is one of those Angular Material updates that isn't huge, but it's immediately useful.

The old approach works, but it usually means manually swapping content and accepting small layout issues.

With showProgress and progressIndicator, Angular Material gives us a built-in pattern for loading buttons that feels more polished with less template logic.

Want to Go Deeper With Modern Angular?

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Angular v22 WebMCP Tools Explained

Brian Treese — Fri, 15 May 2026 07:00:00 +0000

Angular v22 is experimenting with a new way to expose your app’s real capabilities to AI. Instead of letting models guess what's happening by scraping the DOM, we can now provide explicit, state-backed tools directly to the browser. This post walks through setting up WebMCP tools to bridge the gap between your Angular state and AI models like Gemini.

The Problem: AI Is Blind to App State

Most AI interactions with web apps today are limited to what the model can “see” in the rendered page.

This is brittle, surface-level, and completely misses the rich business logic living inside our services and signals.

Here's an example of a basic Angular app with no WebMCP tools registered:

We're using the WebMCP Inspector to see what tools are available and in this case, there are none:

In this app, we have data that doesn’t always live in the DOM, like retention risk calculations and hidden account metrics, that could help an AI provide much better assistance.

Without a structured way to expose these capabilities, the AI is just left guessing.

The Solution: Angular Signal State

Before we can give the AI tools, we need a clean source of truth.

In this app, we're using a UserStore service to manage our customer data.

We're using the new @Service() decorator and signals to expose profile information and computed business rules.

import { computed, Service, signal } from '@angular/core';
import { USER_ACCOUNTS, type UserKey } from './user.mock-data';

@Service()
export class UserStore {
  private readonly selectedUserKeyState = signal<UserKey>('sarah');

  readonly users = [
    { key: 'sarah', user: USER_ACCOUNTS.sarah.user },
    { key: 'marcus', user: USER_ACCOUNTS.marcus.user },
  ] as const;

  readonly selectedUserKey = this.selectedUserKeyState.asReadonly();
  readonly currentUser = computed(() => USER_ACCOUNTS[this.selectedUserKey()].user);
  readonly account = computed(() => USER_ACCOUNTS[this.selectedUserKey()].account);
  readonly isHighRiskAccount = computed(() => {
    const account = this.account();

    return (
      account.daysSinceLastLogin > 14 ||
      account.paymentFailures > 0 ||
      account.unresolvedPriorityTickets > 0
    );
  });

  selectUser(userKey: UserKey): void {
    this.selectedUserKeyState.set(userKey);
  }
}

The isHighRiskAccount signal is exactly the kind of "hidden" logic that an AI wouldn't know about just by looking at the UI.

It provides a clear, computed state based on multiple factors.

Creating WebMCP Tools with provideWebMcpTools()

Angular v22 introduces provideWebMcpTools(), a new API that registers WebMCP tools through the provider system.

This is powerful because these tools run inside the Angular injection context, meaning they can use dependency injection to access our services and signals.

Since this is still experimental, I’d treat this as a preview of where Angular and browser-based AI tooling are heading rather than a production recommendation today.

In this case, we register our tools globally in app.config.ts, but you should also be able to use it in route providers too:

import { ..., provideWebMcpTools } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideWebMcpTools([])
  ]
};

Each tool needs a name, a description for the AI to understand when to use it, an inputSchema, and an execute function.

Tool 1: Summarize the Current Customer

This tool provides a basic summary of the currently selected user.

It's intentionally simple to demonstrate the core wiring: Gemini asks for a summary, and Angular returns the current signal state.

{
  name: 'get_current_user_summary',
  description: 'Returns a summary of the current user.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const user = inject(UserStore).currentUser();

    return {
      content: [
        {
          type: 'text',
          text: `Name: ${user.name}
            Email: ${user.email}
            Plan: ${user.plan}
            Status: ${user.status}
            Last login: ${user.lastLogin}
            Open tickets: ${user.openTickets}`,
        },
      ],
    };
  },
},

Notice how the execute function directly injects UserStore and reads the currentUser signal.

The AI isn't scraping the DOM, it's calling a tool that accesses real Angular application state.

Tool 2: Analyze Retention Risk

This tool analyzes the current account and explains its retention risk.

It leverages the isHighRiskAccount computed signal we defined earlier.

{
  name: 'get_retention_risk',
  description: 'Analyzes the current account and explains retention risk.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const store = inject(UserStore);
    const user = store.currentUser();
    const account = store.account();
    const isHighRisk = store.isHighRiskAccount();

    return {
      content: [
        {
          type: 'text',
          text: isHighRisk ?
            // Is high risk
            `${user.name} is currently considered high risk.

            Reasons:
            - ${account.daysSinceLastLogin} days since last login
            - ${account.paymentFailures} recent payment failures
            - ${account.unresolvedPriorityTickets} unresolved priority ticket

            Recommended next action:                  
            Have customer success schedule a live onboarding session.` :

            // Is low risk
            `${user.name} is currently considered low risk.

            No significant warning signs detected.

            Recommended next action:
            No immediate action needed.`
        },
      ],
    };
  },
},

This demonstrates how the AI can use app-defined business logic to determine a customer’s risk level, providing actionable insights based on our application's internal state.

Tool 3: Draft a Customer Success Note

The third tool drafts a customer success outreach note.

The message content dynamically changes based on whether the isHighRiskAccount signal is true or false.

{
  name: 'draft_customer_success_note',
  description: 'Drafts a customer success outreach note for the current account.',
  inputSchema: { type: 'object', properties: {} },
  execute: () => {
    const store = inject(UserStore);
    const user = store.currentUser();
    const isHighRisk = store.isHighRiskAccount();

    return {
      content: [
        {
          type: 'text',
          text: isHighRisk ? 
            // Is high risk
            `Hi ${user.name},

            I noticed you may have run into a few issues recently, and I wanted to reach out personally to see if we can help.

            If you'd like, we can schedule a quick onboarding session to walk through the platform and help resolve any blockers.

            Thanks,
            Customer Success Team` : 

            // Is low risk
            `Hi ${user.name},

            Just wanted to check in and make sure everything is still going smoothly.

            Thanks for being a customer, and let us know if there’s anything we can help with.

            Thanks,
            Customer Success Team`
        },
      ],
    };
  },
}

This tool showcases how the same underlying Angular state can power multiple AI-callable capabilities, leading to context-aware and personalized AI responses.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Testing with the Inspector

Once registered, all three tools appear in the WebMCP Model Context Tool Inspector:

This allows the AI to see exactly what capabilities our app provides.

We can also see that Gemini already understands the tools available and has filled out the prompt for us:

When we ask Gemini questions like "Can you summarize this customer account?":

or "Is this customer at risk?":

or "Draft a follow-up message for this customer":

It doesn't try to scrape the page.

It calls the appropriate WebMCP tool, reads the signal state, and gives an accurate answer based on our actual business logic.

Why WebMCP Tools Matter for Angular Apps

By exposing app-defined capabilities, we turn the browser into a collaborative environment where the AI understands the context of our application.

The AI response changes as the underlying signal state changes.

This is the real value of WebMCP in Angular: safe, explicit, and reactive AI capabilities backed by your existing services and logic.

Get Ahead of Angular's Next Shift

Angular’s newest APIs are changing the way we build.

If you’re ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Angular’s New injectAsync() API Explained

Brian Treese — Fri, 08 May 2026 07:00:00 +0000

Angular v22 just made lazy-loading services much simpler. In this post, we'll explore how to leverage the new injectAsync() API to reduce your main bundle size and replace awkward lazy-loading workarounds. We’ll compare the older manual lazy-loading approach with Angular v22’s new injectAsync() API and see why the new pattern feels simpler and easier to reason about.

The Problem: Libraries Loading Too Early

When building Angular applications, it's common to include third-party libraries for various functionalities.

However, if these libraries are not loaded efficiently, they can increase your initial bundle size, leading to slower application startup times.

In our demo application, we're using highlight.js and Marked for markdown processing and syntax highlighting.

In this case, the post-editor component itself is needed immediately, but the markdown-processing dependency isn’t.

Even though the feature might not be immediately needed by the user, these libraries are loaded upfront, contributing to a 17.2kb main bundle:

This eager loading means users are paying for code they might never use, impacting performance.

Understanding the Markdown Service and its Eager Usage

Our demo application features a MarkdownService responsible for converting markdown content into HTML with syntax highlighting.

This service leverages marked, marked-highlight, and highlight.js to achieve this functionality:

import { Service } from '@angular/core';
import hljs from 'highlight.js/lib/common';
import { Marked } from 'marked';
import { markedHighlight } from 'marked-highlight';

@Service()
export class MarkdownService {
  private readonly marked = new Marked(
    markedHighlight({
      emptyLangClass: 'hljs',
      langPrefix: 'hljs language-',
      highlight(code, lang) {
        const language = hljs.getLanguage(lang) ? lang : 'plaintext';

        return hljs.highlight(code, { language }).value;
      },
    })
  );

  render(content: string): string {
    return this.marked.parse(content, { async: false });
  }
}

The core issue arises from how this service is consumed.

Initially, the post-editor component directly injects the MarkdownService:

import { Component, inject, signal } from '@angular/core';
import { MarkdownService } from '../markdown.service';

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');
  private markdownService = inject(MarkdownService);

  preview() {
    this.previewHtml.set(this.markdownService.render(this.content()));
  }
}

Because the MarkdownService is statically imported and injected into PostEditorComponent, Angular includes it and all its dependencies (marked, highlight.js) in the initial application bundle.

This happens regardless of whether the user has interacted with the markdown preview feature, leading to unnecessary upfront loading and a larger initial bundle size.

This is the "problem" we aim to solve with lazy loading.

The Old Way: Manually Lazy Loading an Angular Service

Historically, addressing eager loading for services involved a fair amount of manual setup.

To lazy load the MarkdownService and its dependencies, we would typically inject Angular's Injector and dynamically import the service.

It might look something like this:

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

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');
  private readonly injector = inject(Injector);
  private markdownServicePromise: Promise<MarkdownService> | null = null;

  async preview() {
    this.markdownServicePromise ??= import('../markdown.service').then(m =>
      this.injector.get(m.MarkdownService)
    );

    const markdownService = await this.markdownServicePromise;
    this.previewHtml.set(markdownService.render(this.content()));
  }
}

This approach solves the problem.

The bundle size is reduced, and highlight.js and marked are no longer part of the initial page load:

They are now dynamically loaded only when the preview() method is called:

However, this manual lazy loading introduces a lot of setup, making it less ergonomic and harder to maintain.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

The New Way: Replacing Boilerplate with injectAsync()

Angular v22 introduces injectAsync(), a new API that simplifies lazy loading services.

This function handles much of the orchestration we previously had to manage ourselves.

To refactor our post-editor component using injectAsync(), we can remove the Injector and the markdownServicePromise:

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

@Component({
  selector: 'app-post-editor',
  templateUrl: './post-editor.component.html',
  styleUrls: ['./post-editor.component.css'],
})
export class PostEditorComponent {
  protected readonly content = signal('');
  protected readonly previewHtml = signal('');

  private markdownService = injectAsync(
    () => import('../markdown.service').then(m => m.MarkdownService)
  );

  async preview() {
    const svc = await this.markdownService();
    this.previewHtml.set(svc.render(this.content()));
  }
}

With injectAsync(), we pass a loader function that dynamically imports the service.

Angular automatically captures the current injection context, resolves the service through dependency injection, and caches the result.

This makes the implementation simpler and easier to reason about.

Prefetch Lazy Dependencies with onIdle

injectAsync() also offers a prefetch option, allowing us to load dependencies early, but without blocking the initial bundle:

import { ..., onIdle } from '@angular/core';

private markdownService = injectAsync(
  () => import('../markdown.service').then(m => m.MarkdownService),
  { prefetch: onIdle }
);

By setting prefetch: onIdle, Angular will begin loading the dependency quietly in the background once the browser becomes idle.

This means the feature stays out of the initial bundle, but the user might never notice a loading delay because the service is already prefetched by the time they need it.

The Final Result

The application continues to function exactly as before, but with an optimized loading strategy.

The initial bundle size is smaller, and the markdown libraries are lazy-loaded, either on demand or prefetched during browser idle time.

This makes the pattern much more practical for real-world applications.

Get Ahead of Angular's Next Shift

Angular’s newest APIs are changing the way we build.

If you’re ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course
👉 Get it with YouTube membership

Additional Resources

Angular 22 @Service vs @Injectable (What You Need to Know)"

Brian Treese — Fri, 01 May 2026 07:00:00 +0000

Every Angular developer is familiar with @Injectable({ providedIn: 'root' }) for declaring services. While powerful, the @Injectable decorator supports many advanced configurations that are rarely used in typical application services. Angular 22 introduces a new @Service decorator designed to simplify service declaration for the most common use cases. This post will explore how it streamlines service creation and even enforces modern dependency injection patterns.

Version Disclaimer

This API is currently in pre-release, so some details may change before the final Angular 22 release.

The Problem: Overly Complex Service Declaration

For many years, declaring a service in Angular meant using the @Injectable decorator, often with the providedIn: 'root' option.

This pattern, while effective, includes configuration options that are seldom needed for straightforward application services.

Let's look at a very simple example of a service that fetches user data and posts from an API:

import { Injectable, signal } from '@angular/core';
import { HttpClient, httpResource } from '@angular/common/http';
import { Post, User } from './models';

const BASE = 'https://jsonplaceholder.typicode.com';

@Injectable({ providedIn: 'root' })
export class PostsService {
  selectedUserId = signal<number | null>(null);

  users = httpResource<User[]>(() => `${BASE}/users`, { defaultValue: [] });

  posts = httpResource<Post[]>(() => {
    const id = this.selectedUserId();
    if (!id) {
      return undefined;
    }
    return `${BASE}/posts?userId=${id}`;
  }, { defaultValue: [] });
}

This code works perfectly fine in current Angular versions.

The @Injectable decorator registers the service as a singleton in Angular's dependency injection system, making the same instance available wherever PostsService is injected.

The New Way: Angular 22 `@Service()` and `inject()`

Angular 22 introduces the @Service() decorator as a simpler, more opinionated alternative to @Injectable for common service patterns.

It’s intended for most app-level services, not a full replacement for every use case.

It assumes the most frequent scenario: a root-provided singleton service.

Step 1: Replacing `@Injectable` with `@Service`

Swapping from @Injectable to @Service is straightforward.

We simply replace the decorator and remove the providedIn: 'root' option, as it's the default behavior for @Service():

import { Service, signal } from '@angular/core'; // Note: Injectable is removed
import { HttpClient, httpResource } from '@angular/common/http';
import { Post, User } from './models';

const BASE = 'https://jsonplaceholder.typicode.com';

@Service() // ← providedIn: 'root' by default, no config needed
export class PostsService {
  selectedUserId = signal<number | null>(null);

  users = httpResource<User[]>(() => `${BASE}/users`, { defaultValue: [] });

  posts = httpResource<Post[]>(() => {
    const id = this.selectedUserId();
    if (!id) {
      return undefined;
    }
    return `${BASE}/posts?userId=${id}`;
  }, { defaultValue: [] });
}

With this change, the PostsService continues to function identically.

So, @Service() provides the same root-level singleton behavior without the explicit configuration.

Step 2: Enforcing `inject()` for Dependencies

One of the significant changes with @Service() is that it does not allow constructor injection.

If you attempt to inject a dependency via the constructor while using @Service(), Angular will throw an error.

This is an intentional guardrail, pushing developers towards the modern inject() function for dependency resolution.

Consider our PostsService with HttpClient injected in the constructor:

import { Service, signal } from '@angular/core';
import { HttpClient, httpResource } from '@angular/common/http';
// ...

@Service()
export class PostsService {
  // ...

  constructor(private http: HttpClient) { // This will cause an error with @Service()
  }
}

Attempting to run this will result in a compilation error:

The solution is to use the inject() function:

import { Service, signal, inject } from '@angular/core'; // Note: inject is imported
import { HttpClient, httpResource } from '@angular/common/http';
// ...

@Service()
export class PostsService {
  // ...

  private http = inject(HttpClient); // Using inject() for dependency
}

This pushes services toward a more functional and consistent dependency injection style, aligning with how modern Angular APIs are designed.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 3: Component-Scoped Services with `autoProvided: false`

While @Service() defaults to root-level provision, it also offers a powerful option for explicit service scoping: autoProvided: false.

This is particularly useful for services that manage UI-specific state and should have their lifetime tied to a particular component.

Let's look at a DraftPostService that manages the state for a draft form:

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

@Service({ autoProvided: false })  // I'll manage where this lives
export class DraftPostService {
  title = signal('');
  body = signal('');
  isValid = computed(() => this.title().length > 3 && this.body().length > 10);

  reset() {
    this.title.set('');
    this.body.set('');
  }
}

By setting autoProvided: false, we explicitly state that this service should not be automatically provided in the root injector.

Instead, its provision becomes the responsibility of the consumer.

This is ideal for UI state that should not persist across navigation or be globally accessible.

If we try to use this service in a component without providing it, we'll encounter a NullInjectorError:

This occurs because Angular's DI system cannot find a provider for DraftPostService in the injector tree.

To fix this, we need to explicitly provide the service at the component level:

import { Component, inject } from '@angular/core';
import { DraftPostService } from './draft-post.service';

@Component({
  selector: 'app-draft-panel',
  templateUrl: './draft-panel.component.html',
  styleUrl: './draft-panel.component.css',
  providers: [DraftPostService], // Service provided here
})
export class DraftPanelComponent {
  protected draft = inject(DraftPostService);
}

Now, the DraftPostService's lifetime is directly tied to the DraftPanelComponent.

When the component is created, the service is instantiated.

When it’s destroyed, the service is destroyed as well.

This makes the intent of the service's scope explicit and clear.

The Final Result

The @Service() decorator in Angular 22 offers a more streamlined and opinionated way to declare services, especially for the most common use cases.

It simplifies things, encourages the use of the inject() function for dependencies, and provides a clear mechanism for defining component-scoped services with autoProvided: false.

This isn't just about new syntax, it's about making the intent of your services more explicit and guiding developers toward modern Angular patterns.

By embracing @Service(), you can write cleaner, more maintainable code and better communicate the intended lifecycle and scope of your application's services.

Get Ahead of Angular's Next Shift

And speaking of modern patterns, if you’re trying to go deeper on those, especially things like signals and modern forms, I’ve got a new course available on Signal Forms that walks through how all of this fits together in real apps.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

This completely changed my Angular development workflow

Brian Treese — Fri, 24 Apr 2026 07:00:00 +0000

You ever use AI to generate Angular code that's almost right, but not quite? You end up renaming things, swapping decorators for signals, and rewriting *ngIf to @if every single time. Well, in this post, I'll show you how to use Cursor Skills to encode those fixes once and automate your Angular workflow for the whole team.

The Problem: Fixing "Almost Right" Code

When we use AI to generate Angular code, it often defaults to generic patterns.

We end up spending time manually refactoring it to match our specific architecture or modern Angular conventions like signals and standalone components.

Instead of repeating these manual fixes every time, we can use Cursor Skills to tell the AI exactly how we want our code built.

The Old Way: Manual Refactoring

Before Cursor Skills, we'd ask the AI for a component and get back something that maybe looked like this:

import { Component, Input, Output, EventEmitter } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-hello-world',
  standalone: true,
  imports: [CommonModule],
  template: `
    <section class="hello-world">
      <h2>Hello, world</h2>
      <p *ngIf="todayDate">{{ todayDate }}</p>
      <button type="button" (click)="onClick()">Update time</button>
    </section>
  `,
})
export class HelloWorldComponent {
  @Input() todayDate!: string;
  @Output() updateTime = new EventEmitter<string>();

  onClick() {
    this.updateTime.emit(new Date().toISOString());
  }
}

That's almost right, but every single line needs a touch-up:

Drop standalone: true (it's the default now)
Remove CommonModule
Swap @Input() / @Output() for input() / output()
And replace *ngIf with @if
And add OnPush change detection

Doing that by hand every time is slow, inconsistent, and worst of all, a guaranteed source of drift across a team.

Of course we can continue running the old component generation schematic but it's not as flexible as using AI.

The New Way: Project-Level Cursor Skills

Cursor Skills allow us to define reusable workflows that are committed directly into our source code.

This ensures every developer on the team follows the same standards.

Step 1: Setting Up the Skills Directory

We create a .cursor/skills directory in our project root.

Inside, we add a folder for each skill.

In this case we'll create an angular-component-generator folder.

Inside this folder, we then need to add a SKILL.md file inside it.

It's important to note that the name "SKILL" in this file must be capitalized for Cursor to recognize it as a skill.

This file is just Markdown with a bit of frontmatter.

The frontmatter tells Cursor when to use the skill, and the body is the "training material", the conventions, a template, and an example.

Here's the shape of our component-generator skill (with the full template omitted for brevity):

---
name: angular-component-generator
description: "Generates a modern Angular standalone component using signals, OnPush change detection, native control flow, and the latest Angular conventions. Use when the user asks to create, scaffold, or generate an Angular component."
---

# Angular Component Generator

Creates a single, modern Angular component file that follows current Angular (v20+) conventions.

## Conventions to Follow

- **Standalone** — do NOT set `standalone: true` (it's the default in v20+)
- **Change detection** — always set `changeDetection: ChangeDetectionStrategy.OnPush`
- **Inputs / outputs** — use `input()` and `output()` functions, not decorators
- **State** — use `signal()` for local state, `computed()` for derived state
- **Templates** — prefer inline `template`; use `@if` / `@for` / `@switch`
- **Injection** — use the `inject()` function, not constructor injection
- **Selector** — kebab-case with an `app-` prefix
- **Class name** — PascalCase ending in `Component`

## Workflow

1. Confirm the component name with the user (if not provided).
2. Generate the file using the template below.
3. Only split into separate `.html` / `.css` files if they're large enough to justify it.

## Template

// ... a reference template the AI uses as a starting point ...

## Don'ts

- Don't add `standalone: true`
- Don't use `NgModule`
- Don't use `@Input()` / `@Output()` decorators
- Don't use `*ngIf` / `*ngFor` / `*ngSwitch`
- Don't import `CommonModule` just to use control flow

The full version is in the project repo, but notice the pattern:

Describe the conventions
Provide a template
And list the things you never want to see

That last section is the one that makes the biggest difference in practice.

It directly counters the AI's default habits.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 2: Running the Skill

To use the skill, we open a new chat and invoke it by typing a forward slash followed by the skill name:

Cursor reads our SKILL.md and asks for anything missing.

In this case it looks like we need to provide some more information:

So here's what I added:

Then, after it does its work, we've got a new component:

Here's what the generated code looks like:

import { ChangeDetectionStrategy, Component, input, output } from '@angular/core';

@Component({
  selector: 'app-hello-world',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <section class="hello-world">
      <h2>Hello, world</h2>
      <p class="hello-world__date">{% raw %}{{ todayDate() }}{% endraw %}</p>
      <button type="button" (click)="emitUpdateTime()">Update time</button>
    </section>
  `,
  styles: `
    .hello-world {
      display: block;
    }

    .hello-world__date {
      margin: 0.5rem 0;
    }
  `,
})
export class HelloWorldComponent {
  readonly todayDate = input.required<string>();
  readonly updateTime = output<string>();

  protected emitUpdateTime(): void {
    this.updateTime.emit(new Date().toISOString());
  }
}

Compare that to the generic version from earlier:

No standalone: true
No CommonModule
No decorators
And no *ngIf

Exactly the code we would have spent time hand-editing, or following up with AI, generated for us in one shot.

Automating Unit Tests

And skills compose nicely.

Once we have one for generating components, the obvious next move is a matching skill for generating their tests.

For this we create a second folder, add-component-unit-tests, with its own SKILL.md that encodes how our team writes specs:

And here's what the code for that skill might look like (the spec template is abbreviated below for brevity):

---
name: add-component-unit-tests
description: Evaluates an Angular standalone component and generates unit tests that cover its inputs, outputs, signals, computed values, methods, and template behavior following unit-testing best practices. Use when the user asks to add, generate, scaffold, or write unit tests for an Angular component.
---

# Add Angular Component Unit Tests

Creates a `.component.spec.ts` file next to an Angular component that covers its public API and rendered behavior using Angular's `TestBed` and Jasmine.

## Assumptions

- Angular v20+ standalone components (no `NgModule`, no `standalone: true`).
- Inputs/outputs declared with `input()` / `input.required()` / `output()`.
- State with `signal()` and derived state with `computed()`.
- Native control flow (`@if`, `@for`, `@switch`) in templates.
- Host bindings/listeners declared via the `host` object.
- `ChangeDetectionStrategy.OnPush`.

## Workflow

1. **Read the component file** to build an inventory of inputs, outputs, signals, computed values, methods, host bindings, template elements, and injected dependencies.
2. **Derive the test plan** using the Test Plan Heuristics below. Briefly list the cases you will cover before writing code.
3. **Write the spec file** at `<folder>/<name>.component.spec.ts` using the Spec Template.
4. **Follow the Best Practices** — one behavior per test, arrange-act-assert, no snapshot tests for signals, no testing of private implementation details.
5. **Do not modify the component** to make it testable unless the user asks. If something is genuinely untestable, flag it instead of refactoring silently.

## Test Plan Heuristics

For each component, generate tests from this checklist. Skip categories that don't apply.

- **Creation**: component compiles and renders with required inputs set.
- **Inputs**: required inputs render the provided value; optional inputs use defaults; input changes propagate via `componentRef.setInput(...)` + `detectChanges()`.
- **Outputs**: each `output()` emits with the expected payload when its trigger fires.
- **Signals / computed**: initial value, updates when dependencies change, edge cases (empty, null, boundary).
- **Methods**: each method produces its documented side effect.
- **Template**: `@if` both branches, `@for` empty / one / many, `@switch` each case, event bindings, class/style bindings.
- **Host**: host classes, attributes, and listeners behave correctly.
- **Dependencies**: injected services replaced with fakes/spies via `providers`.

## Spec Template

// ... a reference spec template with TestBed setup, setInput for required inputs,
//     and sections for inputs / outputs / signals / template ...

## Best Practices

- **One behavior per test.** Each `it` asserts a single observable outcome.
- **Arrange / Act / Assert** — keep the three phases visually separated.
- **Test public behavior, not implementation.** Drive the component through inputs and DOM events; assert on outputs, rendered DOM, and public signals. Never test `private` members directly.
- **Use `setInput`, not field assignment.** Signal inputs must be set via `fixture.componentRef.setInput(name, value)`.
- **Call `fixture.detectChanges()`** after every state change that should affect the view.
- **Query the DOM with `By.css`** and assert against `textContent`, attributes, or element presence — not on stringified HTML.
- **Stub dependencies.** Replace injected services with jasmine spy objects via `{ provide: X, useValue: ... }` in `providers`.
- **Async.** Use `fakeAsync` + `tick` for timers, `await fixture.whenStable()` for promises.
- **No snapshot tests** for templates — write explicit assertions.
- **Deterministic.** No reliance on real dates, random values, or network. Inject or freeze those.
- **Descriptive names.** `it('emits selected with the row id when the row is clicked')`, not `it('works')`.

## Don'ts

- Don't assign signal inputs directly (`component.foo = ...`) — use `setInput`.
- Don't use `TestBed.overrideComponent` just to swap a template.
- Don't test `private` or `protected` members by casting to `any`.
- Don't assert on CSS selectors that include Angular-generated attributes (`_ngcontent-...`)
- Don't write a single giant `it` that exercises every behavior.
- Don't re-test framework behavior (that `@Input` works, that `output()` emits at all) — test your component's use of it.
- Don't modify the component under test to make it easier to test without asking first.

The full version, including the complete spec template and a worked example, is in the project repo.

Notice the same pattern as before:

Assumptions
A workflow
A template
Best practices
And a list of don'ts.

The don'ts are what stop the AI from falling back to legacy patterns like assigning signal inputs with component.foo = ... or casting to any to poke at private members.

With that in place, we run /add-component-unit-tests against our HelloWorldComponent and get a full spec file that seeds the required signal input, exercises the output with a payload assertion, and verifies the rendered template:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { By } from '@angular/platform-browser';
import { HelloWorldComponent } from './hello-world.component';

describe('HelloWorldComponent', () => {
  let fixture: ComponentFixture<HelloWorldComponent>;
  let component: HelloWorldComponent;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [HelloWorldComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(HelloWorldComponent);
    component = fixture.componentInstance;
    fixture.componentRef.setInput('todayDate', 'Monday, April 20, 2026');
    fixture.detectChanges();
  });

  it('creates', () => {
    expect(component).toBeTruthy();
  });

  describe('inputs', () => {
    it('renders the provided todayDate value', () => {
      const el = fixture.debugElement.query(By.css('.hello-world__date')).nativeElement;
      expect(el.textContent).toContain('Monday, April 20, 2026');
    });

    it('reflects updates to todayDate', () => {
      fixture.componentRef.setInput('todayDate', 'Tuesday, April 21, 2026');
      fixture.detectChanges();

      const el = fixture.debugElement.query(By.css('.hello-world__date')).nativeElement;
      expect(el.textContent).toContain('Tuesday, April 21, 2026');
    });
  });

  describe('outputs', () => {
    it('emits updateTime exactly once when the button is clicked', () => {
      const emitSpy = spyOn(component.updateTime, 'emit');
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;

      button.click();

      expect(emitSpy).toHaveBeenCalledTimes(1);
    });

    it('emits an ISO-formatted string as the updateTime payload', () => {
      const emitSpy = spyOn(component.updateTime, 'emit');
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;

      button.click();

      expect(emitSpy).toHaveBeenCalledWith(
        jasmine.stringMatching(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/),
      );
    });
  });

  describe('template', () => {
    it('renders the heading', () => {
      const heading = fixture.debugElement.query(By.css('h2')).nativeElement;
      expect(heading.textContent).toContain('Hello, world');
    });

    it('renders the date inside the .hello-world__date element', () => {
      const date = fixture.debugElement.query(By.css('.hello-world__date'));
      expect(date).not.toBeNull();
    });

    it('renders a button with the correct type and label', () => {
      const button = fixture.debugElement.query(By.css('button')).nativeElement as HTMLButtonElement;
      expect(button.type).toBe('button');
      expect(button.textContent).toContain('Update time');
    });
  });
});

A lot of the skill's rules are baked into this output:

The hardcoded date isn't magic, it comes from the setInput call in beforeEach. The skill enforces seeding required signal inputs before the first detectChanges, so the template has the data it needs to render.
The inputs block covers both the initial render and how the component responds to setInput updates, not just "does it work once?" but "does it react to change?"
The outputs block goes beyond "was it called?" and also asserts on the payload shape with jasmine.stringMatching(...).
The template block queries the rendered DOM for each meaningful element, heading, date container, button, rather than stringifying HTML or relying on snapshots.

All of that comes out of the box because we told the AI once, in the skill, how we expect our team's specs to look.

And then, we can run npm test to see the tests pass:

Skills vs. Rules: When to Use Which

If you're already using Cursor Rules (.cursor/rules/) or AGENTS.md, you might be wondering where Skills fit in.

The short version:

Rules are always-on guidance. They apply automatically to every request that matches their scope.
Skills are on-demand workflows. You invoke them explicitly when you want that specific behavior.

Rules are great for baseline conventions ("we use signals in this repo").

Skills are great for repeatable, parameterized tasks ("scaffold a new component", "generate tests for this file") where you want a guided, interactive workflow instead of passive nudging.

Final Thoughts: Automating Angular Workflows with Cursor Skills

Here’s the real takeaway: with skills, Cursor isn’t just generating code, it’s letting you encode how your team builds software.

And this is just the beginning.

Because next, we could apply something like this to migrate an existing reactive form over to signal forms, which gets way more interesting!

Get Ahead of Angular's Next Shift

And speaking of signal forms, they’re still pretty new and not widely adopted yet, which makes this a good time to get ahead of the curve.

I created a course that walks through everything in a real-world context if you want to get up to speed early.

You can access it either directly or through YouTube membership, depending on what works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

Better Numeric Inputs in Angular (Signal Forms + Angular 22)

Brian Treese — Fri, 17 Apr 2026 13:00:00 +0000

Signal Forms just fixed a subtle, but important, issue you’ve likely shipped without realizing. If you’re using <input type="number">, it's likely that you're introducing UX issues that only show up during real interaction. In this example, I'll show you a better approach that will be available in Angular v22.

Why Number Inputs Break UX in Angular Forms

Let's start with a typical setup.

We have a typed form model where age is a number and can be null:

interface SignupFormData {
  username: string;
  email: string;
  age: number | null;
}

Then we have a signal-backed model to store the form data where the age field is initialized to null:

protected model = signal<SignupFormData>({
  username: '',
  email: '',
  age: null,
});

After this, we have the form configuration created with the form() function from the Signal Forms API and our model signal:

protected signupForm = form(this.model, s => {
  required(s.username, { message: 'Username is required' });
  required(s.email, { message: 'Email is required' });
  required(s.age, { message: 'Age is required' });
});

This form is already setup with basic required() validators for the username, email, and age fields.

So this is what we're starting with.

Now let's finish adding the logic for the age field.

First, we want to prevent folks from joining if they're under 18, so let's add a min() validator.

min(s.age, 18, { message: 'You must be at least 18' });

Then, we want to ensure the age entered is valid.

If it's greater than 120, it's probably not valid, so let's add a max() validator:

max(s.age, 120, { message: 'Please enter a valid age' });

That’s all we need here.

Now let’s switch over to the template and add the field itself.

Since age will always be a number, we should use a number input, right?

Let's try it!

We'll add a number type input and bind it to the age field using the formField directive.

<input 
  type="number" 
  [formField]="signupForm.age" />

Now, this probably looks correct, but it really isn’t.

This is one of those cases where the default looks right but causes subtle issues in real use.

For one, the browser will automatically add a spinner control to the input:

These are rarely useful except in cases where you actually have an incremental number.

Which maybe you could argue we have here, but who wants to enter their age this way?

Also, if you use your mousewheel over the input, it will change the value too.

In our case this isn't too bad but think of something like a postal code or credit card CVV number.

It just wouldn't make sense.

And this isn't just something I'm making up, MDN explicitly recommends avoiding number inputs in many cases.

So, let's switch over to the recommended approach.

Step 1: Switch to a Text Input

For this, all we need to do is replace this:

<input 
  type="number" 
  [formField]="signupForm.age" />

With this:

<input 
  type="text" 
  inputmode="numeric" 
  [formField]="signupForm.age" />

This removes browser-controlled behavior while still triggering the numeric keyboard on mobile thanks to the inputmode attribute.

At this point (pre-Angular 22), this breaks typing:

Step 2: Angular 22 Fix: Number ↔ Text Binding

Previously, with Signal Forms:

Text input → string
Model expects → number | null
Result → type mismatch

Angular 22 fixes this.

After upgrading, Signal Forms:

Accept text inputs for numeric fields
Convert values to number
Map empty input to null (not '')

This is the key improvement.

Step 3: Keep Validation in the Schema

If we want to strictly adhere to the MDN guidance we would add attributes like these:

<input 
  pattern="[0-9]*" 
  min="18" 
  max="120" />

But these aren’t needed here.

With Signal Forms:

Validation belongs in the schema
Template stays declarative

So we'll keep the validation where we have it, and we'll remove these attributes.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

Step 4: Restrict Input via Keyboard Handling

According to MDN, browsers are inconsistent at enforcing numeric input, even with the correct inputmode.

So we need to enforce it ourselves.

To do this, we'll add a (keydown) event handler to the input.

We'll call it onAgeKeydown and it will take a KeyboardEvent parameter.

<input
  type="text"
  inputmode="numeric"
  [formField]="signupForm.age"
  (keydown)="onAgeKeydown($event)"
/>

Then, we'll switch over to the component TypeScript and add this new method:

protected onAgeKeydown(event: KeyboardEvent) {
  const allowedKeys = [
    'Backspace',
    'Delete',
    'Tab',
    'Escape',
    'Enter',
    'ArrowLeft',
    'ArrowRight'
  ];

  if (allowedKeys.includes(event.key)) {
    return;
  }

  if (!/^\d$/.test(event.key)) {
    event.preventDefault();
  }
}

This ensures:

Only digits are entered
Navigation keys still work

The Final Result

So now, we no longer have the spinner UI or scroll-wheel side effects:

We still can't add any non-numeric characters.

If we add invalid age values, we'll get the validation errors we added earlier:

Then, when we clear the field, we'll get the correct null value:

Previously, a text field would give you an empty string, but Angular now handles the conversion to null for us perfectly!

Clean, Typed Numeric Input in Angular 22

<input type="number"> looks correct but introduces avoidable UX issues.

Angular 22 removes the main blocker:

You can bind numeric models to text inputs cleanly
You retain strict typing and schema validation

For real applications, this is the better default (in many cases):

type="text"
inputmode="numeric"
Schema validation
Explicit keyboard handling

It’s a small change that eliminates a class of subtle UX bugs that often slip through reviews.

Taking This Further with Signal Forms

This example is just one piece of what Signal Forms are starting to simplify.

If you want to go deeper, I put together a full course that walks through building real-world forms step by step.

You can access it either directly or through YouTube membership, depending on what works best for you:

👉 Buy the course

👉 Get it with YouTube membership

DEV Community: Brian Treese

Angular 22 hostDirectives De-Duplication Explained

The Problem: Shared Behavior Can Collide

Creating the Shared Tooltip Directive

Composing Tooltip Behavior Into a Copy Button

Reusing the Same Tooltip in a Pressable Directive

Applying Both Directives to the Same Button

Why This Used to Break

Angular 22 De-Duplicates Shared Host Directives

One Important Caveat: Aliases Still Matter

Why This Makes hostDirectives More Practical

Get Ahead of Angular's Next Shift

Additional Resources

Angular 22: Better Tab Animations in Material

The Problem With Shared Tab Animation Durations

The Old Way: One Duration for Everything

Making the Indicator Faster Creates the Opposite Problem

Angular 22: Separate Header and Body Durations

When This Is Actually Useful

Get Ahead of Angular's Next Shift

Additional Resources

Angular 22: linkedSignal() Can Now Write Back to State

The Problem: Editing Nested Signal State

Before Angular 22: Reading Was Clean, Writing Wasn't

Angular 22: Add a Custom set() to linkedSignal()

Step 1: Use set() on the linkedSignal()

Before:

After:

Step 2: Use update() Too

The Final Result

Final Thoughts

Get Ahead of Angular's Next Shift

Additional Resources

New in Angular 22: Directives for CDK Component Portals

The Problem: Dynamic Components Need Host Behavior Too

How the Inline Portal Works

How DomPortalOutlet Renders the Floating Portal

Create a Directive for the Portal Host

Add a Directive to ComponentPortal

Reuse the Same Directive with DomPortalOutlet

The Result: Host Behavior Travels with the Portal

Final Thoughts

Get Ahead of Angular's Next Shift

Additional Resources

Angular Material Dialogs Now Support Real Component Bindings

The Problem

The Reusable Component

Add Dialog Bindings

What Each Binding Does

The Final Result

Final Thoughts

Get Ahead of Angular's Next Shift

Additional Resources

The Angular @switch Upgrades You Should Know About

The Problem: UI States Can Drift from Your Types

A Basic Angular @switch Block

Adding a New Union Value

Exhaustive @switch Checking with @default never

Cleaning Up Duplicate @case Blocks

Safer Templates, Cleaner Code

Get Ahead of Angular's Next Shift

Additional Resources

Better Loading Buttons in Angular Material v22

A Simple Example

The Old Way: Swap the Label for a Spinner

The Angular Material v22 Way: Use showProgress and progressIndicator

Why This Feels Better

This Does Not Have to Be a Material Spinner

Cleaner Loading Buttons in Angular Material

Want to Go Deeper With Modern Angular?

Additional Resources

Angular v22 WebMCP Tools Explained

The Problem: AI Is Blind to App State

The Solution: Angular Signal State

Creating WebMCP Tools with provideWebMcpTools()

Tool 1: Summarize the Current Customer

Tool 2: Analyze Retention Risk

Tool 3: Draft a Customer Success Note

Testing with the Inspector

Why WebMCP Tools Matter for Angular Apps

How `DomPortalOutlet` Renders the Floating Portal

Add a Directive to `ComponentPortal`

Reuse the Same Directive with `DomPortalOutlet`

The Angular Material v22 Way: Use `showProgress` and `progressIndicator`

The New Way: Angular 22 `@Service()` and `inject()`

Step 1: Replacing `@Injectable` with `@Service`

Step 2: Enforcing `inject()` for Dependencies

Step 3: Component-Scoped Services with `autoProvided: false`