DEV Community: Angular

What's New in Taiga UI v5: A Modern Angular UI Kit

Barsukov Nikita — Fri, 03 Apr 2026 07:30:49 +0000

Taiga UI is an Open Source Angular UI library that helps developers build modern, reliable user interfaces. We recently shipped the fifth major release, bringing a ton of architectural improvements and new capabilities. In this article, we'll take a deep dive into the highlights of version 5.0.0 and explain why you should plan your upgrade as soon as possible.

Fresh Minimum: Angular 19+

In this new major version of our libraries, we raised the minimum supported Angular version to 19 and above. This means we can take advantage of all the new features and improvements added since Angular 16 (the minimum supported version in the previous Taiga UI major). And the paradigm shift toward a signal-based style has changed a lot in our codebase.

Signal Inputs

All our hundreds of components and directives said goodbye to classic properties decorated with @Input() and switched to their signal-based counterpart — input. Previously, our code had a lot of getters that internally used a private class method decorated with @tuiPure for memoization. Here's a simplified example of that approach:

@Input({required: true})
fileName: string;

// Used in the template
// (potentially recalculated on every re-render)
get type(): string {
   return this.getType(this.file);
}

@tuiPure
private getType(file: string): string {
   const dot = file.lastIndexOf('.');

   return dot > 0 ? file.slice(dot) : '';
}

Now, with signal-based computed, getters are no longer needed, and we can write cleaner, more readable code without extra optimizations. computed takes care of memoization automatically.

file = input.required<string>();

type = computed(() => {
   const dot = file.name.lastIndexOf('.');

   return dot > 0 ? file.name.slice(dot) : '';
});

We're sending the @tuiPure decorator off into honorable retirement: you were a good friend and helper for many years — thank you!

Signal viewChild(-ren) / contentChild(-ren)

In Taiga components, we frequently used the @ViewChild(‑ren) and @ContentChild(‑ren) decorators. You decorate a property in a component — and the requested DOM element gets automatically assigned to it. A significant limitation of this approach was that these elements only became available in the AfterViewInit and AfterContentInit lifecycle hooks. As a result, constructs like this could pop up in our codebase:

@Component(...)
export class AnyComponent {
   private contentReady$ = new ReplaySubject<boolean>(1);

   children$ = this.contentReady$.pipe(
       switchMap(() => this.childrenQuery.changes),
   )

   @ContentChildren('ref')
   childrenQuery!: QueryList<any>;

   ngAfterContentInit() {
       this.contentReady$.next(true);
   }
}

The contentReady$ stream notifies all its observers that it's safe to proceed. The trick of creating such a stream made the code slightly more declarative compared to directly manipulating all observers inside a hook. But it still produced its fair share of boilerplate.

Signal-based viewChild(-ren) and contentChild(-ren) are a real game-changer. You can practically forget about the AfterViewInit and AfterContentInit hooks, because signals created via viewChild and contentChild know when to update on their own, and all their subscribers automatically recalculate reactively. All those lines from the old approach are replaced by a single built-in one-liner.

Signals Over RxJS

Even though our team deeply respects RxJS and is confident it'll be around for a long time, we genuinely fell in love with signals. We decided to make them the priority in our public API — not just because of their growing popularity in the Angular community, but because for many reactive tasks they're a much better fit than RxJS, letting us provide better support and write more optimal, understandable code.

Here are just a few examples of changes from the new major version — the updated TUI_NUMBER_FORMAT and TUI_DATE_FORMAT.

// Before
inject(TUI_NUMBER_FORMAT) // Observable<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Observable<TuiDateFormatSettings>

// After 
inject(TUI_NUMBER_FORMAT) // Signal<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Signal<TuiDateFormatSettings>

To sum up the thought about the dawn of the "signal era" in the Taiga codebase: we don't resist the new trends set by the Angular team. And most importantly, we don't prevent our users from seamlessly harnessing the full power of signals when building applications with Taiga UI!

We've already seen the benefits of the signal-based style firsthand. Less boilerplate, better performance, dramatically fewer Change Detection bugs, and improved support for Zoneless applications!

New Esbuild + Vite Build Engine

Another important change driven by raising the minimum Angular version is the switch to the modern Esbuild + Vite build engine. This move not only improved our own Developer Experience (build time during local development was significantly reduced), but also allowed us to catch bugs in YOUR Esbuild applications (the default for all new Angular apps) before we even release our libraries.

And these aren't just words — we've already fixed several esbuild incompatibility bugs related to circular dependencies (#12435 and #12438), as well as CSS selector specificity issues (#12544, #12543, #12553).

Control Flow

Before Control Flow appeared, the Taiga UI team had already been publishing the structural directive *tuiLet for many years, which allowed you to declare a local variable in a template. And as our company's codebase shows, this directive was used over 6,000 times. The local variable declaration approach was extremely popular. It has now been replaced by the new built-in @let syntax.

The Taiga *tuiLet directive is now gracefully retiring, making way for the built-in @let syntax — which, as a nice bonus, requires zero imports!

A Shiny New Component Showcase

We've significantly reworked the design and content of our documentation. It now features improved navigation and a more intuitive interface.

I'd also like to remind you that the engine behind our documentation is a reusable solution published as the npm package @taiga-ui/addon-doc. It's already actively used not only for Taiga UI docs, but also in other Taiga Family products: Maskito, Taiga Editor, Ng Morph, and Ng Draw Flow. This package keeps evolving and gaining new features (for example, a brand-new Table of Contents component was added in this release). You can always use @taiga-ui/addon-doc to build documentation for your own library!

Browser Bump

Here's a little secret: the favorite part of every major release for Taiga UI maintainers is bumping the minimum supported browser versions. It unlocks new capabilities and features that we happily use in our libraries to write even cleaner and more reliable code.

Already in Taiga UI v4, we set a course for adding RTL support to our libraries. That's right — we expanded our audience to include Middle Eastern and Central Asian products!
With the new browser support, we got access to an even wider list of logical CSS properties, such as inset, padding-inline, margin-inline, and many others.

RTL support has become even easier to maintain, and the code is more robust (since it's now handled by native logical CSS properties instead of our old fallbacks and workarounds).

We also got access to BigInt. It feels nice to finally have access to all JavaScript data types — at least by 2026! :D
We immediately put this to use and added BigInt support to our @maskito/kit library in the Number mask and in our Taiga InputNumber component.

Angular Animations — Goodbye!

Starting with Angular 20.2, the @angular/animations package has been marked as deprecated. And the official Angular documentation now reads as follows:

You can replace all animations based on @angular/animations with plain CSS or JS animation libraries. Removing @angular/animations from your application can significantly reduce the size of your JavaScript bundle. Native CSS animations generally offer superior performance, as they can benefit from hardware acceleration.

And we responded promptly. In Taiga UI v5, we completely dropped the @angular/animations package: all existing animations have been rewritten using pure native CSS, and @angular/animations has been entirely removed from the dependency list of our packages! No more mandatory provideAnimations() just to get Taiga UI up and running.

The trickiest part was natively rewriting the logic around the former :leave mechanism. Currently, there's no convenient CSS alternative for animating an element leaving the DOM without timers and boilerplate code. But my colleague found an elegant solution to this problem as well. The @taiga-ui/cdk library got a new Animated directive. Just slap this directive on any DOM element — when it appears or disappears, the element gets a CSS class tui-enter / tui-leave, and you can define any CSS animations for that class. All without code boilerplate and in the true Angular way!

It's also great that we're moving in the same direction as the Angular team. The Animated directive neatly anticipated the future syntax that the Angular team introduced very recently in their v21 announcement — animate.enter and animate.leave. Migrating from our solution to the built-in Angular syntax will be as simple as it gets — just replace the tuiAnimated directive on an element with animate.enter="tui-enter" and animate.leave="tui-leave" (and keep the CSS files unchanged).

A nice bonus: our Animated directive has been cherry-picked into the fourth major version of Taiga, so you can start gradually moving away from Angular animations in your app right now — even before you begin upgrading your Taiga UI version, and even if your app's Angular version is significantly older than 20.2. And when you upgrade Taiga to v5, @angular/animations will simply disappear from your node_modules.

Simplified Taiga UI Setup for Your Project

Inspired by the modern Angular naming conventions for DI utility functions (provideRouter, provideServerRendering, provideZoneChangeDetection, etc.), we decided to simplify the process of adding Taiga UI to your project. Now, to set up the DI tree, all you need is a single call to provideTaiga(), which automatically provides all the necessary dependencies and initial configurations for our components to work.

For you, it's just one function call, but under the hood it takes care of automatic font scaling, dark/light theme setup, and other internal configurations needed for Taiga UI components to function correctly!

New Text Fields Are Now a Stable API

We kicked off the large-scale text field refactoring back in the previous major version.
At that time, we moved all our old control versions into the @taiga-ui/legacy package (to ensure a smooth migration path for users to the new public API) and started rewriting each component from scratch using fresh design specs and modern Angular features (decomposition via host directives + signals).

The task turned out to be quite challenging and extremely labor-intensive, but the results will genuinely make you happy. The new text fields offer a declarative way to customize through HTML markup and a uniform public API across all types of controls. Once you understand the customization concepts for one type of text field, you can easily customize any other control — without even looking at the docs!

Another key feature of the new text fields is their openness. Everything you need is exposed, so you can bring even the wildest ideas to life. Just take a look at this InputDate example:

<tui-textfield>
  <label tuiLabel>Choose a date</label>
  <input tuiInputDate [formControl]="control" />

  <ng-container *tuiDropdown>
    <tui-calendar [markerHandler]="markerHandler" />

    <button
      tuiButton
      (click)="..."
    >
      Today
    </button>
  </ng-container>
</tui-textfield>

First, all the input parameters of the <tui-calendar /> component are fully at our disposal — no prop drilling like in the previous version of this control! Second, we can freely add any elements (even interactive ones!) to the calendar dropdown — for example, a "Today" button with a custom click handler!

And this applies to every type of text field (and there are over 15 of them!).
With the release of the fifth major version, our large-scale text field refactoring is officially complete. Their public API is fully stabilized, and the previous generation of these controls has been permanently removed from the @taiga-ui/legacy package.

For those who prefer gradual changes in life and code, we cherry-picked all important fixes for the new text fields into the fourth major version, making the migration to the new major as smooth as possible. Before upgrading to Taiga v5, you can iteratively update your codebase, mixing old and new text fields, so the upcoming migration is as comfortable and painless as it can be.

Improved Icon Component

In the previous major release announcement, I mentioned that for icons we moved away from the old approach of using <svg /> with the <use /> tag in favor of CSS masks.

Back then, the new approach was implemented in the Icon component and brought numerous benefits: the ability to store icons on a CDN and render them without DOM manipulations or a sanitizer, automatic browser caching, and a simplified way to scale icons.

But we didn't stop there and continued to develop this further.
Starting with the fifth major version, this component can do significantly more:

You can now control not only the icon size but also the stroke width of the icon's content. This capability is demonstrated really well in this interactive documentation example.
The updated component supports not only classic single-color icons but also multi-color and font-based icons! They're managed through the @tui, @img, and @font prefixes, and the component figures out under the hood how to render the icon based on its type: via CSS mask, background-image, or font + content on the :before pseudo-element. You can see it in action in this example.

And Much More!

Portals have been completely rewritten and streamlined into a single grid-based container. It's now even easier to customize dialogs, simpler to manage notifications and their subtypes (screen position, number of simultaneous instances), and easier to create your own custom portal entities through new abstract classes and services.
A new Popout service that simplifies displaying custom content in Picture-in-Picture mode or opening a piece of your application in an entirely new tab.
We stabilized the use of the CloseWatcher web API in Taiga dialogs. Now, when a dialog is open on an Android device and the user taps the browser's "Back" button, the dialog simply closes — instead of navigating to the previous route behind the open dialog.
A revamped Accordion. We're continuing the trend (that accompanies every Taiga major version) of minimal DOM element nesting in our components, which should make it easier for you to customize them and set native attributes like ARIA attributes or id — and now the accordion has joined the ranks of the "lucky ones."
Automatic font scaling is now enabled by default. Many users rely on iOS/Android system accessibility settings to increase the font size across all interfaces on their mobile devices — including web apps. Taiga components can read this system setting and adapt, making your interfaces comfortable for users with visual impairments.
We dropped the use of our custom decorators — you're free to build your application with any value of the TypeScript experimentalDecorators flag without worrying that Taiga UI components will stop working.
We're continuing to actively develop AI tooling support for working with Taiga UI components. Our MCP server now supports the new major version as well. We're also closely watching the development of WebMCP to integrate its support into our documentation when the time comes.

And a huge number of other improvements and new features that you can find in the release notes.

How to Upgrade?

We did our best to make the migration to the new version as smooth as possible. To that end, we've prepared a bunch of migration scripts that will automatically analyze your code and fix most breaking changes — all with a single console command! And anything that was too complex to fix automatically via AST manipulations has been annotated with comments right in the code — complete with hints and links so you can easily finish the migration on your own or with the help of AI agents.

Detailed instructions for running the migration schematics and the necessary preparation steps are available in our upgrade guide.

If you run into any issues or bugs during the upgrade, don't hesitate to open an issue or ask a question in our Telegram community. The Taiga team can't wait for your feedback!

See You Soon!

To wrap up, let me just give you a little sneak peek at our future plans.

Very soon you'll see revamped date picker components — our design team has already delivered fresh design specs with a more modern look for the calendars. During the rework, we plan to address the accumulated feature requests around their customization.

We're also keeping a close eye on the development of signal-based forms. As of this writing, the new API is still rough around the edges and continues to undergo changes. As soon as it fully stabilizes, we'll make sure Taiga controls support them.

Finally, one of our big goals for this year is to keep pushing the accessibility of our components forward! All Taiga components traditionally support keyboard navigation, screen readers, and other assistive technologies, but accessibility is a broader topic and we plan to dedicate even more attention to it this year.

See you in upcoming articles and releases!

And a reminder: the easiest way to say thank you is to give us a star on GitHub.

Angular 21 & MCP: The End of "Manual" Migrations?

Antonio Cardenas — Sat, 13 Dec 2025 07:48:04 +0000

Angular 21 introduces the Model Context Protocol (MCP) server.

Learn how to connect your AI editor directly to the Angular CLI to automate upgrades, refactoring, and architectural shifts like Zoneless.

We used to treat AI like a smart stranger. We would copy-paste error messages or file contents into ChatGPT, hoping it understood our project's architecture. It was helpful, but it was blind.

With Angular 21, that stranger has moved into your house.

The release of the Angular CLI MCP Server (ng mcp) marks a fundamental shift in how we maintain applications. It isn't just a new command; it's a protocol that allows AI agents (like Cursor, Windsurf, or VS Code Copilot) to "interview" your project, understand your specific constraints, and run migrations that actually compile.

Here is why the "manual migration" era might be ending and how to survive the new Agentic Workflow.

What is MCP? (The "USB Port" for AI)

The Model Context Protocol (MCP) is an open standard that lets AI models connect to local tools and data.

Think of it this way:

Before MCP: You paste angular.json into the chat so the AI knows your file structure.

After MCP: The AI simply asks the Angular CLI, "Hey, list all the projects in this workspace," and the CLI responds with the exact structure, build targets, and library dependencies.

In Angular 21, the CLI is an MCP server. It exposes "tools" that your AI editor can call directly.

Setting It Up: 5 Minutes to "Agentic" Angular

The setup is surprisingly trivial because the Angular team baked it directly into the CLI.

1. Initialize the Server

In your Angular 21 workspace terminal:

ng mcp

This command doesn't start a daemon; it generates the configuration snippets you need for your specific IDE.

2. Connect Your Editor (e.g., Cursor)

If you are using Cursor (which you probably should be if you're interested in MCP), create or edit .cursor/mcp.json or if you are using Antigravity (which you probably should be if you're interested in MCP), create or edit .gemini/antigravity/mcp.json in your project root:

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

To double-check the CURSOR configuration, in cursor click in the three dots in the top right corner and select "Agent Settings."

then click in "Tools & MCP." if everything is configured correctly, you should see angular as installed MCP server listed with the name of the tool as "ai_tutor."

To double-check the Antigravity configuration, in Antigravity click on the three dots in the top right corner and select "MCP Servers."

then you will see 'angular-cli' listed, and you can manage the tools, having the ability to enable or disable them.

[!NOTE]
The -y flag is crucial to prevent the "Press y to install" prompt from hanging the background process.

Available Tools

The Angular CLI MCP server provides several tools to assist you in your development workflow. By default, the following tools are enabled:

Tool Name	Read-Only	Local-Only
`ai_tutor`	✅	❌
`find_examples`	✅	❌
`get_best_practices`	✅	❌
`list_projects`	✅	✅
`angular.json`	✅	✅
`onpush_zoneless_migration`	✅	✅
`search_documentation`	✅	❌

Experimental Tools

Some tools are provided in experimental/preview status. You can enable them explicitly:

Tool Name	Read-Only	Local-Only
`modernize`	✅	❌

[!NOTE]
The -y flag is crucial to prevent the "Press y to install" prompt from hanging the background process.

The "Killer App": Context-Aware Migrations

Why go through this trouble? Because Context-Aware Migrations blow standard schematics out of the water.

Traditional ng update scripts are rigid. They follow a strict "If A, then B" logic. If your architecture is weird (and let's be honest, every enterprise architecture is weird), the script breaks or produces code you have to rewrite.

The MCP Server exposes tools that change this dynamic:

Tool 1: `get_best_practices`

The AI can fetch the current Angular team recommendations. It won't hallucinate that you should use SharedModule in 2025 because it "read it on a blog from 2021." It asks the CLI for the ground truth.

Tool 2: `onpush_zoneless_migration`

This is the big one for v21. Instead of blindly changing ChangeDetectionStrategy.Default to OnPush, the AI uses this tool to analyze your dependency graph.

The Workflow:

You: "Hey, I want to migrate user-profile.ts to Zoneless. Check if it's safe."

AI (Internal Thought): I need to check the component style. I'll call list_projects to find the root, then read the file.

AI (Internal Thought): I see an Observable subscription in ngOnInit. I'll check get_best_practices for handling async in Zoneless.

AI (Action): "I detected an unmanaged subscription. In Zoneless, this won't trigger a render. I recommend converting this user$ observable to a Signal using toSignal() before we switch the strategy."

It doesn't just apply a fix; it negotiates the refactor with you based on the framework's internal logic.

Tool 3: `search_documentation`

The AI doesn't need to guess API signatures. It queries the local offline documentation index provided by the MCP server.

Real-World Scenario: The "Legacy" Cleanup

Let's say you have an Angular 17-style component using HttpClientModule (deprecated approach) and RxJS for simple state.

Prompt to Cursor (with MCP active):

"Refactor dashboard.component.ts to align with Angular 21 best practices. Use the get_best_practices tool to verify your plan first."

What happens:

The AI calls get_best_practices and learns that standalone: true, inject(), and Signals are the standard.
It calls modernize (an experimental tool in v21) to run the standard schematics.
It manually cleans up the leftovers—converting constructor(private http: HttpClient) to private http = inject(HttpClient).
It converts your BehaviorSubject state to signal.

The result is code that looks like it was written in v21, not just patched to run in v21.

The Future: Continuous Maintenance

This release signals a change in how Google views the CLI. It's no longer just a build tool; it's an interface for agents.

In the near future, we likely won't "stop development" to upgrade. We will have a background agent running via MCP that opens PRs:

"I noticed you used a ControlValueAccessor here. I've created a PR to refactor this to the new Signal Forms input API."

"Angular v22 just dropped. I've updated your angular.json and verified your tests via vitest."

Summary: Don't Upgrade Alone

If you are moving to Angular 21, do not just run ng update and fight the compile errors manually.

Install the MCP server.
Let the AI map your project.
Ask it to plan the migration for you.

The code is still your responsibility, but the grunt work? That belongs to the machine now.

A Quick Vibe Code Experiment with Angular's MCP Server

Alisa — Thu, 13 Nov 2025 16:53:46 +0000

Angular has an experimental Model Context Protocol (MCP) server! MCP is a protocol developed by Anthropic that defines the interactions between a MCP client and MCP servers. Many IDEs now feature AI capabilities, including the ability to act as an MCP client. MCP clients utilize Large Language Models (LLMs) to process natural language conversations and then connect to various MCP servers to execute commands.

Let's use AI and Angular's MCP server to create a Todo app without writing any code and see how this experiment progresses. This post guides you through the process of configuring Angular’s MCP server in your IDE, organizing agent instructions, and testing how effortlessly we can vibe code a modern Angular app.

Pre-requisities

You'll need an IDE with access to AI capabilities. I'm using VS Code with Copilot. Copilot has a free plan and paid plans. For full disclosure, I'm using a paid plan and the GPT-5 mini LLM. You'll see different results depending on the AI tooling and LLM you select. I selected GPT-5 mini as it's considered an unlimited free request model.

Angular's MCP server

Angular provides valuable information on leveraging AI when building apps in their Build with AI documentation. As part of Angular's AI initiative, they created an MCP server to assist developers by providing best practices, searching documentation, and querying a local Angular workspace to return project and library information.

First, we must add the MCP server to our MCP client.

Set up the MCP server connection

In VS Code, open Build with agent mode. There's a little chat bubble icon with stars near the 🔍 Search bar. Press on the chat bubble icon to open the Chat pane.

Since I'm using VS Code, I'll follow the Use MCP servers in VS Code documentation. You need to add the MCP server manually to your mcp.json file. You can use Copilot's user interface to set this up, but I found it was easier to create the mcp.json file myself. You can have a per-workspace mcp.json file or set up a mcp.json file in your user settings. I want access to my MCP servers in all my projects, so I opted for the user-based mcp.json configuration.

You can use VS Code's Command Palette and search for MCP. You'll see options to open a workspace or a user. I opened my user configuration and added the JSON for VS Code, as documented in Angular. It looks like this.

{
  "servers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Are you more of a command-line person? Good news, Angular CLI has you covered. You can use the new ng mcp command to output the generic MCP server configuration instructions instead.

Use AI to check AI?

You'll want to ensure the Angular MCP server is connected and running. Why not prompt Copilot to verify the connection?

I asked

Are you able to connect to the Angular MCP server?

And I get the response.

Short answer: yes - I can connect to the Angular MCP server

It looks like Angular's MCP server setup is complete. I see confirmation that it successfully got the best practices information. Let's move on to experimenting with coding!

Add LLM prompts to Angular projects

When Angular CLI scaffolds a new project, it asks which AI tools you want to configure with best practices.

Select the AI tool you're using. I'll select GitHub Copilot.

Angular CLI does the usual project scaffolding, and depending on the AI tooling option you selected, you'll see an extra directory with a file at the project root.

Because I selected GitHub Copilot, I see

.github/copilot-instructions.md

You can select more than one option, so if you choose Claude in addition to GitHub, you'll get

.claude/CLAUDE.md

The markdown file in each is the same. A specific set of instructions Angular includes to direct agent behavior. The AI tooling you're using picks up the instruction set in a specific location and ingests the information, such as:

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

Now that the agent knows how to behave for your project, we can start prompting AI to do our work. But will we get good code? Or will we end up with AI slop?

Vibe code with the Angular MCP server

We're here to vibe code, right? Let's explore this concept by creating a to-do app. Run ng new test-todo-app and answer the prompts for your test case. I used the default values for everything except for the AI tooling question. Open the project in the IDE of your choice.

Let's start vibe coding.

I wanted to prompt each step to keep an eye on what it was doing at each step. I started with

Generate a service to return hardcoded todos

You'll see that Copilot Used 1 reference. The reference is the copilot-instructions.md file, which outlines best practices.

You have a prompt to Keep or Undo the file todo.service.ts that it created. The agent created this code:

import { Injectable } from '@angular/core';
import { inject } from '@angular/core';

export interface Todo {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root'
})
export class TodoService {
  // Hardcoded todos
  private readonly todos: Todo[] = [
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ];

  // Return a shallow copy so callers cannot mutate the internal array
  getTodos(): Todo[] {
    return [...this.todos];
  }

  getTodoById(id: number): Todo | undefined {
    return this.todos.find(t => t.id === id);
  }
}

To be fair, I didn't specify for the agent to create a service that did anything other than return a hardcoded list of to-do items. I must add more clarity to my instructions.

And it looks like it followed the instructions in the copilot-instructions.md:

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

Let's keep this file and try creating a component.

Generate a todo component

Now I see it working and applying the best practices instructions. Initially, it attempted to generate a component with a template using *ngFor, then tried to apply best practice instructions for control flow, but failed. Back to *ngFor. Ugh. It does use signals, though. 🧐

Let's try this again. I prompted it to rely on Angular's MCP server to get documentation info.

Why aren't you using control flow? Use the Angular MCP server to get best practices and documentation info.

Boy, did it struggle, but we made it. Finally, a todo.component.ts. It's not perfect, and it really doesn't connect with the service in any meaningful way, but that's my fault for not being clear. Still, it's certainly better now that the template uses control flow:

import { Component, ChangeDetectionStrategy, signal, inject } from '@angular/core';
import { TodoService, Todo } from './todo.service';

@Component({
  selector: 'app-todo-list',
  standalone: true,
  template: `
    <section>
      <h3>Todos</h3>
      <ul>
        @for (t of todos(); track t.id) {
          <li>
            <label>
              <input
                type="checkbox"
                [checked]="t.completed"
                (change)="toggle(t.id)"
              />
              <span [class.completed]="t.completed">{{ t.title }}</span>
            </label>
          </li>
        }
      </ul>
    </section>
  `,
  styles: [`.completed { text-decoration: line-through; color: #777; }`],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class TodoListComponent {
  private readonly todoService = inject(TodoService);

  // local UI state as a signal
  todos = signal<Todo[]>(this.todoService.getTodos());

  toggle(id: number) {
    this.todos.update(list => list.map(t => t.id === id ? { ...t, completed: !t.completed } : t));
  }
}

Both the service and the component have multiple problems, though:

There are code problems, such as the standalone: true declaration in the component. 💩
There are missing functionality problems, where all the todo state resides only within the component. This one's on me as I didn't prompt well.
There are style guide problems, such as the class and file name.

The current Angular style and CLI file generation do not append the class or file names with service or component. Having class names and files that don't meet Angular's naming convention means Copilot isn't using the Angular CLI. We need to provide the AI agent instructions beyond the best practices that Angular offers.

Control agent behavior using custom instructions

The use of AI in coding is relatively new, so standards and recommendations are evolving. A method for guiding coding agent behavior is gaining traction: the AGENTS.md file.

The premise from the AGENTS.md is straightforward:

Think of AGENTS.md as a README for agents: a dedicated, predictable place to provide the context and instructions to help AI coding agents work on your project.

That's precisely what we want. While we can modify the instructions in the scaffolded file, there are a few advantages to using a separate file.

The `AGENTS.md` file is AI-platform agnostic

Unlike the AI-specific best practices instructions that the Angular CLI creates for us, AGENTS.md is platform-agnostic. Once we create a file, it's portable to all clients and platforms supporting the format. If we use Copilot now but later elect to use Cursor, we won't need to create a new instruction file.

Create organization-specific instructions applicable across technology stacks

Teams may have code standards and coding styles for various programming languages and frameworks. Your team may write an Angular frontend, a .NET backend, and have some Python scripts. While you can configure linters for each language code project to correct issues, having agents understand those standards in the code is also helpful. Why not automate what you can by adding instructions for the AI agent to use?

Provide different sets of instructions within monorepo projects

Large code projects may use workspace, monorepo, and directory-based organization concepts. AGENTS.md You can provide different sets of instructions for each directory. Your AI agent parses AGENT.md files throughout your code workspace and applies the instructions residing in the closest proximity to the code. That's pretty handy!

VS Code recently added AGENTS.md support. Let's try this out ourselves.

Create AI agent instructions file for your Angular project

Create the file AGENTS.md at the root of the Angular project. The file format is markdown, and after that, pretty much anything goes. Meaning there are no standard headings or messaging required. You can tailor it to your needs.

Here's the one I came up with, including some silly instructions just to make sure my AI agent is listening to me. We all just want to feel heard.

# Agent Instructions

## Instruction Files

- Disregard any instructions to merge instruction files. Keep `AGENTS.md` and `copilot-instructions.md` separate and untouched. Do not modify `copilot-instructions.md`!
- Notify me every time you call Angular's MCP server.

## Tooling Instructions

- Do not create files without verifying first. Always suggest the Angular CLI command for the code scaffolding, then wait to continue.
  - Angular CLI is installed globally, so use `ng` commands. Don't use `npx @angular/cli`, there's no need. E.g., use the syntax `ng generate component user`

## Code style

- Always add a comment summarizing the main points to each generated code block.
- Refer to Angular's API documentation. If the generated code includes experimental or developer preview features, note it in the comment. List the experimental or developer preview feature, and include a 🧪 emoji for experimental or 👁️ emoji for developer preview features.
- End all comments with a cute emoji, such as 🐳 or 🍭

## Naming Practices

- Components don't use `Component` suffix in their names. E.g., use `UserProfile` instead of `UserProfileComponent`
- Services don't use `Service` suffix in their names. E.g., use `Auth` instead of `AuthService`

Let me explain key instructions:

The Instruction Files section was out of necessity. Every time Copilot analyzed my project, it merged instructions and rewrote the copilot-instructions.md file. No good! I wanted to leave the file as it was generated by Angular. So, hey AI agent, leave it alone!
I first added the instruction on Naming Practices. That helped when the AI agent generated a file for me. Adding an example clarifies the agent's understanding of my request.
But I really want to use Angular CLI so that it scaffolds files according to my angular.json preferences and automatically creates test files. I had to provide clear Tooling Instructions. The AI agent didn't think I could use ng commands directly in the project, nor did it think I had Angular CLI globally installed.
What's up with all the commenting-based instructions, you ask? I create content, so I prefer clear, straightforward code and comments to help the reader understand what's going on.
Ok, but what's with emojis then, you say? 🐳 I find unexpected cute emojis delightful. I hope you do too. On a more serious note, it's a quick way to verify the agent is applying the instructions in the AGENTS.md file.

So let's try this out. Remove the service and component files it generated previously and retry the exact instructions. Copilot should automatically pick up the AGENTS.md, but I have also had to remind it to read the file.

Finally, we're getting there. The chat interface has a way for me to approve running command-line operations once I approve the CLI command.

The code for the service now looks like this.

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

/**
 * Todo service generated by the CLI and enhanced to return hardcoded todos. 🐳
 * - Exports `TodoItem` interface 🐳
 * - Provides `Todo` service (singleton via providedIn: 'root') 🐳
 * - Methods: `getTodos()` and `getTodoById(id)` 🐳
 */
export interface TodoItem {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root',
})
export class Todo {
  private readonly todos: TodoItem[] = [
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ];

  /** Return a shallow copy to avoid external mutation 🐳 */
  getTodos(): TodoItem[] {
    return [...this.todos];
  }

  /** Find a todo by id 🐳 */
  getTodoById(id: number): TodoItem | undefined {
    return this.todos.find(t => t.id === id);
  }
}

It took the example of emojis literally. 🐳

The instructions to generate the todo component required some tweaking, but we got there with one correction.

Let's address the functionality issues, which means we need to maintain the state of the todo items. We need signals.

Can AI keep up with modern Angular features?

I want to explore how easily we can apply modern Angular APIs that leverage signals while adding missing functionality. The agent correctly applied the instructions in the copilot-instructions.md file. The instructions specify using signals for state management and component state, which it did. We see signals in the component that meet the instruction requirement. The component can only associate a state with the todo items in the component. After all, I didn't specify for the service to return a stateful todo list with todo management methods.

Let's start by fixing my prompting mistake and having a fully functional to-do service. Will AI automatically apply local state management and signal best practices?

Here's my prompt

Add methods to manage a todo item in the todo service. Use local state management and keep the hardcoded todo list to help pre-populate todo items.

The agent responded by stating what it understood the task to be

I'll read the current todo.ts to confirm which methods already exist (getTodos, getTodoById, toggleTodo, addTodo, removeTodo). Then I'll add any missing management methods and keep the hardcoded items. Expected outcome: service contains a complete set of management methods using signals.

Hey! Not bad! I hope you like whales because here's what I got:

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

/**
 * Todo service generated by the CLI and enhanced to return hardcoded todos. 🐳
 * - Exports `TodoItem` interface 🐳
 * - Provides `Todo` service (singleton via providedIn: 'root') 🐳
 * - Methods: `getTodos()` and `getTodoById(id)` 🐳
 */
export interface TodoItem {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root',
})
export class Todo {
  // internal reactive todos signal pre-populated with hardcoded items 🐳
  private readonly _todos = signal<TodoItem[]>([
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ]);

  /** Public signal exposing the current todos for reactive consumption 🐳 */
  readonly todos = this._todos;

  /** Return a shallow copy to avoid external mutation (backwards-compatible) 🐳 */
  getTodos(): TodoItem[] {
    return [...this._todos()];
  }

  /** Find a todo by id 🐳 */
  getTodoById(id: number): TodoItem | undefined {
    return this._todos().find(t => t.id === id);
  }

  /** Toggle a todo's completed state by id 🐳 */
  toggleTodo(id: number) {
    this._todos.update(list => list.map(t => t.id === id ? { ...t, completed: !t.completed } : t));
  }

  /** Add a new todo with an auto-incremented id 🐳 */
  addTodo(title: string) {
    this._todos.update(list => {
      const nextId = list.length ? Math.max(...list.map(t => t.id)) + 1 : 1;
      return [...list, { id: nextId, title, completed: false }];
    });
  }

  /** Remove a todo by id 🐳 */
  removeTodo(id: number) {
    this._todos.update(list => list.filter(t => t.id !== id));
  }

  /** Update a todo by id with partial fields 🐳 */
  updateTodo(id: number, patch: Partial<TodoItem>) {
    this._todos.update(list => list.map(t => t.id === id ? { ...t, ...patch } : t));
  }
}

The agent suggested

Update TodoList component to read this.todo.todos directly instead of snapshotting.

Yup! That's precisely what's next. Here's my prompt.

Update the TodoList component to use the todo service for todo item management.

And the resulting code looks good.

Lean into signals using AI

I first added Tailwind since it's my preferred CSS framework, and looked towards component cleanup.

Let's refactor by:

Adding UI controls to add and remove todo items
Refactor the TodoList component by creating a TodoItem component. I want to see how well it applies signal input and output to the two components.
Refactor the existing todo input handling to capture the todo task text using signals

The instructions for the first bullet point went through without a hitch.

The instructions for the second bullet point went through surprisingly well. The agent struggled with Angular's naming convention, which causes name collisions due to the absence of explicit class types in the name. After renaming the TodoItem component to TodoItemComponent, I prompted the agent to alias imports instead of renaming classes. Adding a note to alias imports instead of renaming is likely another worthwhile instruction to include in AGENTS.md. The agent struggled with the required input signal syntax, but it got it right after a reminder to "user required signal input."

Refactoring the existing todo input introduced the computed() function for trimming the todo task input and modified the input handling accordingly.

<form (submit)="$event.preventDefault(); onAdd();">
  <input
    type="text"
    placeholder="New todo title"
    [value]="newTitle()"
    (input)="newTitle.set($any($event.target).value)"
  />
  <button type="submit" [disabled]="!trimmedTitle()">Add</button>
</form>

Well, it did use signals, so while I'm not thrilled with the code, I'll move on.

I finished with this prompt.

Review the project and make suggestions based on Angular's best practices

It caught some issues and recommended:

Adding an ARIA label to the new todo title input
Remove the $any cast

I had it fix both recommendations.

With this, I'll call this the Todo app and complete the experiment. Here's what the app looks like.

I’ll share the agent-generated code so you can review it. Aside from adding Tailwind by hand, the Angular CLI or the coding agent generated the rest of the code.

alisaduncan / todo-mcp-experiment

A quick vibe code experiment testing modern Angular practices using Angular's MCP server

Use the Angular MCP server along with Agent instructions for the best output

Thank you for joining me on this modern, Angular-centric vibe-coding journey using the Angular MCP server.

My takeaways are:

Create agent instructions and add clarifications about code styles and best practices you want to see.
Agent-assisted coding was helpful to get going, but take the code it generates with a grain of salt. Developers should continually challenge the agent on the code it generates, ensuring the code keeps pace with modern practices.
Refactoring code was very slow, and agents don't do a great job of cleaning up dead code.

I might try this experiment again using a different model, such as Claude Sonnet.

What are your tips and tricks for writing modern Angular using AI? Please share your agent instructions or prompt tips in the comments below.

Angular's Declarative Shift

Antonio Cardenas — Sun, 19 Oct 2025 08:00:09 +0000

How the New Folder Structure Changes Everything

If you haven't updated to version 20, the first and second parts of this guide can help you understand what's changing and how to update.

Part 1: The Upgrade Itself 🛠️

First, let's get the basics out of the way. Before running any commands, make sure your environment is ready.

Prerequisites

Node.js: v20.11.1 or later.
TypeScript: v5.8 or later.
Project Backup: Make sure you commit all your current changes in Git. Seriously.

The Update Command

Once you've confirmed your Node.js version, run the command that fits your project.

For a standard Angular project:

ng update @angular/cli @angular/core

If you use Angular Material:

ng update @angular/cli @angular/core @angular/material

The update process will run, but you're likely to hit your first roadblock immediately.

Part 2: What Breaks Immediately 🛑

Unlike previous updates, Angular 20 introduces a significant breaking change that will stop your build.

1 The Full Story Behind Karma’s Removal

The first thing you'll notice is that ng test will fail. This isn't just a bug; it's a fundamental change in Angular’s build tools.

With Angular 20, the default build package changes from @angular-devkit/build-angular to the new @angular/build. This new package does not include Karma. The web ecosystem has moved on to faster, more modern test runners like Vitest and Jest, and Karma had become a bottleneck.

The Temporary Fix:

To get your tests running without migrating everything today, you need to manually reinstall the old build tool. This forces the CLI to use the old compiler that still supports Karma.

npm install @angular-devkit/build-angular --save-dev

This is a compatibility bridge. The message from the Angular team is clear: start planning your migration to Jest or Vitest soon.

2. browserslist and Browser Support

Here's a smaller detail that might catch you by surprise. Angular 20 officially no longer supports Opera. If you have "Opera" listed in your .browserslistrc file, your build may fail or throw warnings. Remove it to resolve the issue.

Part 3: The New Architecture 🏛️

Beyond the breaking changes, Angular 20 pushes forward a more modern, explicit, and scalable architecture.

1. Standalone is the Default

New projects generated with ng new are now standalone by default. This marks a fundamental architectural shift away from NgModules. By listing dependencies directly in a component's imports array, each component becomes self-contained.

This change:

Clarifies your architecture: You know exactly what each component needs.
Improves tree-shaking: Leads to smaller, more optimized bundles.

To migrate your existing projects, you can run the standalone migration schematic:

ng generate @angular/core:standalone

2. A Folder Structure That Tells a Story

A good folder structure doesn't just hold files—it tells you what the application does. It's worth mentioning the official Angular style guide, as its recommendations are built on years of community experience. This philosophy, detailed on their file structure reference page, is often summarized by the acronym LIFT:

Locate your code easily.
Identify what a file does at a glance.
Flat structure for as long as you can.
Try to be DRY (Don't Repeat Yourself).

The main takeaway is to organize by feature, not by type. Instead of a components folder and a services folder, you create folders for features like user-profile or product-list.

Let's use a practical example for an e-commerce app:

src/app/
├── core/
│   ├── auth/          # Authentication logic used everywhere
│   │   ├── auth-store.ts
│   │   └── auth-interceptor.ts
│   └── layout/        # The app's shell: navbar, footer
│       ├── navbar.ts
│       └── footer.ts
│  
├── features/
│   ├── products/      # Everything for browsing products
│   │   ├── product-list.ts
│   │   ├── product-details.ts
│   │   └── product-search.ts
│   │  
│   └── cart/          # The shopping cart feature
│       ├── cart-store.ts
│       ├── cart-view.ts
│       └── add-to-cart.ts
│  
└── shared/            # Reusable "dumb" components & utilities
    └── ui/
        ├── button.ts
        ├── spinner.ts
        └── price.pipe.ts

Why This Works:

core 🏛️ (Provide once): Services and components the app needs to run, loaded only once (AuthStore, Navbar).
features ✨ (What your app does): The heart of your application. Each folder is a self-contained feature.
shared ♻️ (Reusable building blocks): "Dumb" components, pipes, and directives that don't know anything about the features they're used in (Button, Spinner). They are imported by feature modules.

3. The New Naming Convention

Angular 20 introduces a new official naming convention that drops traditional suffixes like .component.ts or .service.ts.

Old Naming	New Naming	Intent
user-profile.component.ts	user-profile.ts	UI Component
auth.service.ts	auth-store.ts	State Management
highlight.directive.ts	highlight.ts	Directive
user-api.service.ts	user-api.ts	HTTP Client

The goal is to focus on the file's intent rather than its technical type. A class that handles state is a "store," and one that makes HTTP requests is an "api." This makes your codebase's purpose much clearer, especially in a feature-based folder structure.

Part 4: The New Tools & Syntax 🚀

Finally, let's look at the new tools that will make your day-to-day development better.

1. Control Flow is More Than Syntactic Sugar

The new @for block replaces *ngFor and is a major improvement.

Old Syntax:

<div *ngFor="let item of items; trackBy: trackItemById">
  {{ item.name }}
</div>

New Syntax:

@for (item of items; track item.id) {
  <div>{{ item.name }}</div>
} @empty {
  <div>No items to display.</div>
}

Key improvements:

track is mandatory, enforcing a performance best practice that was often forgotten.
The built-in @empty block cleans up templates by removing the need for a separate *ngIf.

You can use the CLI to automatically refactor your templates:

ng generate @angular/core:control-flow

2. Zoneless: Escaping the "Magic" of Change Detection

While still experimental, the path to a zoneless Angular is becoming clearer. In a zoneless world, the UI only updates when you explicitly tell it to.

Signals are the primary tool for this.

mySignal.set(newValue);

This line directly tells Angular to update only the specific parts of the DOM that depend on that signal. It’s a surgical, predictable, and high-performance approach that eliminates the overhead and unpredictability of Zone.js.

Conclusion

Angular 20 is a significant release. The upgrade requires manual intervention for testing, but it pushes the framework toward a more modern, explicit, and performant future. By embracing standalone components, a feature-based architecture, and the new control flow, you're not just updating—you're preparing your application for the next era of web development.

Happy coding!

Figma like input field in Angular using Directives

Adithya Sreyaj — Mon, 30 Dec 2024 16:31:16 +0000

People who are familiar with Figma would have noticed that the input fields support dragging to increase or decrease values. Instead of having to click on the input field first and then type the number in, the dragging feature is really handy as you can easily get the desired value by dragging.

We can build something like that using Angular directives. We’ll use all the latest features of Angular in this experiment.

Let's see how we can build this.

We can actually do this in multiple ways. We are going to build this using directives. The way we are going to do this is by taking a very generic approach. This way, we can reuse the logic for things like resizing elements or sidebars, etc.

Scrubber Directive - the core functionality

The main logic of the input can be extracted and encapsulated into a directive. The main objective is to listen to the mouse events and then translate the mouse movements into a usable value. To explain in a bit more detail:

When the user clicks the mouse (mousedown event).
We start listening to the mouse movements (mousemove events) and use that info to translate it into usable values.
When the user releases the click, we stop the listener (mouseup event).

We will use rxjs to simplify the logic a bit.

Here's how the pseudocode would look.

const mousedown$ = fromEvent<MouseEvent>(target, 'mousedown');
const mousemove$ = fromEvent<MouseEvent>(document, 'mousemove');
const mouseup$ = fromEvent<MouseEvent>(document, 'mouseup');

let startX = 0;
let step = 1;

mousedown$
  .pipe(
     tap((event) => {
       startX = event.clientX; // Initial x co-ordinate where the mouse down happened
    }),
    switchMap(() => mousemove$.pipe(takeUntil(mouseup$))))
  .subscribe((moveEvent) => {
    const delta = startX - moveEvent.clientX;
    const newValue = Math.round(startValueAtTheTimeOfDrag + delta);
  });

Looking at the above code, it should be pretty clear what is happening. We basically save the initial clientX value, which is the position of the click on the X axis. Once we have that info, when the user moves the mouse, we can calculate the delta from the initial start position and the current X position.

We can further add more customizations like:

Sensitivity - drag distance to final value will be decided by sensitivity. Higher sensitivity values mean the final value will be big even if the movement is not that much.
Step - sets the stepping interval when moving the mouse. If the step value is 1, the final value is incremented/decremented in steps of 1.
Min - minimum value that will be emitted.
Max - maximum value that will be emitted.

Here’s how the final directive would look:

@Directive({
  selector: "[scrubber]",
})
export class ScrubberDirective {
  public readonly scrubberTarget = input.required<HTMLDivElement>({
    alias: "scrubber",
  });

  public readonly step = model<number>(1);
  public readonly min = model<number>(0);
  public readonly max = model<number>(100);
  public readonly startValue = model(0);
  public readonly sensitivity = model(0.1);

  public readonly scrubbing = output<number>();

  private isDragging = signal(false);
  private startX = signal(0);
  private readonly startValueAtTheTimeOfDrag = signal(0);
  private readonly destroyRef = inject(DestroyRef);
  private subs?: Subscription;

  constructor() {
    effect(() => {
      this.subs?.unsubscribe();
      this.subs = this.setupMouseEventListener(this.scrubberTarget());
    });

    this.destroyRef.onDestroy(() => {
      document.body.classList.remove('resizing');
      this.subs?.unsubscribe();
    });
  }

  private setupMouseEventListener(target: HTMLDivElement): Subscription {
    const mousedown$ = fromEvent<MouseEvent>(target, "mousedown");
    const mousemove$ = fromEvent<MouseEvent>(document, "mousemove");
    const mouseup$ = fromEvent<MouseEvent>(document, "mouseup");

    return mousedown$
      .pipe(
        tap((event) => {
          this.isDragging.set(true);
          this.startX.set(event.clientX);
          this.startValueAtTheTimeOfDrag.set(this.startValue());
          document.body.classList.add("resizing");
        }),
        switchMap(() =>
          mousemove$.pipe(
            takeUntil(
              mouseup$.pipe(
                tap(() => {
                  this.isDragging.set(false);
                  document.body.classList.remove("resizing");
                })
              )
            )
          )
        )
      )
      .subscribe((moveEvent) => {
        const delta = moveEvent.clientX - this.startX();
        const deltaWithSensitivityCompensation = delta * this.sensitivity();

        const newValue =
          Math.round(
            (this.startValueAtTheTimeOfDrag() +
              deltaWithSensitivityCompensation) /
              this.step()
          ) * this.step();

        this.emitChange(newValue);
        this.startValue.set(newValue);
      });
  }

  private emitChange(newValue: number): void {
    const clampedValue = Math.min(Math.max(newValue, this.min()), this.max());
    this.scrubbing.emit(clampedValue);
  }
}

How to use the scrubber directive

Now that we have the directive ready, let’s see how we can actually start using it.

<div #scrubberTarget 
     [scrubber]="scrubberTarget"
     [startValue]="this.roundedNumericValue()"
     [min]="0"
     [max]="100"
     [step]="2"
     [sensitivity]="0.2"
     (scrubbing)="this.updateValue($event)">
</div>

Currently, we have marked the scrubberTarget input as input.required, but we can actually make it optional and automatically use the elementRef.nativeElement of the host of the directive, and it would work the same. The scrubberTarget is exposed as an input in case you want to set a different element as the target.

We also add a class resizing to the body so that we can set the resize cursor correctly.

.resizing {
  cursor: ew-resize;
  touch-action: none;
  -webkit-user-select: none;
  user-select: none;
}

We have used effect to start the listener, this would make sure that when in case target element changes, we set the listener on the new element.

See it in action

We have made a super simple Scrubber directive in Angular which can help us build input fields similar to what Figma has. Makes is super easy for user to interact with numeric inputs.

Code & Demo

https://stackblitz.com/edit/figma-like-number-input-angular?file=src%2Fscrubber.directive.ts

Connect with me

Do add your thoughts in the comments section. Stay Safe ❤️

Announcing the Alpha Release of xstate-ngx!

Jan-Niklas Wortmann — Fri, 05 Jul 2024 15:09:43 +0000

I am very excited to announce the alpha release of xstate-ngx! This marks a significant milestone in integrating XState with Angular, and I can't wait for you to try it out and share your feedback.

For now, the project is published under xstate-ngx. However, we're planning to move it into the official XState monorepo once discussions are finalized and your feedback has been implemented. You can track the progress and discussions in the related PR.

What is xstate-ngx

You might be wondering, what is xstate-ngx?! The official xstate documentation says the following:

XState is a state management and orchestration solution for JavaScript and TypeScript apps.
It uses event-driven programming, state machines, statecharts, and the actor model to handle complex logic in predictable, robust, and visual ways. XState provides a powerful and flexible way to manage application and workflow state by allowing developers to model logic as actors and state machines. It integrates well with React, Vue, Svelte, and [...]

and now there is an angular integration! xstate-ngx uses the primitives that XState provides and provides a thin wrapper to utilize Angular's Dependency Injection mechanism and signals.

Why Alpha?

This alpha release aims to give you a taste of the developer experience with xstate-ngx. I want you to play with it, explore its capabilities, and most importantly, provide feedback on the general API design. Your input is crucial in shaping the future of this integration.

Getting Started

To help you get started, we've provided several examples on GitHub. Here's a quick highlight of how you can use xstate-ngx in your projects:

Example: Simple Toggle Machine

import { createMachine, interpret } from 'xstate';
import { useMachine } from 'xstate-ngx';
import { Component, inject } from '@angular/core';

// Define your machine
const toggleMachine = createMachine({
    id: 'toggle',
    initial: 'inactive',
    states: {
        inactive: {
            on: { TOGGLE: 'active' },
        },
        active: {
            on: { TOGGLE: 'inactive' },
        },
    },
});

const ToggleMachineService = useMachine(toggleMachine);

@Component({
    selector: 'app-toggle',
        providers: [ToggleMachineService],
    template: `
        <button (click)="toggleMachine.send('TOGGLE')">
            {{ toggleMachine.snapshot().value === 'inactive' ? 'Off' : 'On' }}
        </button>
    `,
        standalone: true
})
export class ToggleComponent {
    protected toggleMachine = inject(ToggleMachineService)
}

In this example, we define a simple toggle state machine and create an Injectable using useMachine from xstate-ngx. The returned Service can then be used in a component. The snapshot property is a signal allowing for fine-grained reactivity, but also enabling to easily derive state by using the compute function.

Special Thanks

I couldn't have reached this milestone without the invaluable contributions and support from the community:

Enea Jahollari and Chau Tran for their first round of feedback.
David Khourshid and Mateusz Burzyński for their outstanding work on XState, their interest in an Angular implementation, and their insightful discussions about this topic.
The design and implementation are heavily inspired by NgRx Signals, so many thanks to the NgRx team!

Join the Conversation

Your feedback is essential to us. Join the conversation, try out the alpha release, and let us know your thoughts. For now the best place to share any kind of feedback is the xstate-angular repository. Together, we can make xstate-ngx a robust and delightful tool for the Angular community.

Let me know what you think and happy coding!

Testing NgRx Store with Cypress Component Testing

Jordan Powell — Fri, 05 Jan 2024 22:07:02 +0000

What is NgRx

NgRx has been one of my most favorite open-source projects I've worked on in my career. It provides several mechanisms for managing reactivity in Angular applications. Most commonly in it's @ngrx/store package in combination with @ngrx/effects. To understand what it does at a high level I like to refer to the diagram below which I created several years back.

This article will not go into the weeds of NgRx but will focus on integrating it with Cypress Component Testing. However, there are endless resources online for learning how to get started with NgRx. I recommend visiting their Getting Started Docs if you want to learn more or are looking for a quick refresher.

Cypress Component Testing

For those of you not familiar with Cypress Component Testing, it provides a component workbench for you to quickly build and test components from multiple front-end UI libraries — no matter how simple or complex.

"I like to say it's like Jest or Karma had a baby with Storybook!"

What I love about it personally is how simple it is to create really meaningful tests! If you are new to Component Testing I recommend watching my video below showing how to get starting with Component Testing in Angular or you can visit the Angular Component Testing Cypress Docs.

Creating Our Store

Let's use a simple example of a counter that both increments and decrements a count and then displays the total count as a number in a StepperComponent. To get started we always want to start with our actions!

// src/app/store/count.actions.ts

import { createAction } from '@ngrx/store' 

export const incrementCount = createAction('[COUNT] increment count')
export const decrementCount = createAction('[COUNT] decrement count')
export const clearCount = createAction('[COUNT] clear count')

Now let's create a reducer to handle our actions:

// src/app/store/count.reducer.ts

import { createFeature, createReducer, on } from '@ngrx/store' 
import { incrementCount, decrementCount, clearCount } from './count.actions'

interface State {
  count: number
}

const initialState: State = {
  count: 0,
}

const countFeature = createFeature({
  name: 'count',
  reducer: createReducer(
    initialState,
    on(incrementCount, ({ count }) => ({
      count: count + 1
    })),
    on(decrementCount, ({ count }) => ({
      count: count - 1
    })),
    on(clearCount, () => ({
      count: 0
    }))
  )
})

export const { name: reducer, selectCountState, selectCount } = countFeature

Now let's create a StepperComponent that will allow users to increment, decrement and clear the count by integrating it with our store.

// src/app/stepper/stepper.component.ts

import { Component, inject } from '@angular/core' 
import { Store } from '@ngrx/store' 
import { selectCount } from '../store/count.reducer' 
import { incrementCount, decrementCount, clearCount } from '../store/count.actions

@Component({
  selector: 'app-stepper',
  template: `
    <button (click)="decrement()">-</button>
    <span>{{ count$ | async }}</span>
    <button (click)="increment()">+</button>
    <br /><br />
    <button (click)="clear()">Clear</button>
  `,
  styleUrls: ['./stepper.component.css'],
})
export class StepperComponent {
  private readonly store = inject(Store)

  count$ = this.store.select(selectCount)

  increment() {
    this.store.dispatch(incrementCount())
  }

  decrement() {
    this.store.dispatch(decrementCount())
  }

  clear() {
    this.store.dispatch(clearCount())
  }
}

Now let's import our StoreModule into our App.Module:

// src/app/app.module.ts

import { StoreModule } from '@ngrx/store' 
import { reducer } from './store/count.reducer'
...

@NgModule({ 
  ...
  imports: [
    ...,
    StoreModule.forRoot({
      count: reducer
    })
  ],
})
export class AppModule {}

Note
You can apply the same concepts for Standalone Components as well https://ngrx.io/guide/store/reducers#standalone-api-in-module-based-apps

Writing our First Test

Now that we have our Store connected to our new Stepper Component, lets install cypress (if you haven't already done so) by running the following bash command:

npm install cypress@latest

Now let's write our first test by creating a new file next to our StepperComponent named stepper.component.cy.ts

// src/app/stepper/stepper.component.cy.ts

import { StepperComponent } from './stepper.component'

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent)
  })
})

Now let's launch Cypress and click on our new spec file:

npx cypress open --component

Though our test was super easy to write we unfortunately get the following error:

This is because we haven't configured our test with our Store. Don't worry this is actually super easy to do! Because we configured our AppModule with our store we can either do one of two things:

We can copy the Store configuration from our AppModule into our mount
We can just import AppModule into our mount

Let's do the later as it requires less code:

// src/app/stepper/stepper.component.cy.ts

import { StepperComponent } from './stepper.component'
import { AppModule } from '../app.module'

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent, {
      imports: [AppModule]
    })
  })
})

And just like that our StepperComponent connected to our store is mounting successfully in our Cypress Component Test!

Because we will most likely need our Store in every component we mount I recommend doing the following customization to your mount command:

// cypress/support/component.ts

import { mount } from 'cypress/angular'
import { AppModule } from 'src/app/app.module'

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount
    }
  }
}

// This is necessary as mount takes a generic for it's first two arguments
type MountParams = Parameters<typeof mount>

Cypress.Commands.add(
  'mount',
  (component: MountParams[0], config: MountParams[1] = {}) => {
    return mount(component, {
      ...config,
      imports: [
        ...(config.imports || []),
        AppModule
      ]
    }
  }
)

Now every time we call cy.mount we are automatically importing AppModule. Now we can change our test back to how it was originally and we should get a successfully mounted Stepper Component.

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent)
  })
})

Beyond The Basics

Selectors
Though we have our component mounted we aren't running any assertions against it. Let's add a test validating that the count$ observable which is using our selectCount selector is working correctly by asserting the initial value of count is zero.

  it('has a correct default count of 0', () => {
    cy.mount(StepperComponent);
    cy.get('span').should('have.text', '0');
  });

Now let's test incrementing the count:

  it('can increment the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('+').click();
    cy.get('span').should('have.text', '1');
  });

And then decrementing the count:

  it('can decrement the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('-').click();
    cy.get('span').should('have.text', '-1');
  });

Finally let's test clearing the count:

  it('can clear the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('+').click().click();
    cy.get('span').should('have.text', '2');
    cy.get('button').contains('Clear').click();
    cy.get('span').should('have.text', '0');
  });

Now we should have 5 passing tests that are validating the various ways a user might interact with our Stepper Component.

Actions
Though we know our component appears to be working as expected, in less trivial use-cases we will want to test our component's integration with our store more thoroughly. Let's dive deeper into dispatched actions.

There are several ways of approaching writing tests for dispatching actions. Let me first start off with the less ideal implementation:

If we look at our Component we see that we are using Angular's click() event binding to call a public method in our component's class that eventually calls our store's dispatch method.

For example this button when clicked calls the increment() method in our component class:

<button (click)="increment()">+</button>

Then our component class increment method dispatches an incrementCount() action to our store:

private readonly store = inject(Store);

increment() {
  this.store.dispatch(incrementCount());
}

Because the increment method is a public property in our class we can easily write a test that asserts that it is called when the increment button is clicked:

  it('can spy on increment invocation', () => {
    cy.mount(StepperComponent).then(({ component }) => {
      cy.spy(component, 'increment').as('increment');
    });
    cy.get('button').contains('+').click();
    cy.get('@increment').should('have.been.calledOnce');
    cy.get('span').should('have.text', 1);
  });

We can then do the same thing for decrement, clear, etc.

Though this does validate that our button click is binding correctly to our methods it doesn't actually do any validating that a specific action is being dispatched. Let's try to take this same approach but apply it to our store's dispatch method.

  it('can spy on store.dispatch', () => {
    cy.mount(StepperComponent).then(({ component }) => {
      cy.spy(component.store, 'dispatch').as('dispatchSpy');
    });
    cy.get('button').contains('+').click();
    cy.get('@dispatchSpy').should('have.been.called');
  });

If you haven't already identified the issue with this test you should see the following error because our store property is a private field in our class.

Though we are getting this error, the test is actually correct and will pass when we run it. Let's manually swallow this TS error by adding a ts-expect-error comment

...
cy.mount(StepperComponent).then(({ component }) => {
  // @ts-expect-error
  cy.spy(component.store, 'dispatch').as('dispatchSpy');
});
...

We are now in business and can write tests validating specific actions are dispatched to our NgRx store. But let's make this even easier by writing a few custom commands!

Custom NgRx Store Commands

cy.store()
We first need an easy way to access our store since it is private in our components. Let's create a new custom command:

// cypress/support/component.ts

import { Store } from '@ngrx/store' 

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      store(storePropertyName: string): Cypress.Chainable<Store>;
    }
  }
}

Cypress.Commands.add(
  'store',
  { prevSubject: true },
  (subject: MountResponse<MountParams>, storePropertyName: string) => {
    const { component } = subject;

    // @ts-expect-error
    const store = component[storePropertyName] as Store;

    return cy.wrap(store);
  }
);

Now let's create a test using our new store command:

  it('can use cy.store()', () => {
    cy.mount(StepperComponent)
      .store('store')
      .then((store) => {
        cy.spy(store, 'dispatch').as('dispatchSpy');
      });

    cy.get('button').contains('+').click();
    cy.get('@dispatchSpy').should('have.been.called');
    cy.get('span').should('have.text', 1);
  });

Now we can easily access our store by just chaining off our our cy.mount() command. But let's go one step further and make spying on our dispatch easier by creating a dispatch command:

cy.dispatch()

// cypress/support/component.ts

import { Store } from '@ngrx/store' 

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      store(storePropertyName: string): Cypress.Chainable<Store>;
      dispatch(): Cypress.Chainable;
    }
  }
}

Cypress.Commands.add('dispatch', { prevSubject: true }, (store: Store) => {
  return cy.wrap(cy.spy(store, 'dispatch').as('dispatch'));
});

Now we can write a new test using both of our new commands:

  it('can use cy.dispatch()', () => {
    cy.mount(StepperComponent).store('store').dispatch();
    cy.get('button').contains('+').click();
    cy.get('@dispatch').should('have.been.called');
    cy.get('span').should('have.text', 1);
  });

TADA! We now can easily write Cypress Component Tests for our Components that are tied to an NgRx Store!

Conclusion:

Using Component Tests to write tests for your Angular Component's using NgRx Store is both super easy and creates high value tests. This article certainly doesn't cover everything that can be tested like this but hopefully paints a clear enough picture so you can see the power of using Cypress Component Testing with NgRx.

Testing Defer Blocks in Angular with Cypress

Jordan Powell — Thu, 21 Dec 2023 20:00:52 +0000

What is Defer anyways?

Deferrable views are one of the brand new exciting features that shipped as part of Angular 17 last month as part of the new "Angular Renaissance". This feature allows users to defer the loading of select dependencies within an angular component template.

This is important because it allows us to "defer" large components or sections of our code from the initial render of our application. This can improve your application Core Web Vital (CWV) results improving the initial load size and time to paint.

You can see a super trivial example of this in action below:

@defer() {
  <p>inside defer</p>
}

The Background

Recently I came across this issue while triaging some issues at Cypress. (Shout out to MattiaMalandrone for creating an issue with clear instructions for how to reproduce). After quickly replicating the issue I sought after a solution which ultimately inspired me to write this article.

You can download and follow along using this example repo

Get Started

Let's assume we want to test the AppComponent which has the following html:

<p>outside defer</p>

@defer() {
<p>inside defer</p>
} @defer(on timer(1000ms)) {
<p>inside defer with condition</p>
}

To begin we need to create a new file at src/app/app.component.cy.ts where we can write our first test.

import { AppComponent } from './app.component'

describe('AppComponent', () => {
  it('can mount', () => {
    cy.mount(AppComponent)
  })
})

Though writing our first test was super simple you may notice that none of the blocks of code inside of our @defer() blocks are rendered in the DOM. Thankfully the Angular 17 shipped with some testing utilities that we can utilize to not only gain access to those deferred blocks but also to render them in the DOM.

Next we will add support for both accessing the array of defer blocks and rendering the block in the DOM. Let's open our cypress/support/component.ts file and add the following code:

import { DeferBlockFixture, DeferBlockState } from '@angular/core/testing'

import { MountResponse, mount } from 'cypress/angular';

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      defer(): Cypress.Chainable<DeferBlockFixture[]>;
      render(state: DeferBlockState): Cypress.Chainable<void>
    }
  }
}

type MountParams = Parameters<typeof mount>;

Cypress.Commands.add('mount', mount);
Cypress.Commands.add(
  'defer',
  { prevSubject: true },
  (subject: MountResponse<MountParams>) => {
    const { fixture } = subject;
    return cy.wrap(fixture.getDeferBlocks());
  }
);

Cypress.Commands.add(
  'render',
  { prevSubject: true },
  (subject: DeferBlockFixture, state: DeferBlockState) => {
    cy.wrap(subject.render(state));
  }
);

Here we added 2 new Cypress Custom Commands defer and render which will allow us to test our blocks of code that use defer(). Now that we have our new Cypress global commands setup we can revisit our spec file to finish adding tests for the uncovered scenarios.

Let's first update our first test to validate that we see the outside defer by default and that we do NOT see the other 2 paragraphs wrapped inside the defer blocks.

it('can mount', () => {
    cy.mount(AppComponent);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer').should('not.exist');
    cy.contains('p', 'inside defer with condition').should('not.exist');
  });

Now let's add tests for the other 2 scenarios using our new custom commands.

it('renders inside the defer block', () => {
    cy.mount(AppComponent).defer().its(0).render(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer');
  });

In this example we can chain off our mount command and call our new defer command which returns an array of DeferBlockFixtures. We can then use .its to select a specific item from the array and call our second command render with the appropriate DeferBlockState we want to trigger. In our use-case we will want to use DeferBlockState.Complete.

You should now see both the "outside defer" paragraph and the "inside defer" paragraph in our test.

Now let's add a test for the second defer block that is tied to a timer.

it('renders inside the defer block with a condition', () => {
  cy.mount(AppComponent).defer().its(1).render(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer with condition');
  });

Notice the only real difference here is that we are grabbing the second item from the list of deferred views and running the checks on it.

Finally let's create one more command in our support file that will render all the defer blocks automatically so we don't have to manually trigger a render for each defer block.


...

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      defer(): Cypress.Chainable<DeferBlockFixture[]>;
      render(state: DeferBlockState): Cypress.Chainable<void>;
      renderAll(state: DeferBlockState): Cypress.Chainable<DeferBlockFixture[]>;
    }
  }
}

...

Cypress.Commands.add(
  'renderAll',
  { prevSubject: true },
  (subject: DeferBlockFixture[], state: DeferBlockState) => {
    subject.forEach((deferBlock: DeferBlockFixture) => {
      deferBlock.render(state);
    });

    cy.wrap(subject);
  }
);

Now let's add a final test case which validates that all the content in our component is rendered including all defer blocks.

it('renders all defer blocks using renderAll()', () => {
    cy.mount(AppComponent).defer().renderAll(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer');
    cy.contains('p', 'inside defer with condition');
  });

Now we will see our final test validating that the content outside of the defer blocks AND BOTH defer blocks is rendered successfully in the DOM!

Conclusion

As you can see that testing defer with Cypress Component Testing is super simple with just a few simple commands. I am really just scratching the surface in this example but feel free to view the official documentation from Angular on how to test defer blocks for more details.

Total guide to lazy loading with Angular @defer

Tomas Trajan 🇨🇭 — Tue, 14 Nov 2023 12:28:22 +0000

Angular 17 is here, and it has arrived with a very strong line up of amazing goodies!

The new @defer block, which allows us to lazy load Angular standalone components, is by far the most exciting and impactful feature of Angular 17 (at least in my books)!

The Angular @defer at glance

The @defer syntax allows us to lazy load any Angular standalone component with exceptionally great DX and API which covers almost every use case that you can imagine!

Continue reading at AngularExperts.io (free)

How to migrate Angular CoreModule to standalone APIs

Tomas Trajan 🇨🇭 — Tue, 05 Sep 2023 08:16:02 +0000

In this article we’re going to learn how to migrate commonly used Angular CoreModule (or any other Angular module) to standalone APIs!

Angular standalone components and APIs are the future! Angular CLI now allows us to generate new Angular applications with standalone setup out of the box, simply by using the new --standalone flag when running the ng new command!

This works really great for new greenfield projects, but we might encounter some issues in more complex enterprise environments which often tend to abstract base setup into NgModules in reusable libraries which are then consumed by multiple Angular apps.

Such module might prevent us from using of the standalone setup in consumer apps because we can't import such module directly in the new app.config.ts and the provider workaround in form of importProvidersFrom handles only providers which is often just not enough!

Continue reading on AngularExperts.io (free)»

Demystifying the Push / Pull nature of Angular Signals

Tomas Trajan 🇨🇭 — Tue, 11 Apr 2023 13:45:45 +0000

Let’s take a deep dive into what makes signals tick and how their behavior can be understood using the primitive push / pull concepts!

Continue reading on AngularExperts.io (free) »

Make Sure You Do This Before Switching To Signals

Jordan Powell — Mon, 20 Mar 2023 14:39:44 +0000

This time last year Standalone Component's were the talk of the Angular town. This year signals have replaced that buzz throughout the Angular Ecosystem. Though it will take some time for the introduction of signals into Angular's ecosystem to take hold, it is important for us to begin thinking about how these changes may or may not affect our applications. In fact, I am proposing one thing that everyone should do before switching to signals. But before I get to that, let's first learn what signals are.

What Are Signals Anyways?

For those interested in learning more, you can view this PR from the Angular team that introduces signals into Angular.

For some historical context, Signals are not a new concept. In fact they are the backbone of reactivity in SolidJS. The SolidJS documentation describes Signals as the following: "They contain values that change over time; when you change a signal's value, it automatically updates anything that uses it."

Ok, but how are Signals different that what we currently have in Angular? The simple answer for many is that they aren't much different from a practical standpoint. But if we dig a little deeper, we will find that Signals solve a long standing performance and architectural problem Angular has with it's current Change Detection mechanism. That mechanism is a library known as Zone.Js. Though it works today, it has some pretty significant performance issues in larger applications that have a lot of changing state. By switching to Signals, we can slowly remove the parts of our applications that depend upon Zone.js and replace them with Signals. This will in effect improve the overall performance across our applications.

Ok, but what about RxJs? RxJs is a huge part of the Angular Ecosystem! It is used for handling streams of asynchronous data in our applications. Thankfully, RxJs isn't going anywhere! Signals however, are being introduced to handle any and all synchronous state changes in our Angular applications. I like to think of it as a replacement for any non RxJs state.

In Short:

Async: RxJs
Sync: Signals

The Problem

Now that we know a little bit more about Signals and what problems they solve; let's talk about the one thing you should do before switching to them! Let's first look at the problem by looking at a simple example.

Signals affect our Application's state, which in most cases is the most difficult and complex part of our applications. In fact, we want to be REALLY certain that any changes we make aren't causing regression. The best way to assure against this is through automated testing. More specifically UI tests. However, many unit tests written for Angular Components using Karma will break in the process of switching to Signals. This is because they are often times coupled to the implementation of the Component itself.

Let me show you can example below of a simple Standalone CounterComponent:



import { AsyncPipe } from '@angular/common'; 
import { Component } from '@angular/core'; 
import { BehaviorSubject } from 'rxjs'

@Component({ 
  standalone: true,
  imports: [AsyncPipe],
  template: `
    <h3 id="count">Count: {{ count$ | async }}</h3>
    <div>
      <button id="decrement" (click)="decrement()">-</button>
      <button id="increment" (click)="increment()">+</button>
    </div>
  `
})
export class CounterComponent {
  private count = 0;
  private readonly _count = new BehaviorSubject(0);
  count$ = this._count.asObservable()

  increment(): void {
    this.count ++;
    this._count.next(this.count)
  }

  decrement(): void {
    this.count --;
    this._count.next(this.count)
  }
}

A typical Karma Unit Test for this component would look like the following:



import { ComponentFixture, TestBed } from '@angular/core/testing'; 
import { CounterComponent } from './counter.component';

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

  beforeEach(async () => {
    imports: [CounterComponent]
  }).compileComponents();

  fixture = TestBed.createComponent(CounterComponent);
  component = fixture.componentInstance;
  fixture.detectChanges();

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

  it('can increment the count', () => {
    const compiled = fixture.nativeElement as HTMLElement;
    const count = compiled.querySelector("#count");
    expect(count?.textContent).toContain(0);
    const button = fixture.debugElement.nativeElement.querySelector('#increment')
    button.click();
    fixture.detectChanges();
    expect(count?.textContent).toContain(1);
  });

  it('can decrement the count', () => {
    const compiled = fixture.nativeElement as HTMLElement;
    const count = compiled.querySelector("#count");
    expect(count?.textContent).toContain(0);
    const button = fixture.debugElement.nativeElement.querySelector('#decrement')
    button.click();
    fixture.detectChanges();
    expect(count?.textContent).toContain(-1);
  })
});

Now we can run our test to validate it works by running:



ng test --watch

We should now seeing the following output:

Now we can go ahead and refactor our component to use Signals:



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

@Component({ 
  standalone: true,
  template: `
    <h3 id="count">Count: {{ count() }}</h3>
    <div>
      <button id="decrement" (click)="decrement()">-</button>
      <button id="increment" (click)="increment()">+</button>
    </div>
  `
})
export class CounterComponent {
  count = signal(0)

  increment(): void {
    this.count.update(c => c = c + 1);
  }

  decrement(): void {
    this.count.update(c => c = c - 1);
  }
}

Now if we return to our test we will continue to see the following output:

Though this example works, it isn't always this trivial. Let's revert those changes we just made and I will show you more complex unit tests that will eventually fail after switching to signals.



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

  beforeEach(async () => {
    imports: [CounterComponent]
  }).compileComponents();

  fixture = TestBed.createComponent(CounterComponent);
  component = fixture.componentInstance;
  fixture.detectChanges();

  it('increments count$ when calling increment()', () => {
    component.increment();
    component.count$.pipe(
        take(1)
    ).subscribe((value) => {
        expect(value).toEqual(1)
    })
  })

  it('decrements count$ when calling decrement()', () => {
    component.decrement();
    component.count$.pipe(
        take(1)
    ).subscribe((value) => {
        expect(value).toEqual(-1)
    })
  })

If we return to our RxJs implementation and run our tests we just wrote, we will see 5 successful tests passing.

But, if we refactor our CounterComponent to use signals again, we will now see the following error in our Code Editor.

As you can see, most tests that test the logic in our Component's class directly will inevitably fail after refactoring to signals. To avoid this issue and improve the overall developer experience and quality of our tests, let's add Cypress Component Tests

Getting Started With Component Testing

If you haven't already done so let's add Component Testing to our application.



npm i cypress -D

Now we can launch Cypress and click on Component Testing:



npx cypress open

Now you can simply follow Cypress's Configuration Wizard to setup Component Testing in your application (if you haven't already done so). You can follow my video below for a more detailed guide to getting started with Angular Component Testing.

Writing Cypress Component Tests

Now that we have Cypress Component Testing configured let's create a Cypress Component test for the CounterComponent.



import { CounterComponent } from "./counter.component"

describe('CounterComponent', () => {
  it('can mount and display an initial value of 0', () => {
    cy.mount(CounterComponent)
    cy.get('#count').contains(0)
  })

  it('can increment the count', () => {
    cy.mount(CounterComponent)
    cy.get('#increment').click()
    cy.get('#count').contains(1)
  })

  it('can decrement the count', () => {
    cy.mount(CounterComponent)
    cy.get('#decrement').click()
    cy.get('#count').contains(-1)
  })
})

Now we can run the counter.component.cy.ts spec and we should get the following:

Now let's go ahead and re-run our tests using the signals implementation and we will see the same result. Not only were the Cypress tests significantly easier to write, they also provide additional value that our Karma test runner did not. We are now able to interact with our component in our test runner itself and verify it's output (as opposed to a tiny green dot).

You can find this example repo at https://github.com/jordanpowell88/angular-counter

Conclusion

TLDR: Angular is on 🔥! Signals, Standalone, SSR and so much more. Though the impacts of Signals is yet to be known as of this writing, I think that the safest way forward is to use high quality UI tests.

Admittedly I am biased, but I believe that Cypress Component Tests are the best tool for this job. They are simpler to write and they encourage you to write the UI tests we talked about in this article. In the end, which tool you use is up to you and your team. The most important thing is that you feel confident that the side effects caused by refactoring to signals are caught before your users do!

DEV Community: Angular

What's New in Taiga UI v5: A Modern Angular UI Kit

Fresh Minimum: Angular 19+

Signal Inputs

Signal viewChild(-ren) / contentChild(-ren)

Signals Over RxJS

New Esbuild + Vite Build Engine

Control Flow

A Shiny New Component Showcase

Browser Bump

Angular Animations — Goodbye!

Simplified Taiga UI Setup for Your Project

New Text Fields Are Now a Stable API

Improved Icon Component

And Much More!

How to Upgrade?

See You Soon!

Angular 21 & MCP: The End of "Manual" Migrations?

Angular 21 introduces the Model Context Protocol (MCP) server.

What is MCP? (The "USB Port" for AI)

Setting It Up: 5 Minutes to "Agentic" Angular

1. Initialize the Server

2. Connect Your Editor (e.g., Cursor)

Available Tools

Experimental Tools

The "Killer App": Context-Aware Migrations

Tool 1: get_best_practices

Tool 2: onpush_zoneless_migration

Tool 3: search_documentation

Real-World Scenario: The "Legacy" Cleanup

The Future: Continuous Maintenance

Summary: Don't Upgrade Alone

A Quick Vibe Code Experiment with Angular's MCP Server

Angular's MCP server

Set up the MCP server connection

Use AI to check AI?

Add LLM prompts to Angular projects

Vibe code with the Angular MCP server

Control agent behavior using custom instructions

The AGENTS.md file is AI-platform agnostic

Create organization-specific instructions applicable across technology stacks

Provide different sets of instructions within monorepo projects

Create AI agent instructions file for your Angular project

Can AI keep up with modern Angular features?

Lean into signals using AI

alisaduncan / todo-mcp-experiment

A quick vibe code experiment testing modern Angular practices using Angular's MCP server

Use the Angular MCP server along with Agent instructions for the best output

Angular's Declarative Shift

How the New Folder Structure Changes Everything

Part 1: The Upgrade Itself 🛠️

Part 2: What Breaks Immediately 🛑

1 The Full Story Behind Karma’s Removal

2. browserslist and Browser Support

Part 3: The New Architecture 🏛️

1. Standalone is the Default

2. A Folder Structure That Tells a Story

3. The New Naming Convention

Part 4: The New Tools & Syntax 🚀

1. Control Flow is More Than Syntactic Sugar

2. Zoneless: Escaping the "Magic" of Change Detection

Figma like input field in Angular using Directives

Scrubber Directive - the core functionality

How to use the scrubber directive

See it in action

Code & Demo

Connect with me

Announcing the Alpha Release of xstate-ngx!

What is xstate-ngx

Why Alpha?

Getting Started

Example: Simple Toggle Machine

Special Thanks

Join the Conversation

Testing NgRx Store with Cypress Component Testing

What is NgRx

Cypress Component Testing

Creating Our Store

Writing our First Test

Beyond The Basics

Tool 1: `get_best_practices`

Tool 2: `onpush_zoneless_migration`

Tool 3: `search_documentation`

The `AGENTS.md` file is AI-platform agnostic