DEV Community: Brian Treese

Are We Becoming AI Managers Instead of Developers?

Brian Treese — Sat, 05 Sep 2026 02:08:53 +0000

I've been doing front-end development for somewhere around 20 years now. During that time, I've watched the job change over and over again. New frameworks. New languages. New tooling. New ways of building and deploying software. But I don't think I've ever had to adapt as quickly as I have over the last few years. And lately I've found myself asking a strange question:

Am I becoming more of an AI manager than a software developer?

Because when I look at how I work today, I barely write code anymore.

I Barely Write Code Now

Even a year ago, I was still writing quite a bit of code myself.

Today, most of my development work looks very different.

I'll think through a feature, work out the requirements, ask an AI model to help me plan it, and then have an agent implement it.

Sometimes I'll use one model for planning and another for implementation. Sometimes I'll break the work into smaller pieces. Sometimes I'll experiment with different approaches depending on the complexity of the problem or how much context I'm working with.

Then I review the result.

I make sure it works.

I make sure the code makes sense.

I make sure it's maintainable.

And if something looks strange, I start asking questions.

That's increasingly what software development looks like for me.

So am I developing software?

Or am I managing AI that develops software?

At this point, the answer might be a little bit of both.

I Thought This Would Make the Job Worse

When AI coding tools first started getting good, I wasn't particularly excited about this version of the future.

One of my first thoughts was...

Great. So now I'm just going to review code all day?

Code review has never been my favorite part of the job.

The idea that AI would write everything while I sat there inspecting somebody else's work didn't sound especially appealing.

But something unexpected happened as the tools improved and I got better at using them.

I started enjoying it.

Not necessarily because I enjoy reviewing generated code, but because there's a new problem to solve...

How effectively can I communicate what I want and get AI to produce it?

There's something pretty wild about describing a feature in one or two sentences and getting back something very close to what I would have built myself.

Sometimes, dare I say it, I even get something better than what I would have come up with.

Of course, I also get bad solutions.

That's part of the job too.

But when something that might have taken me several hours can suddenly be built, reviewed, adjusted, and finished in 20 minutes, it's hard not to find that exciting.

The problem-solving hasn't disappeared.

The problem has changed.

Experience Feels More Valuable Right Now

This is where things get complicated.

AI can generate code extremely quickly.

But being able to tell whether that code is good is still incredibly important.

I've spent years working with HTML, CSS, JavaScript, Angular, PHP, WordPress, jQuery, and plenty of other technologies along the way.

I've made bad architectural decisions.

I've chased bugs for hours.

I've implemented things one way, discovered why that approach didn't work, and rebuilt them another way.

I've accumulated a huge collection of mistakes.

And oddly enough, those mistakes are incredibly useful now.

They help me recognize when generated code looks wrong.

They help me ask better questions.

They help me understand when an AI is solving the wrong problem even if the code itself looks perfectly reasonable.

Right now, that experience gives experienced developers an interesting advantage.

We can let AI handle more of the implementation while leaning heavily on the judgment we've developed over the years.

But that raises another uncomfortable question.

How Do Junior Developers Get That Experience?

This is probably the part I struggle with the most.

A lot of the work we traditionally gave junior developers is exactly the type of work AI is becoming really good at.

Refactor this component.

Update these usages.

Write this utility.

Fix this bug.

Add this small feature.

Those tasks weren't always glamorous, but they were important.

You learned by doing them.

You made mistakes.

You ran into weird edge cases.

You discovered that the solution you thought was obvious wasn't actually very good.

Over time, all of those experiences made you a better developer.

So what happens when AI starts doing a large portion of that work?

How does a developer who is just getting started build the judgment required to evaluate what AI produces?

I don't have a great answer yet.

AI can absolutely help someone learn faster than we could in the past. You can ask questions instantly, explore unfamiliar code, generate examples, compare approaches, and have complicated ideas explained in seconds.

That's incredible.

But there's a catch.

You can't assume what you're learning from AI is 100% correct.

You still need enough understanding to question the answers.

That's a strange place for new developers to be.

Maybe Learning Isn't Actually That Different

At the same time, maybe some parts of becoming a developer haven't changed as much as we think.

When I was getting started, building things was basically my hobby.

I built websites for family.

I built websites for friends.

If I heard somebody needed a website, I'd probably offer to build it.

Sometimes I barely charged anything.

Sometimes I didn't charge at all.

I wasn't doing it because it was an efficient way to run a business.

I was doing it because I wanted experience.

Every project taught me something new, and eventually those projects became a portfolio that helped me get real work.

If I were starting today, I think I'd probably do the same thing.

The difference is that I'd have AI sitting next to me while I did it.

That could actually make it possible to explore more ideas, build more projects, and learn faster.

But I'd still need to stay curious about what was being generated instead of blindly accepting it.

If AI Writes It, I'm Still Responsible for It

At least for now, I have a pretty simple rule for professional software development...

If AI writes something and I don't understand what it's doing or why it's there, I'm probably leaning on AI too much.

I don't necessarily need to remember every API from memory.

I don't need to manually type every line.

But if I'm putting something into production, I should be able to explain what it does.

I should understand the decisions being made.

And I should be able to recognize when something doesn't look right.

That means keeping up with the technologies I'm using is still important.

When frameworks evolve, I need to know about it.

When better patterns emerge, I need to understand them.

And when AI produces something that feels strange, I need to question it.

Sometimes that means asking another model.

Sometimes it means digging into documentation.

Sometimes it means throwing the implementation away and trying something different.

The AI can do a lot of the typing.

I still own the result.

Are We More Productive, or Is More Just Expected of Us?

AI definitely makes me faster.

I don't think I'm suddenly a 100x developer, but I can solve certain problems dramatically faster than I could before.

I've worked through some complicated problems recently that would have taken me significantly longer without AI.

The frustrating part of development where you stare at a problem for hours thinking...

How am I possibly going to make this work?

...happens less often.

You can explore several possible solutions quickly.

You can ask for alternatives.

You can test assumptions.

You can iterate much faster.

That's great.

But there's another side to it.

When everyone knows developers can move faster, expectations move too.

If a task that used to take a day can now take an hour, nobody is going to keep planning as though it takes a day forever.

So yes, AI makes us more productive.

But it probably also means more is expected of us.

That's not necessarily unreasonable.

The tools changed.

The amount of work we're capable of doing changed with them.

What Happens When Coding Becomes Cheap?

This might be the biggest question of all.

What becomes valuable when producing code becomes incredibly cheap?

For most of my career, knowing how to turn an idea into working software was a relatively scarce skill.

That's changing.

Today, someone with very little programming experience can already describe an idea and produce something surprisingly functional.

Those tools are only getting better.

So maybe the valuable part of software development increasingly becomes everything surrounding the code.

Understanding the problem.

Understanding the user.

Making good product decisions.

Knowing what should be built.

Knowing what shouldn't be built.

Recognizing bad solutions.

Designing systems that can survive beyond the first demo.

Making tradeoffs.

Judgment.

Right now, experience plays a massive role in all of that.

But even that could change.

Models are improving so quickly that it's difficult to confidently predict what any of this looks like a few years from now.

Maybe eventually the implementation becomes something we barely think about at all.

Maybe We Become Product Builders

There's a future I can imagine where developers become less concerned with the actual mechanics of producing code.

In some ways, that wouldn't be unprecedented.

Think about working on a car.

Changing your own oil isn't particularly difficult.

Neither are plenty of other basic maintenance tasks.

But most people still take their car to a mechanic.

It's not because changing oil has become impossible.

It's because we created an abstraction above that work.

People care that the car works.

They don't necessarily care about performing every step required to keep it working.

Software could eventually move in a similar direction.

Maybe the important skill becomes turning a business problem into a working product, while the lower-level implementation becomes increasingly automated.

At that point, maybe we're not really "coders" anymore.

Maybe we're product builders.

And maybe that's fine.

Would My Old Self Recognize This as Software Development?

Absolutely not.

If you showed me my current workflow ten years ago, I'm not sure I would have called it software development.

I'm describing things in plain English.

I'm asking agents to make changes.

I'm reviewing generated implementations.

I'm having conversations with software that writes software.

It's weird.

But I still think I'm developing.

The game has changed.

We're solving the same kinds of problems, but we're solving them differently.

And unlike many of the changes I've seen throughout my career, this one isn't happening incrementally.

It feels like the tablecloth is being pulled out from underneath us.

Every month the tools get better.

Every month the workflow changes a little more.

We're adapting constantly.

Do I Actually Like This Version of the Job?

Surprisingly, yes.

There have definitely been moments where I've wondered what all of this means for my career.

There probably will be plenty more.

But right now, this is one of the most interesting periods I've experienced as a software developer.

Software development has always attracted people who like solving problems.

That's still what I'm doing.

I'm still thinking creatively.

I'm still figuring out how things should work.

I'm still building things people need.

I'm just doing it with an entirely different set of tools.

And I've found a new kind of enjoyment in seeing just how effectively I can use those tools.

So maybe I am becoming an AI manager.

Maybe we're all becoming something slightly different from what we used to call a developer.

I'm not sure the terminology matters that much yet.

What matters is that we're still building.

The bigger question is whether you like this version of the job.

Because I think we're going to be seeing a lot more of it.

AI Has Made Me Faster, But Has It Made Me Worse?

Brian Treese — Fri, 28 Aug 2026 19:00:00 +0000

AI has made me faster. A lot faster. But recently, I caught myself doing something that made me wonder whether that speed is coming at a cost.

I’ve been a front-end developer for roughly 20 years, and these days I use AI to write most of my code.

I’m still thinking through architecture, making technical decisions, reviewing what gets generated, and deciding what actually belongs in the codebase.

But I’m doing far less of the actual coding than I used to.

And every once in a while, I notice something that makes me wonder...

"Am I becoming a better developer, or am I just getting better at using AI?"

When I Realized Something Had Changed

Recently, I was working on some animations in an Angular project.

I was using AI to help with the implementation, and it generated some CSS using a property that I knew was relatively new.

My immediate reaction was...

“Is this actually supported by all the browsers we need to support?”

A few years ago, I probably would have known the answer already.

I probably would have opened caniuse.com, checked the support table, and moved on.

But I would've also been the one intentionally reaching for it to build out the solution myself.

This time, I just asked the AI.

It told me the browser support was good, gave me some statistics, and I accepted the answer.

That was the moment where I stopped and thought...

"Wait… am I getting worse at this?"

Not because the AI gave me a bad answer. It didn’t.

The uncomfortable part was that I didn’t really feel the need to verify it myself.

I’m Learning Different Things Now

Web development has always required us to keep learning.

When I started, my focus was heavily on HTML and CSS. Then JavaScript became a bigger part of my work. Then frameworks like Angular became central to what I was doing.

There was always something new to understand.

That part hasn’t changed.

What has changed is where a lot of my attention goes.

I still care about browser APIs, Angular features, CSS, performance, accessibility, and all the normal things that come with front-end development.

But now I’m also spending a lot of time trying to understand AI tools.

Which models are better for which tasks?

How should I structure a prompt?

How much context should I give it?

Should I let it make a larger change or break the problem into smaller pieces?

When should I trust it, and when should I push back?

Those are development skills now too, whether we like it or not.

And because AI is changing so quickly, there’s a lot to keep up with.

Am I Actually Getting Worse?

I think this is where the question gets more complicated.

If you asked me whether I’m becoming better at manually writing code, the answer is probably no.

I’m doing less of it.

So I’m sure there are things I could once recall immediately that I now might have to look up (or ask AI).

But I don’t think that automatically means I’m becoming worse as a developer.

Because at the same time, I’m getting better at other parts of development.

I’m spending more time thinking about the shape of the solution before any code gets written.

I’m reviewing implementations more critically.

I’m deciding what should change, what shouldn’t change, and whether the code AI generated actually solves the problem in the right way.

And sometimes AI shows me something I genuinely wouldn’t have thought of myself.

It might find an edge case I missed.

It might use an approach that is cleaner than the one I had in mind.

It might introduce me to an API or technique I haven’t used before.

When that happens, I’m still learning.

Just in a different way.

AI as a Pair Programmer

That’s probably the best way I can describe how I use AI today.

It feels a lot like pair programming.

Except instead of sitting next to another developer and taking turns writing code, I’m describing the problem, reviewing the implementation, correcting mistakes, and refining the solution.

Sometimes the AI gets it wrong.

Sometimes it misunderstands what I’m asking.

Sometimes it generates something way more complicated than it needs to be.

And I have to recognize that and fix it.

Other times, it produces something better than what I would have written myself.

That doesn’t make me feel like I’ve lost control.

I still decide what gets used.

I still decide how much of the problem I want AI to handle.

Sometimes I ask it for a tiny change.

Sometimes I let it build out a larger feature.

Sometimes I reject the whole thing and start over.

The tool is powerful, but I’m still responsible for the result.

This Is Probably Very Different for Junior Developers

I also think experience changes this conversation quite a bit.

I’ve spent two decades writing code, debugging bad solutions, making architectural mistakes, refactoring things I thought were good ideas at the time, and learning what tends to go wrong.

That experience gives me a pretty good filter for evaluating what AI produces.

Someone at the beginning of their career doesn’t have that yet.

And I think that’s what makes this moment especially difficult for junior developers.

They need to build that experience.

They need to struggle through problems.

They need to write things that don’t work and understand why they don’t work.

They need to learn what good code looks like.

But at the same time, they’re entering an industry where they’re probably going to be expected to use AI.

The bigger challenge is figuring out how junior developers can use AI without skipping the learning that eventually gives them good judgment.

I’m not sure we’ve figured that out yet.

Maybe the Job Is Just Changing

For a long time, being a good developer meant knowing how to translate a solution into code.

That still matters today.

But I’m not convinced it will matter in exactly the same way forever.

If AI keeps improving, I wouldn’t be surprised if we spend less time thinking about the mechanics of writing code and more time thinking about the system around it.

What should we build?

How should it behave?

How should the pieces fit together?

What are the tradeoffs?

What could go wrong?

Is the implementation actually correct?

Is it maintainable?

Does it solve the right problem?

Those questions aren’t going away just because AI can generate code.

If anything, they may become more important.

So yes, in some ways I may be losing some manual coding sharpness.

But I’m also gaining new skills, learning from AI-generated solutions, and spending more time on parts of development that I think are becoming increasingly important.

That doesn’t feel like becoming worse as a developer.

It feels like becoming a different kind of developer.

And maybe that’s the real question.

Are we actually getting worse at development, or are the skills that define a good developer simply changing?

What is 20 years of coding experience worth now?

Brian Treese — Mon, 24 Aug 2026 19:00:00 +0000

I’ve been a front-end developer for more than 20 years now. For the last decade or so, most of my work has centered around Angular. I’ve spent a huge part of my career learning how to write better code, debug faster, understand architecture, recognize patterns, and generally become a more capable developer.

For a long time, that experience felt like a pretty clear advantage.

Now I’m not so sure what that advantage is supposed to look like.

AI has changed the way I work enough that I sometimes find myself wondering what 20 years of coding experience is actually worth when so much of the coding itself can now be done for me.

And depending on the day, I can feel really excited about that or pretty uneasy about it.

I Barely Write Code the Way I Used To

One of the strangest changes for me is that I rarely spend much time manually writing code anymore.

Most of the time, I’m essentially coding in plain English.

I’ll explain what I want to accomplish, let AI take a pass at it, review what it produced, and then continue refining it through conversation.

A few years ago, I probably would’ve hated that idea.

I used to enjoy being the person who could sit down and build something by hand. There was a certain satisfaction in knowing the APIs, understanding the framework, and being able to turn an idea into working code myself.

If I’m being completely transparent, I probably took some pride in feeling like I was better at that than a lot of other developers.

AI has changed that feeling quite a bit.

The interesting part, though, is that I don’t feel like my experience has become useless.

I feel like I’m just using it differently.

So What Are 20 Years of Experience Worth Now?

The AI can write the code.

What it can’t consistently do, at least in my experience, is know whether the code it wrote is actually the right code.

That’s where the experience still matters.

When AI gives me an implementation, I’m constantly evaluating it.

Does this fit the architecture?

Is this solving the actual problem?

Did it introduce unnecessary complexity?

Is there already something in the codebase we should be using?

What else does this change affect?

Is this going to create a problem six months from now?

Those questions aren’t really about syntax.

They’re about judgment.

And a lot of that judgment comes from years of building things, breaking things, maintaining things, refactoring bad decisions, and learning what tends to work in real applications.

In that sense, AI hasn’t made my experience irrelevant.

It may actually be forcing me to rely on the parts of that experience that matter most.

AI Works Best for Me in Small Chunks

I’ve also found that the way I use AI matters a lot.

I see plenty of demos where someone gives an agent a large feature, walks away, and comes back to a finished implementation.

That hasn’t really been my experience.

What works best for me is keeping the tasks small.

I’ll give AI one focused piece of work, review it, make sure it’s right, and then move on to the next piece.

In a lot of ways, it’s not that different from how I would have built the feature myself.

I’m still thinking through the structure.

I’m still deciding what should happen next.

I’m still controlling the direction.

The difference is that AI is doing much more of the implementation work along the way.

That workflow has been surprisingly effective for me.

It’s faster, but more importantly, it can make me more thorough.

Sometimes I’ll ask AI to refactor something and it’ll notice another related area that needs to change that I might not have remembered immediately.

That part is genuinely useful.

I’m not suddenly 100 times more productive, but I can definitely get more done.

And in some ways, I actually enjoy the work more now.

AI Feels a Lot Like a Very Fast Junior Developer

The closest comparison I can make is that working with AI sometimes feels like working with an incredibly fast junior developer.

You explain what you need.

It goes off and does it almost immediately.

Then you look at what it came back with and say:

No, not quite.

Let’s do this differently.

Don’t add that.

Use this pattern instead.

You send it back, and a few seconds later it returns with another version.

That’s incredibly powerful.

But it also explains why I still don’t feel comfortable handing over large parts of a production application and simply trusting the result.

The speed is there.

The judgment isn’t always there.

The Big Agent Workflows Still Haven’t Clicked for Me

This is one area where I still feel like I might be missing something.

I see developers talking about multi-agent environments, autonomous coding workflows, and handing entire features over to AI.

I’ve tried versions of that.

Usually, I end up with a massive code review.

The AI touches more things than I expected. It makes architectural decisions I wouldn’t have made. It introduces abstractions I don’t necessarily want.

At that point, figuring out whether everything is correct can take longer than I expected.

So for now, I keep coming back to smaller, controlled iterations.

Maybe that changes.

Maybe other teams have already figured out much better agent workflows than I have.

If that’s you, I’d genuinely like to know what you’re doing differently.

What tools are you using?

How much context are you giving the agents?

How much review is still required afterward?

And are you really trusting these systems with large production features?

I’m interested in the workflows people are actually using every day, not just the ones that make for an impressive demo.

Do Experienced Developers Still Matter?

Right now, I think we do.

But I also think the reason we matter is changing.

Being able to write code quickly may become less valuable.

Knowing what should be built, how it should fit together, whether the implementation is good, and what risks are hiding inside it may become much more important.

Maybe the job shifts away from writing every line yourself and more toward directing, evaluating, and shaping what gets built.

I don’t know exactly where this ends.

And I don’t want to pretend that I do.

There are days when AI makes me incredibly excited about what I’m able to accomplish.

There are other days when I look at how fast all of this is moving and wonder what it means for the career I’ve spent more than two decades building.

For now, though, I still feel needed.

I still feel like the experience I’ve accumulated matters.

I’m just using it in a very different way than I expected.

That’s how I feel today, anyway.

Ask me again in a few weeks. 😂

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

DEV Community: Brian Treese

Are We Becoming AI Managers Instead of Developers?

I Barely Write Code Now

I Thought This Would Make the Job Worse

Experience Feels More Valuable Right Now

How Do Junior Developers Get That Experience?

Maybe Learning Isn't Actually That Different

If AI Writes It, I'm Still Responsible for It

Are We More Productive, or Is More Just Expected of Us?

What Happens When Coding Becomes Cheap?

Maybe We Become Product Builders

Would My Old Self Recognize This as Software Development?

Do I Actually Like This Version of the Job?

AI Has Made Me Faster, But Has It Made Me Worse?

When I Realized Something Had Changed

I’m Learning Different Things Now

Am I Actually Getting Worse?

AI as a Pair Programmer

This Is Probably Very Different for Junior Developers

Maybe the Job Is Just Changing

What is 20 years of coding experience worth now?

I Barely Write Code the Way I Used To

So What Are 20 Years of Experience Worth Now?

AI Works Best for Me in Small Chunks

AI Feels a Lot Like a Very Fast Junior Developer

The Big Agent Workflows Still Haven’t Clicked for Me

Do Experienced Developers Still Matter?

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

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`