Ever looked at @Component, @Injectable, or @Input in Angular and wondered — "Can I make my own decorator magic?"

If yes, you're about to unlock one of the most elegant and underused features in TypeScript: decorators.

This article dives deep into 10 practical and powerful decorator patterns, not just theory—but hands-on, demo-style code you can apply right now in your Angular or vanilla TypeScript projects. We’ll cover class decorators, method decorators, property decorators, and accessor decorators with clarity and purpose.

At the end, you’ll know how to:

• Create and apply custom decorators
• Use decorators to inject behavior, log automatically, validate data, and memoize functions
• Write cleaner, DRY-er, and scalable Angular code
• Think like an advanced frontend developer

Let’s get started.

1. Logging Methods Automatically with a Method Decorator

function LogMethod(
  target: Object,
  propertyName: string,
  descriptor: PropertyDescriptor
) {
  const original = descriptor.value;

  descriptor.value = function (...args: any[]) {
    console.log(`Calling ${propertyName} with`, args);
    const result = original.apply(this, args);
    console.log(`Returned from ${propertyName} with`, result);
    return result;
  };
}

Usage:

class MathService {
  @LogMethod
  add(a: number, b: number): number {
    return a + b;
  }
}

new MathService().add(2, 3); // Logs input and output

2. Property Validation Decorator

function Required(target: any, propertyKey: string) {
  let value = target[propertyKey];

  const getter = () => value;
  const setter = (newVal: any) => {
    if (!newVal) {
      throw new Error(`${propertyKey} is required.`);
    }
    value = newVal;
  };

  Object.defineProperty(target, propertyKey, {
    get: getter,
    set: setter,
  });
}

Usage:

class User {
  @Required
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

new User(""); // Throws error

3. Creating a Custom Angular Service Decorator

export function SingletonService() {
  return function (target: any) {
    Reflect.defineMetadata('singleton', true, target);
  };
}

Usage:

@SingletonService()
@Injectable({ providedIn: 'root' })
export class MyService {}

4. Memoize Expensive Computations

function Memoize(_: any, key: string, descriptor: PropertyDescriptor) {
  const original = descriptor.value;
  const cache = new Map();

  descriptor.value = function (...args: any[]) {
    const hash = JSON.stringify(args);
    if (cache.has(hash)) {
      return cache.get(hash);
    }
    const result = original.apply(this, args);
    cache.set(hash, result);
    return result;
  };
}

Usage:

class MathEngine {
  @Memoize
  fib(n: number): number {
    if (n <= 1) return n;
    return this.fib(n - 1) + this.fib(n - 2);
  }
}

5. Role-Based Access Control

function Role(role: string) {
  return function (target: any, key: string, descriptor: PropertyDescriptor) {
    const original = descriptor.value;
    descriptor.value = function (...args: any[]) {
      const userRole = 'admin'; // Mock example
      if (userRole !== role) {
        throw new Error(`Unauthorized access to ${key}`);
      }
      return original.apply(this, args);
    };
  };
}

Usage:

class AdminPanel {
  @Role('admin')
  deleteUser(userId: string) {
    console.log(`User ${userId} deleted`);
  }
}

6. Debounce Function Calls

function Debounce(ms: number) {
  return function (_: any, key: string, descriptor: PropertyDescriptor) {
    const original = descriptor.value;
    let timeout: any;

    descriptor.value = function (...args: any[]) {
      clearTimeout(timeout);
      timeout = setTimeout(() => original.apply(this, args), ms);
    };
  };
}

Usage:

class SearchBar {
  @Debounce(300)
  onInputChange(value: string) {
    console.log('Search for', value);
  }
}

7. Readonly Properties with a Property Decorator

function Readonly(target: any, propertyKey: string) {
  Object.defineProperty(target, propertyKey, {
    writable: false,
  });
}

Usage:

class Settings {
  @Readonly
  appName = 'MyApp';
}

8. Auto-Bind Method to Context

function Autobind(_: any, _2: string, descriptor: PropertyDescriptor) {
  const original = descriptor.value;
  return {
    configurable: true,
    get() {
      return original.bind(this);
    },
  };
}

Usage:

class ButtonHandler {
  @Autobind
  onClick() {
    console.log('Clicked by', this);
  }
}

9. Custom @Component Wrapper in Angular

export function EnhancedComponent(metadata: Component) {
  return function (target: any) {
    Component(metadata)(target);
    // Add your enhancements here
  };
}

Usage:

@EnhancedComponent({
  selector: 'app-enhanced',
  template: `<p>Enhanced Component</p>`,
})
export class EnhancedComponentDemo {}

10. Custom Date Formatter Decorator

function FormatDate(_: any, key: string, descriptor: PropertyDescriptor) {
  const original = descriptor.get;

  descriptor.get = function () {
    const result = original!.apply(this);
    return new Date(result).toLocaleDateString();
  };
}

Usage:

class Invoice {
  private rawDate = '2025-05-24T12:00:00Z';

  @FormatDate
  get createdAt() {
    return this.rawDate;
  }
}

Final Thoughts

Decorators aren’t just for Angular—they’re a powerful metaprogramming tool available to all TypeScript developers. Whether you're streamlining UI logic in Angular, reducing boilerplate, or creating testable, reusable utility patterns, decorators can take your code from good to great.

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally
• 🎥 Threads — Short-form frontend insights
• 🐦 X (Twitter) — Developer banter + code snippets
• 👥 BlueSky — Stay up to date on frontend trends
• 🌟 GitHub Projects — Explore code in action
• 🌐 Website — Everything in one place
• 📚 Medium Blog — Long-form content and deep-dives
• 💬 Dev Blog — Free Long-form content and deep-dives
• ✉️ Substack — Weekly frontend stories & curated resources
• 🧩 Portfolio — Projects, talks, and recognitions
• ✍️ Hashnode — Developer blog posts & tech discussions
• ✍️ Reddit — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap
• Drop a 💬 Comment
• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠🚀

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Angular’s withInMemoryScrolling feature addresses this gap by giving the router control over scroll behavior during navigation. It provides declarative configuration for two critical scroll-related features: scroll position restoration across route changes and fragment-based anchor scrolling.

Developers should care about this feature when building applications where users frequently navigate between routes and expect intuitive scroll behavior — particularly in content-heavy applications, e-commerce platforms with list-detail patterns, dashboards with tabbed interfaces, or any application where preserving navigation context improves usability.

What is withInMemoryScrolling

withInMemoryScrolling is a router feature function introduced in Angular’s standalone API era that enables the router to manage scroll behavior during navigation events. The “in-memory” designation refers to how Angular stores scroll positions: it maintains a map of scroll positions in memory, keyed by navigation state, rather than relying on browser-native mechanisms.

At the router level, this works through integration with Angular’s navigation lifecycle. When a navigation begins, the router captures the current scroll position. When a navigation completes, it determines whether to restore a previous position, scroll to top, scroll to an anchor, or leave the scroll position unchanged. This decision is made based on the configuration options and the navigation context (forward navigation, back navigation, route reload, etc.).

The critical difference between browser default scrolling and Angular router-controlled scrolling lies in control and consistency. Browser scroll restoration works at the document level and can be unreliable in SPAs where the DOM is dynamically replaced. Angular’s approach operates within the application’s routing context, providing deterministic behavior that accounts for lazy loading, route transitions, and application-specific navigation patterns.

Configuration in Modern Angular

In modern Angular applications using standalone components and the provideRouter API, withInMemoryScrolling is configured as a router feature alongside other router capabilities.

import { ApplicationConfig } from ‘@angular/core’;
import { provideRouter, withInMemoryScrolling } from ‘@angular/router’;
import { routes } from ‘./app.routes’;

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withInMemoryScrolling({
        scrollPositionRestoration: ‘enabled’,
        anchorScrolling: ‘enabled’
      })
    )
  ]
};

In the standalone bootstrap approach:

import { bootstrapApplication } from ‘@angular/platform-browser’;
import { provideRouter, withInMemoryScrolling } from ‘@angular/router’;
import { AppComponent } from ‘./app/app.component’;
import { routes } from ‘./app/app.routes’;

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(
      routes,
      withInMemoryScrolling({
        scrollPositionRestoration: ‘enabled’,
        anchorScrolling: ‘enabled’
      })
    )
  ]
});

The withInMemoryScrolling function accepts a configuration object with two primary options:

scrollPositionRestoration: Controls how scroll positions are managed during navigation. Accepts 'disabled', 'enabled', or 'top'.

anchorScrolling: Enables or disables automatic scrolling to fragment identifiers in URLs. Accepts 'enabled' or 'disabled'.

Scroll Restoration Strategies

‘disabled’

This strategy completely disables Angular’s scroll management. The scroll position remains wherever it was when navigation occurs. This is the default behavior if withInMemoryScrolling is not configured.

Use cases for 'disabled':

• Applications implementing custom scroll behavior

• Infinite scroll implementations that manage their own position

• Single-route applications where scroll restoration isn’t relevant

• Performance-critical applications minimizing router overhead

UX implications: Users navigating back will stay at the top of the previous page rather than returning to their prior position. This can be disorienting in list-detail patterns.

withInMemoryScrolling({
  scrollPositionRestoration: ‘disabled’
})

‘enabled’

This strategy restores scroll positions when navigating backward or forward through browser history, but scrolls to the top on new forward navigations. This mimics traditional browser behavior in a SPA context.

Use cases for 'enabled':

• E-commerce platforms with product listings

• Content management systems

• Any list-to-detail navigation pattern

• Applications where users browse and return frequently

UX implications: Provides intuitive navigation experience consistent with traditional websites. Users expect to return to their scroll position when hitting back, which this strategy delivers.

withInMemoryScrolling({
  scrollPositionRestoration: ‘enabled’
})

‘top’

This strategy always scrolls to the top of the page on every navigation, regardless of direction.

Read the Complete Article on Medium

This post is a condensed overview of Angular’s withInMemoryScrolling feature.

The full, in-depth article on Medium includes:

• Complete explanation of scroll restoration in SPAs

• Angular Router lifecycle and internal behavior

• Real-world use cases (list → detail → back, dashboards, content pages)

• Edge cases (lazy loading, SSR, hydration, virtual scroll conflicts)

• Performance and accessibility considerations

• Step-by-step demo walkthrough

• Sample code and configuration examples

Read the full article, explore the demo, and access the complete code here:
Read Full Article

**🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

• ✍️ Reddit — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

This isn't a bug. It's how Angular handles component rendering. But here's the thing: most developers don't realize there are multiple ways to move components in Angular, and they behave very differently. Some recreate your component from scratch. Others actually move the live instance, preserving all state.

In this article, we'll explore three approaches to moving components across your layout: ngTemplateOutlet, CDK Template Portal, and CDK DOM Portal. By the end, you'll understand exactly when Angular recreates your views and how to preserve component state when moving elements across your application.

Let's dive into a real-world scenario and see what's actually happening under the hood.

The Problem: Moving Components Kills State

Imagine you're building an admin dashboard with a promotional banner. This banner has interactive elements: a heart button users can click and a live timer counting up. Initially, the banner displays in the sidebar, but users can click a button to move it to the main content area.

Here's what happens with a naive implementation:

import { Component, signal } from '@angular/core';
import { PromoBannerComponent } from './promo-banner.component';

@Component({
  selector: 'app-root',
  imports: [PromoBannerComponent],
   styles: [
    `
  .bottom {
    display: flex;
  justify-content: center
  align-items: center;
  height: 100vh; 
  }
`,
  ],
  template: `
    <div class="dashboard">
      <header>
        <button (click)="toggleRegion()">Toggle Banner Position</button>
      </header>

      <div class="layout">
        @if (dockRight()) {
          <main>
            <app-promo-banner />
          </main>
        }

         <aside class="bottom">
          @if (!dockRight()) {
            <app-promo-banner />
          }
        </aside>
      </div>
    </div>
  `
})
export class AppComponent {
  dockRight = signal(false);

  toggleRegion() {
    this.dockRight.update(value => !value);
  }
}

When you click the toggle button, the banner moves—but the heart button resets and the timer starts over from zero. Why?

Because you're not actually moving the component. You're destroying it in one location and creating a brand new instance in another. The conditional rendering removes the component from the DOM entirely, then Angular initializes a fresh instance elsewhere.

Think of it like moving houses. You're not picking up your house and relocating it—you're demolishing it, then building an identical new house somewhere else. Everything inside gets lost in the process.

Can we do better? Let's explore three different approaches.

Approach 1: Using ngTemplateOutlet

The first instinct might be to use Angular's ngTemplateOutlet directive. This lets you define a template once and stamp it out in multiple locations. Sounds promising, right?

Here's how you'd implement it:

import { Component, signal } from '@angular/core';
import { NgTemplateOutlet } from '@angular/common';
import { PromoBannerComponent } from './promo-banner.component';

@Component({
  selector: 'app-root',
  imports: [NgTemplateOutlet, PromoBannerComponent],
  styles: [
    `
  .bottom {
    display: flex;
  justify-content: center
  align-items: center;
  height: 100vh; 
  }
`,
  ],
  template: `
    <div class="dashboard">
      <header>
        <button (click)="toggleRegion()">Toggle Banner Position</button>
      </header>

      <ng-template #promoBanner>
        <app-promo-banner />
      </ng-template>

      <div class="layout">
        @if (dockRight()) {
          <main>
            <ng-template [ngTemplateOutlet]="promoBanner" />
          </main>
        }

         <aside class="bottom">
          @if (!dockRight()) {
            <ng-template [ngTemplateOutlet]="promoBanner" />
           }
          </aside>        
      </div>
    </div>
  `
})
export class AppComponent {
  dockRight = signal(false);

  toggleRegion() {
    this.dockRight.update(value => !value);
  }
}

You define the banner component once inside an ng-template with a template reference variable. Then you use ngTemplateOutlet to render it in either location based on the condition.

This feels like it should work. You're reusing the same template definition, so surely the state should persist?

Unfortunately, no. The state still resets when you toggle the position. Click the heart, move the banner, and watch it reset.

Here's why: ngTemplateOutlet creates a new embedded view each time it attaches. You're reusing the template definition, but Angular still creates a fresh component instance every time. New view equals new component instance equals new state.

It's like having a blueprint for a house. Sure, you're using the same blueprint in both locations, but you're still building a new house from scratch each time.

Approach 2: CDK Template Portal

Angular CDK provides a Portal module with more sophisticated ways to move content. Let's try the Template Portal approach.

First, you need to install Angular CDK if you haven't already:

npm install @angular/cdk

Now let's refactor our component to use a Template Portal:

The complete, code-heavy deep dive (with diagrams, explanations, and tests) is published.

Read the full article

Are you still waiting minutes for your Angular test suite to run? What if I told you that you could cut that time by 50% or more?

With Angular 21, the framework has officially moved away from Jasmine and Karma in favor of Vitest as the default testing framework. If you’re working on an existing Angular project, you might be wondering: “How do I migrate without breaking everything?”

In this guide, you’ll learn:

• How to manually configure Vitest in your existing Angular project

• Step-by-step migration from Jasmine/Karma to Vitest

• Common pitfalls and how to avoid them

• Advanced configuration tips for real browser testing

• How to write modern unit tests with the latest Angular syntax

By the end of this article, you’ll have a fully functional Vitest setup that runs faster, provides better developer experience, and supports modern testing patterns.

Let’s dive in.

Why Vitest? Understanding the Shift

Angular 21 marks a significant shift in the testing landscape. The Angular team has deprecated Karma and Jasmine in favor of Vitest for several compelling reasons:

Speed: Vitest is built on Vite, offering near-instant test startup and hot module replacement. Your tests run in milliseconds, not seconds.

Modern API: While maintaining compatibility with Jasmine-style syntax, Vitest offers a more modern, flexible API that aligns with current JavaScript testing practices.

Browser and Node Support: Unlike Karma, Vitest can run tests in both Node environments (with jsdom) and real browsers using Playwright.

Better Developer Experience: Built-in watch mode, clear error messages, and seamless TypeScript support make debugging a breeze.

Have you ever felt frustrated waiting for Karma to spin up? That frustration ends here.

Prerequisites

Before we start, make sure you have:

• An existing Angular project (any version, but we’ll focus on 21+)

• Node.js 18+ installed

• Basic familiarity with Angular testing concepts

Don’t worry if you’re new to Vitest—we’ll cover everything you need to know.

Step 1: Installing Vitest and Dependencies

First, let’s install Vitest and the necessary dependencies:

npm install -D vitest @vitest/browser jsdom

Here’s what each package does:

• vitest: The core testing framework

• @vitest/browser: Enables browser-based testing with Playwright

• jsdom: Simulates a browser environment in Node.js

If you plan to use real browser testing (recommended for component tests), also install Playwright:

npm install -D @vitest/browser playwright

Quick tip: Check your package.json to ensure these are added under devDependencies.

Step 2: Configuring angular.json

This is where the magic happens. Open your angular.json file and locate your project’s test configuration. We need to replace the Karma builder with Angular’s new Vitest builder.

Before (Karma configuration):

"test": {
  "builder": "@angular-devkit/build-angular:karma",
  "options": {
    "karmaConfig": "karma.conf.js",
    "polyfills": ["zone.js", "zone.js/testing"],
    "tsConfig": "tsconfig.spec.json",
    "assets": ["src/favicon.ico", "src/assets"]
  }
}

After (Vitest configuration):

"test": {
  "builder": "@angular/build:unit-test",
  "options": {
    "polyfills": ["zone.js", "zone.js/testing"],
    "tsConfig": "tsconfig.spec.json",
    "assets": ["src/favicon.ico", "src/assets"]
  }
}

Notice these changes:

1. Builder changed from @angular-devkit/build-angular:karma to @angular/build:unit-test

2. Removed the karmaConfig option

3. Kept essential options like polyfills, tsConfig, and assets

Save the file and let’s move forward.

Step 3: Removing Karma

Time to clean up. Let’s uninstall all Karma-related packages:

npm uninstall karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter @types/jasmine jasmine-core

Next, delete these files from your project root if they exist:

• karma.conf.js

• src/test.ts (if you have it)

Pro tip: Use your version control to double-check what you’re removing. You can always revert if needed.

Step 4: Running Your First Test with Vitest

Here’s the beautiful part: your existing Jasmine tests will mostly work without changes. Let’s see it in action.

Run your tests:

ng test

Vitest will start, and you’ll see output similar to:

RUN  v2.1.8

✓ src/app/app.component.spec.ts (4 tests) 234ms
✓ src/app/services/data.service.spec.ts (3 tests) 156ms

Test Files  2 passed (2)
     Tests  7 passed (7)

Notice how much faster it is compared to Karma?

API Compatibility:

Vitest maintains compatibility with most Jasmine functions:

• describe() - Test suites

• it() - Individual tests

• beforeEach() - Setup before each test

• beforeAll() - Setup before all tests

• afterEach() - Cleanup after each test

• expect() - Assertions

Key Differences:

Instead of Jasmine’s focused tests:

// Old Jasmine way
fdescribe('Focused suite', () => {});
fit('Focused test', () => {});

Use Vitest’s syntax:

// New Vitest way
describe.only('Focused suite', () => {});
it.only('Focused test', () => {});

Step 5: Fixing TypeScript Typings

You might notice TypeScript errors about describe, it, or expect not being defined. This happens because Vitest doesn’t pollute the global namespace by default (which is actually a good thing).

Update your tsconfig.spec.json:

Before:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jasmine"]
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

After:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["vitest/globals"]
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

Changed "types": ["jasmine"] to "types": ["vitest/globals"].

Better Approach - Explicit Imports:

Instead of relying on global types, import Vitest functions explicitly in your test files:

import { describe, it, expect, beforeEach } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { AppComponent } from './app.component';

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

  it('should create the app', () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app).toBeTruthy();
  });
});

This approach is cleaner, more explicit, and enables better tree-shaking.

Automated Migration:

Angular provides an experimental schematic to add imports automatically:

ng test --migrate --add-imports

This will scan your test files and add the necessary imports. However, review the changes carefully.

Step 6: Writing Modern Angular Tests with Vitest

Let’s write a complete example using Angular 21’s latest syntax with standalone components and signal-based inputs.

Component to Test:

// user-profile.component.ts
import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-user-profile',
  template: `
    <div class="profile">
      <h2>{{ displayName() }}</h2>
      @if (isAdmin()) {
        <span class="badge">Admin</span>
      }
      <p>Email: {{ email() }}</p>
    </div>
  `,
  styles: [`
    .profile { padding: 20px; }
    .badge { color: red; font-weight: bold; }
  `]
})
export class UserProfileComponent {
  firstName = input.required<string>();
  lastName = input.required<string>();
  email = input.required<string>();
  role = input<string>('user');

  displayName = computed(() =>
    `${this.firstName()} ${this.lastName()}`
  );

  isAdmin = computed(() =>
    this.role() === 'admin'
  );
}

Unit Test:

// user-profile.component.spec.ts
import { describe, it, expect, beforeEach } from 'vitest';
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { UserProfileComponent } from './user-profile.component';

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

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

    fixture = TestBed.createComponent(UserProfileComponent);
    component = fixture.componentInstance;
  });

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

  it('should display full name correctly', () => {
    fixture.componentRef.setInput('firstName', 'John');
    fixture.componentRef.setInput('lastName', 'Doe');
    fixture.componentRef.setInput('email', 'john@example.com');
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    expect(compiled.querySelector('h2').textContent).toBe('John Doe');
  });

  it('should show admin badge when role is admin', () => {
    fixture.componentRef.setInput('firstName', 'Jane');
    fixture.componentRef.setInput('lastName', 'Smith');
    fixture.componentRef.setInput('email', 'jane@example.com');
    fixture.componentRef.setInput('role', 'admin');
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    const badge = compiled.querySelector('.badge');
    expect(badge).toBeTruthy();
    expect(badge.textContent).toBe('Admin');
  });

  it('should not show admin badge for regular users', () => {
    fixture.componentRef.setInput('firstName', 'Bob');
    fixture.componentRef.setInput('lastName', 'Wilson');
    fixture.componentRef.setInput('email', 'bob@example.com');
    fixture.componentRef.setInput('role', 'user');
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    const badge = compiled.querySelector('.badge');
    expect(badge).toBeNull();
  });

  it('should compute display name from first and last name', () => {
    fixture.componentRef.setInput('firstName', 'Alice');
    fixture.componentRef.setInput('lastName', 'Johnson');
    fixture.componentRef.setInput('email', 'alice@example.com');

    expect(component.displayName()).toBe('Alice Johnson');
  });
});

Key Points:

• Using imports: [UserProfileComponent] instead of declarations (standalone architecture)

• Using fixture.componentRef.setInput() to set signal-based inputs

• Testing computed signals directly

• Testing template control flow with @if

Step 7: Testing Services with Vitest

Let’s test a service that uses signals and modern Angular features:

Service:

// user.service.ts
import { Injectable, signal, computed } from '@angular/core';
import { HttpClient } from '@angular/common/http';

export interface User {
  id: number;
  name: string;
  email: string;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  private users = signal<User[]>([]);

  allUsers = this.users.asReadonly();
  userCount = computed(() => this.users().length);

  constructor(private http: HttpClient) {}

  loadUsers() {
    return this.http.get<User[]>('/api/users').subscribe(
      users => this.users.set(users)
    );
  }

  addUser(user: User) {
    this.users.update(current => [...current, user]);
  }

  removeUser(id: number) {
    this.users.update(current =>
      current.filter(u => u.id !== id)
    );
  }
}

Unit Test:

// user.service.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService, User } from './user.service';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [UserService]
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });

  it('should load users from API', () => {
    const mockUsers: User[] = [
      { id: 1, name: 'John', email: 'john@test.com' },
      { id: 2, name: 'Jane', email: 'jane@test.com' }
    ];

    service.loadUsers();

    const req = httpMock.expectOne('/api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);

    expect(service.allUsers()).toEqual(mockUsers);
    expect(service.userCount()).toBe(2);
  });

  it('should add a new user', () => {
    const newUser: User = {
      id: 3,
      name: 'Bob',
      email: 'bob@test.com'
    };

    service.addUser(newUser);

    expect(service.allUsers()).toContain(newUser);
    expect(service.userCount()).toBe(1);
  });

  it('should remove a user by id', () => {
    const users: User[] = [
      { id: 1, name: 'John', email: 'john@test.com' },
      { id: 2, name: 'Jane', email: 'jane@test.com' }
    ];

    users.forEach(user => service.addUser(user));
    expect(service.userCount()).toBe(2);

    service.removeUser(1);

    expect(service.userCount()).toBe(1);
    expect(service.allUsers().find(u => u.id === 1)).toBeUndefined();
    expect(service.allUsers().find(u => u.id === 2)).toBeTruthy();
  });

  it('should compute user count correctly', () => {
    expect(service.userCount()).toBe(0);

    service.addUser({ id: 1, name: 'Test', email: 'test@test.com' });
    expect(service.userCount()).toBe(1);

    service.addUser({ id: 2, name: 'Test2', email: 'test2@test.com' });
    expect(service.userCount()).toBe(2);
  });
});

Notice how we’re testing signal-based state management and computed signals directly.

Step 8: Advanced Configuration with vitest.config.ts

For more control over your testing environment, create a vitest.config.ts file in your project root:

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: false, // Disable global APIs
    environment: 'jsdom', // Use jsdom for DOM simulation
    setupFiles: ['src/test-setup.ts'], // Global setup file
    include: ['src/**/*.spec.ts'], // Test file pattern
    coverage: {
      provider: 'v8',
      reporter: ['text', 'html', 'lcov'],
      exclude: [
        'node_modules/',
        'src/test-setup.ts',
      ]
    }
  }
});

Configuration Options Explained:

• globals: false - Requires explicit imports (cleaner, more maintainable)

• environment: 'jsdom' - Fast Node-based DOM simulation

• setupFiles - Code to run before all tests

• coverage - Configure code coverage reporting

Create setup file:

// src/test-setup.ts
import 'zone.js';
import 'zone.js/testing';
import { getTestBed } from '@angular/core/testing';
import {
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting
} from '@angular/platform-browser-dynamic/testing';

// Initialize Angular testing environment
getTestBed().initTestEnvironment(
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting()
);

Step 9: Real Browser Testing with Playwright

For end-to-end component testing in real browsers, configure Vitest to use Playwright:

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: false,
    browser: {
      enabled: true,
      name: 'chromium', // or 'firefox', 'webkit'
      provider: 'playwright',
      headless: true,
      screenshotOnFailure: true
    },
    include: ['src/**/*.spec.ts']
  }
});

Benefits of Browser Testing:

• Tests run in actual browser environments

• More accurate DOM behavior

• Better debugging with browser DevTools

• Support for Chrome, Firefox, and Safari

Example browser test:

import { describe, it, expect } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { AppComponent } from './app.component';

describe('AppComponent (Browser)', () => {
  it('should render in real browser', async () => {
    await TestBed.configureTestingModule({
      imports: [AppComponent]
    }).compileComponents();

    const fixture = TestBed.createComponent(AppComponent);
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    expect(compiled.querySelector('h1')).toBeTruthy();
  });
});

Run browser tests:

ng test --browser

Common Pitfalls and How to Avoid Them

Pitfall 1: Global type conflicts

If you see errors like “Cannot find name ‘describe’”, you likely have conflicting types.

Solution: Use explicit imports and set globals: false in your config.

Pitfall 2: Zone.js issues

Some async tests might fail due to Zone.js timing.

Solution: Ensure zone.js polyfills are loaded in your test configuration:

"polyfills": ["zone.js", "zone.js/testing"]

Pitfall 3: Slow test startup

If tests still feel slow, you might be running in browser mode unnecessarily.

Solution: Use jsdom for unit tests, reserve browser mode for integration tests.

Pitfall 4: Missing TestBed configuration

Forgetting to configure TestBed properly is a common mistake.

Solution: Always initialize in beforeEach:

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

Bonus Tips for Maximum Productivity

Tip 1: Watch Mode

Run tests in watch mode for instant feedback:

ng test --watch

Vitest will re-run only affected tests when you save files.

Tip 2: Run Specific Tests

Focus on specific tests during development:

it.only('should test this specific case', () => {
  // Only this test runs
});

Tip 3: Skip Tests Temporarily

it.skip('will implement this later', () => {
  // Skipped
});

Tip 4: Code Coverage

Generate coverage reports:

ng test --coverage

Open coverage/index.html to see detailed reports.

Tip 5: Parallel Execution

Vitest runs tests in parallel by default. For sequential execution:

// vitest.config.ts
export default defineConfig({
  test: {
    pool: 'threads',
    poolOptions: {
      threads: {
        singleThread: true
      }
    }
  }
});

Recap: What We Learned

Let’s summarize the key takeaways:

1. Installation: Added Vitest, jsdom, and Playwright to replace Karma/Jasmine

2. Configuration: Updated angular.json to use the new unit-test builder

3. Cleanup: Removed Karma dependencies and configuration files

4. TypeScript: Fixed typings by updating tsconfig.spec.json

5. Modern Syntax: Wrote tests using signal-based inputs and standalone components

6. Advanced Setup: Configured vitest.config.ts for custom behavior

7. Browser Testing: Set up Playwright for real browser testing

8. Best Practices: Learned common pitfalls and productivity tips

Migration to Vitest is straightforward, and the benefits are immediate: faster tests, better DX, and modern tooling. Your test suite will run in a fraction of the time, and you’ll enjoy a smoother development workflow.

Take Action Now

Ready to supercharge your Angular testing workflow? Here’s what to do:

1. Back up your current test configuration

2. Follow the steps above in a feature branch

3. Run your existing tests and fix any issues

4. Gradually adopt explicit imports and modern patterns

5. Share your migration experience with the community

What challenges did you face during migration? Did this guide help you get unstuck?

Drop a comment below with your biggest testing pain point, and let’s solve it together.

Found this helpful? Give it a clap so other developers can discover this guide too.

Want more Angular tips, performance tricks, and modern development practices? Follow me for weekly insights that will level up your skills.

Have a specific topic you’d like me to cover next? Let me know in the comments. I read every single one and love hearing what you want to learn.

Happy testing, and may your test suites run blazingly fast!

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

In this article, you will learn how to use npx knip to detect and eliminate dead code, unused exports, redundant dependencies, and more—all without installing anything permanently. By the end, you will have a clear action plan to clean up your JavaScript or TypeScript project and keep it lean going forward.

Let me ask you this: When was the last time you audited your dependencies or checked for unused exports? If the answer is "never" or "I don't remember," keep reading.

What is Knip and Why Should You Care?

Knip is a comprehensive tool that analyzes your JavaScript and TypeScript projects to find:

• Unused files that are no longer imported anywhere

• Unused dependencies sitting in your package.json

• Unused exports from modules

• Unused types in TypeScript files

• Unreachable code and much more

Think of Knip as a linter for your entire project structure, not just your code syntax. It works with Angular, React, Next.js, Vue, Node.js, and virtually any JavaScript ecosystem project.

The best part? You can run it with npx knip without installing it globally. That means zero setup friction.

💬 Quick question: Have you ever deleted a component or service only to realize later that its imports are still scattered across your codebase? Drop a comment below—I would love to hear your cleanup horror stories.

Getting Started with Knip

Let's dive straight into action. Here is how you run Knip on any project.

Step 1: Run Knip with npx

Navigate to your project root and run:

npx knip

That is it. Knip will analyze your project and show you a report of unused files, dependencies, and exports.

Sample Output:

Unused files (3)
  src/utils/old-helper.ts
  src/components/legacy-modal.component.ts
  src/services/deprecated-api.service.ts

Unused dependencies (5)
  lodash
  moment
  uuid
  axios
  rxjs-compat

Unused exports (12)
  calculateTax in src/utils/math.ts
  parseDate in src/utils/date-parser.ts
  LegacyUser in src/models/user.model.ts

This output immediately tells you what is safe to remove. But before you start deleting, let's understand how Knip works.

How Knip Works Under the Hood

Knip uses static analysis to trace your codebase. It starts from your entry points (like main.ts, app.component.ts, or index.ts) and follows all imports to build a dependency graph.

Anything not reachable from these entry points gets flagged as unused. Here is what makes Knip smart:

1. Framework-aware: It understands Angular modules (though we use standalone now), React components, Next.js pages, and more

2. Configurable: You can tell Knip about custom entry points or ignore certain patterns

3. Fast: It analyzes thousands of files in seconds

Real-World Example: Cleaning Up an Angular Project

Let's say you have an Angular 18 application using standalone components. Over time, you have accumulated unused services, old components, and forgotten utility functions. Here is how Knip helps.

Project Structure Before Cleanup:

src/
├── app/
│   ├── components/
│   │   ├── user-list.component.ts
│   │   ├── user-detail.component.ts
│   │   └── old-dashboard.component.ts  // unused
│   ├── services/
│   │   ├── user.service.ts
│   │   ├── auth.service.ts
│   │   └── legacy-api.service.ts  // unused
│   └── utils/
│       ├── format.ts
│       └── old-helpers.ts  // unused
└── main.ts

Running Knip:

npx knip

Knip Output:

Unused files (2)
  src/app/components/old-dashboard.component.ts
  src/app/services/legacy-api.service.ts

Unused exports (3)
  oldHelperFunction in src/app/utils/old-helpers.ts
  formatCurrency in src/app/utils/format.ts
  deprecatedMethod in src/app/services/user.service.ts

Now you know exactly what to remove. But wait—what if Knip is wrong?

Configuring Knip for Your Project

Sometimes Knip flags code that looks unused but is actually needed. For example:

• Entry points that Knip doesn't know about

• Dynamic imports

• Code used only in tests

You can configure Knip using a knip.json or knip.ts file.

Example Configuration:

{
  "entry": ["src/main.ts", "src/polyfills.ts"],
  "project": ["src/**/*.ts"],
  "ignore": ["src/**/*.spec.ts", "src/environments/**"],
  "ignoreDependencies": ["@types/*"]
}

This tells Knip:

• Where your entry points are

• Which files to analyze

• What to ignore (like test files)

• Which dependencies to skip (like type definitions)

👏 If this is making sense so far, hit that clap button—it helps other devs discover this too.

Integrating Knip into Your CI/CD Pipeline

Once you have cleaned up your codebase, you want to keep it clean. The best way? Run Knip in your CI pipeline.

GitHub Actions Example:

name: Code Health Check

on: [push, pull_request]

jobs:
  knip:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install
      - run: npx knip

Now every pull request gets checked for dead code automatically. If someone adds unused code, the build fails. Simple and effective.

Handling Common Knip Warnings

Let's address some scenarios you might encounter:

1. False Positives with Dynamic Imports

If you use dynamic imports like this:

const moduleName = 'user-dashboard';
import(`./modules/${moduleName}.component`);

Knip might not detect these. Solution: Add them to your entry points or use the ignore configuration.

2. Unused Dependencies That Are Actually Needed

Some packages like @angular/animations are needed at runtime but might not show up in your imports. Use ignoreDependencies for these:

{
  "ignoreDependencies": ["@angular/animations", "zone.js"]
}

3. Files Only Used in Production

If certain files are only used in specific environments, you can create environment-specific configurations:

{
  "production": {
    "entry": ["src/main.ts", "src/production-setup.ts"]
  }
}

Testing Your Cleanup with Unit Tests

After removing dead code, you should verify nothing broke. Here is how to write a quick smoke test for an Angular service:

Example: Testing User Service After Cleanup

import { TestBed } from '@angular/core/testing';
import { UserService } from './user.service';
import { provideHttpClient } from '@angular/common/http';
import { provideHttpClientTesting, HttpTestingController } from '@angular/common/http/testing';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        UserService,
        provideHttpClient(),
        provideHttpClientTesting()
      ]
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });

  it('should fetch users successfully', () => {
    const mockUsers = [
      { id: 1, name: 'John' },
      { id: 2, name: 'Jane' }
    ];

    service.getUsers().subscribe(users => {
      expect(users).toEqual(mockUsers);
      expect(users.length).toBe(2);
    });

    const req = httpMock.expectOne('api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);
  });

  it('should handle errors gracefully', () => {
    service.getUsers().subscribe({
      next: () => fail('should have failed'),
      error: (error) => {
        expect(error.status).toBe(500);
      }
    });

    const req = httpMock.expectOne('api/users');
    req.flush('Server error', { status: 500, statusText: 'Server Error' });
  });
});

This ensures your service still works after removing unused methods or dependencies.

💡 Pro tip incoming: Run Knip before and after major refactorings. It is like a safety net that catches orphaned code immediately.

Bonus Tips for Keeping Your Codebase Clean

Here are some practices I follow to prevent dead code accumulation:

1. Run Knip monthly: Set a calendar reminder to audit your codebase

2. Review before merging: Make Knip checks part of your PR review process

3. Delete aggressively: If code is unused for 3+ months, it is probably safe to remove

4. Use feature flags: Instead of commenting out code, use feature flags and delete the code when the flag is removed

5. Document why code exists: If something looks unused but isn't, add a comment explaining why

Comparing Knip to Other Tools

You might be wondering: "How is Knip different from ESLint or Depcheck?"

Knip is the most comprehensive for finding structural waste. Use it alongside ESLint for the best results.

Your Action Plan: Clean Up This Week

Here is what you can do right now:

1. Day 1: Run npx knip on your project and review the report

2. Day 2: Create a knip.json config to tune the results

3. Day 3: Remove obviously unused files and dependencies

4. Day 4: Run your test suite to verify nothing broke

5. Day 5: Add Knip to your CI pipeline

By Friday, you will have a leaner, cleaner codebase.

Recap: What We Covered

Let's wrap up what you learned today:

• What Knip is: A static analysis tool for finding dead code in JavaScript and TypeScript projects

• How to use it: Simply run npx knip in your project root

• Configuration: Customize Knip using knip.json to fit your project structure

• CI Integration: Add Knip to your pipeline to prevent future bloat

• Testing strategy: Write unit tests to verify your cleanup didn't break anything

• Best practices: Run Knip regularly and delete unused code aggressively

The key takeaway? Dead code is not just clutter—it slows down builds, confuses developers, and increases maintenance burden. Knip makes cleaning it up trivial.

Let's Keep the Conversation Going

👇 I want to hear from you:

💬 What percentage of your codebase do you think is unused? Drop your guess in the comments—I am curious to see the range.

👏 If this saved you even 10 minutes of manual searching, smash that clap button. It helps other developers discover this tool too.

📬 Want more practical dev tips like this? Follow me for weekly insights on Angular, TypeScript, and modern frontend development. I share one actionable tip every week.

🔥 Challenge: Run Knip on your project this week and share your results. Tag me with your findings—I will feature the most interesting cleanups in my next article.

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Here's a question for you: Do you actually know where your services end up in production?

If you're like most Angular devs (myself included, until recently), you probably assumed providedIn: 'root' magically optimizes everything. Well, buckle up—we're about to uncover some surprising truths about Angular's dependency injection that could save your app 30-50% in bundle size.

By the end of this article, you'll know:

• The real truth about where providedIn: 'root' services live

• When tree-shaking actually works (and when it fails spectacularly)

• How to optimize your services for a lightweight global context

• Modern Angular patterns that actually make a difference

Let's dive in!

The Myth We All Believed

Quick poll: How many of you thought providedIn: 'root' automatically meant "optimized and tree-shakeable"?

raises hand

Yeah, me too. But here's what's actually happening under the hood...

// Angular  syntax - What we typically write
import { Injectable, inject } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class UserService {
  private readonly http = inject(HttpClient);

  getUser(id: string) {
    return this.http.get(`/api/users/${id}`);
  }
}

Looks clean, right? But here's the kicker: This service might still end up in your main bundle even if it's only used in a lazy-loaded module!

💬 Have you ever analyzed your bundle and found services where they shouldn't be? Drop a comment—I'm curious how common this is!

The Good, The Bad, and The Bundle Size

✅ The Good: When providedIn: 'root' Shines

Let's be clear—providedIn: 'root' isn't evil. It's actually brilliant when used correctly:

// Angular  - Perfect use case for root-provided service
import { Injectable, signal, computed } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class ThemeService {
  // Using signals (Angular 16+)
  private readonly isDarkMode = signal(false);

  readonly theme = computed(() =>
    this.isDarkMode() ? 'dark' : 'light'
  );

  toggleTheme() {
    this.isDarkMode.update(current => !current);
  }
}

Why this works: Global state that's genuinely needed everywhere = perfect for root injection.

❌ The Bad: When Things Go Wrong

Here's where developers get burned:

// This looks innocent but can bloat your main bundle
@Injectable({
  providedIn: 'root'
})
export class HeavyAnalyticsService {
  private readonly analytics = inject(AnalyticsLibrary); // 200KB library
  private readonly featureFlags = inject(FeatureFlagService);
  private readonly logger = inject(LoggingService);

  // Only used in admin module...
  trackAdminAction(action: string) {
    // Complex tracking logic
  }
}

Even if this service is only imported in a lazy-loaded admin module, the entire chain of dependencies might get pulled into your main bundle.

The result? Your users download analytics code they'll never use. Ouch.

The Solution: Smart Service Architecture in Angular

Let me show you three patterns that actually work in production:

Pattern 1: Module-Scoped Services (The Classic)

// feature/admin/services/admin-analytics.service.ts
import { Injectable, inject } from '@angular/core';

@Injectable() // No providedIn!
export class AdminAnalyticsService {
  private readonly analytics = inject(AnalyticsLibrary);

  trackAdminAction(action: string) {
    // Heavy logic stays in the admin module
  }
}

// feature/admin/admin.module.ts
@NgModule({
  providers: [AdminAnalyticsService] // Provided at module level
})
export class AdminModule { }

Pattern 2: Lazy-Injectable Pattern (My Personal Favorite) 🎯

// Angular  with standalone components
import { Injectable, inject } from '@angular/core';

@Injectable({
  providedIn: 'any' // Creates separate instance per lazy module
})
export class FeatureStateService {
  private readonly state = signal<FeatureState>(initialState);

  // Each lazy module gets its own instance
  updateState(updates: Partial<FeatureState>) {
    this.state.update(current => ({ ...current, ...updates }));
  }
}

Pattern 3: Token-Based Injection (For Ultimate Control)

// Angular - Using injection tokens for flexibility
import { InjectionToken, inject } from '@angular/core';

export interface Logger {
  log(message: string): void;
}

export const LOGGER_TOKEN = new InjectionToken<Logger>('Logger');

// In your main.ts
bootstrapApplication(AppComponent, {
  providers: [
    {
      provide: LOGGER_TOKEN,
      useFactory: () => {
        // Only load heavy logger in development
        return environment.production
          ? new SimpleLogger()
          : new DetailedLogger();
      }
    }
  ]
});

// Usage in any component
export class MyComponent {
  private readonly logger = inject(LOGGER_TOKEN);
}

👏 If these patterns just saved you from a refactoring nightmare, hit that clap button! Your future self will thank you.

Let's Test It! Writing Unit Tests in Angular

Here's something most articles skip—how do you actually test these optimized services?

// user.service.spec.ts - Angular testing syntax
import { TestBed } from '@angular/core/testing';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';
import { provideHttpClient } from '@angular/common/http';

describe('UserService', () => {
  let service: UserService;
  let httpTesting: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        provideHttpClient(),
        provideHttpClientTesting(),
        UserService
      ]
    });

    service = TestBed.inject(UserService);
    httpTesting = TestBed.inject(HttpTestingController);
  });

  it('should fetch user with correct endpoint', () => {
    const mockUser = { id: '123', name: 'Dev' };

    service.getUser('123').subscribe(user => {
      expect(user).toEqual(mockUser);
    });

    const req = httpTesting.expectOne('/api/users/123');
    expect(req.request.method).toBe('GET');
    req.flush(mockUser);
  });

  afterEach(() => {
    httpTesting.verify();
  });
});

💡 Pro Tip: Always test your services in isolation first, then test them within their lazy-loaded context to ensure proper scoping!

🎯 Bonus Tips: Bundle Optimization Tricks

1. Use Bundle Analyzer (Your New Best Friend)

# Install webpack-bundle-analyzer
npm install --save-dev webpack-bundle-analyzer

# Add to angular.json
"build": {
  "options": {
    "statsJson": true
  }
}

# Analyze your bundle
ng build --stats-json
npx webpack-bundle-analyzer dist/your-app/stats.json

2. The "Import Cost" VS Code Extension

Install it. Use it. Love it. It shows you the size of every import in real-time. Mind = blown.

3. Lazy Load Everything That's Not Critical

// Angular - Standalone component lazy loading
const routes: Routes = [
  {
    path: 'admin',
    loadComponent: () => import('./admin/admin.component')
      .then(m => m.AdminComponent),
    providers: [AdminService] // Service only loads with component!
  }
];

4. Use Dynamic Imports for Heavy Libraries

// Instead of this
import * as Chart from 'chart.js';

// Do this
async loadChart() {
  const { Chart } = await import('chart.js');
  return new Chart(/* ... */);
}

📊 Quick Recap: Your Action Plan

Let's wrap this up with what you can do right now:

1. Audit your services: Run bundle analyzer today. Find services in wrong bundles.

2. Question every providedIn: 'root': Does it really need to be global?

3. Use providedIn: 'any' for feature-specific services

4. Leverage injection tokens for swappable implementations

5. Test your lazy loading: Ensure services stay where they belong

The golden rule: If a service is only used in a lazy module, it shouldn't be in your main bundle. Period.

🚀 Let's Keep This Conversation Going!

Alright, dev to dev—this stuff matters. Your users on slow connections will thank you, and your Lighthouse scores will love you.

💬 Your turn: What's the biggest bundle size win you've achieved? Got a horror story about a 5MB main bundle? Drop it in the comments—let's learn from each other's pain!

👏 Found this helpful? Smash that clap button (you can hit it up to 50 times, just saying 😉). Every clap helps other devs discover these optimization tricks.

📬 Want more Angular performance tips? I drop one actionable optimization technique every week. [Follow me here] to join 5,000+ devs leveling up their Angular game.

🎯 Action challenge: Analyze your main bundle this week and share your before/after stats in the comments. Best improvement gets a shoutout in my next article!

Remember: Every KB you shave off is a user who doesn't bounce. Let's build faster apps together! 🚀

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Have You Ever Waited 10 Minutes for Your Test Suite to Run?

If you're an Angular developer, you've probably experienced this pain. You make a small change, run your tests, grab coffee, check your phone, and maybe start wondering if you chose the wrong career. Meanwhile, your CI/CD pipeline is burning through minutes (and money) running Karma with Jasmine.

Here's the good news: Angular 21 just changed the game entirely.

The Angular team officially adopted Vitest as the default testing framework, leaving behind the decade-old Karma + Jasmine combo. And this isn't just a minor upgrade—it's a complete paradigm shift in how we think about testing Angular applications.

In this article, you'll discover:

• Why Angular dumped Karma after all these years

• How Vitest makes your tests run 10x faster (seriously)

• Step-by-step migration guide from Jasmine to Vitest

• Real-world examples for testing components, async operations, and browser APIs

• The new ICOV coverage format and why it matters

• Best practices that will make your team's testing workflow smoother

Whether you're maintaining a legacy Angular app or starting fresh with Angular 21, this guide will show you exactly how to leverage Vitest's power. Let's dive in.

What is Vitest? (And Why Angular Finally Made the Switch)

Vitest is a blazing-fast unit testing framework built on top of Vite. Think of it as the modern successor to Jest, but designed specifically for the Vite ecosystem with native ESM support, instant hot module replacement, and TypeScript built right in.

The Karma Problem

Let's be honest—Karma served us well for years, but it was showing its age:

• Slow startup times: Launching a real browser for every test run

• Poor watch mode: Waiting seconds for file changes to register

• Complex configuration: Remember wrestling with webpack configs?

• Flaky tests: Browser timing issues causing random failures

• No native ESM: Forced transpilation slowing everything down

Why Vitest Won

The Angular team didn't make this decision lightly. Here's what tipped the scales:

1. Speed That Actually Matters Vitest runs tests in a Node.js environment with happy-dom or jsdom, eliminating browser overhead. We're talking 10-20x faster execution.

2. Developer Experience That Doesn't Suck Hot module reload in watch mode means instant feedback. Change a test, save, and see results before you even look at the terminal.

3. Modern JavaScript Native Built for ESM from the ground up. No more transpilation gymnastics.

4. TypeScript Without the Headache TypeScript support isn't bolted on—it's core to Vitest's architecture.

5. Future-Proof Architecture As Angular moves toward ESM-only and standalone components, Vitest aligns perfectly with this direction.

Think about it this way: Karma was designed when Internet Explorer 9 was still relevant. Vitest was designed for the JavaScript ecosystem we have today.

Key Features of Vitest in Angular 21

Let's explore what makes Vitest a game-changer with actual code examples.

1. Lightning-Fast Execution

Here's a simple component test to see the speed difference:

// user-profile.component.ts
import { Component, input, output } from '@angular/core';

@Component({
  selector: 'app-user-profile',
  template: `
    <div class="profile-card">
      <h2>{{ name() }}</h2>
      <p>{{ email() }}</p>
      <button (click)="handleEdit()">Edit Profile</button>
    </div>
  `,
  styles: [`
    .profile-card { padding: 1rem; border: 1px solid #ddd; }
  `]
})
export class UserProfileComponent {
  name = input.required<string>();
  email = input.required<string>();
  editClicked = output<void>();

  handleEdit() {
    this.editClicked.emit();
  }
}

Vitest Test:

// user-profile.component.spec.ts
import { describe, it, expect, vi } from 'vitest';
import { ComponentFixture } from '@angular/core/testing';
import { TestBed } from '@angular/core/testing';
import { UserProfileComponent } from './user-profile.component';

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

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

    fixture = TestBed.createComponent(UserProfileComponent);
    component = fixture.componentInstance;
  });

  it('should render user information correctly', () => {
    fixture.componentRef.setInput('name', 'John Doe');
    fixture.componentRef.setInput('email', 'john@example.com');
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    expect(compiled.querySelector('h2')?.textContent).toBe('John Doe');
    expect(compiled.querySelector('p')?.textContent).toBe('john@example.com');
  });

  it('should emit event when edit button is clicked', () => {
    const editSpy = vi.fn();
    component.editClicked.subscribe(editSpy);

    fixture.componentRef.setInput('name', 'Jane Smith');
    fixture.componentRef.setInput('email', 'jane@example.com');
    fixture.detectChanges();

    const button = fixture.nativeElement.querySelector('button');
    button.click();

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

With Karma, this test might take 3-5 seconds to run. With Vitest? Usually under 100ms.

2. Hot Module Reload in Watch Mode

When you run tests in watch mode, Vitest only re-runs tests related to changed files:

ng test --watch

Change your component, save, and boom—instant feedback. No full test suite re-run.

3. Snapshot Testing Made Simple

Snapshot testing helps catch unexpected UI changes:

// navigation.component.spec.ts
import { describe, it, expect } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { NavigationComponent } from './navigation.component';

describe('NavigationComponent Snapshots', () => {
  it('should match snapshot for default state', () => {
    const fixture = TestBed.createComponent(NavigationComponent);
    fixture.detectChanges();

    expect(fixture.nativeElement.innerHTML).toMatchSnapshot();
  });
});

First run creates the snapshot. Subsequent runs compare against it.

4. Built-in Mocking with vi

Vitest's vi utility replaces Jasmine's spy system:

// data.service.ts
import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class DataService {
  private http = inject(HttpClient);

  fetchUsers(): Observable<any[]> {
    return this.http.get<any[]>('/api/users');
  }
}

// data.service.spec.ts
import { describe, it, expect, vi, beforeEach } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { DataService } from './data.service';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';

describe('DataService', () => {
  let service: DataService;
  let httpMock: any;

  beforeEach(() => {
    httpMock = {
      get: vi.fn()
    };

    TestBed.configureTestingModule({
      providers: [
        { provide: HttpClient, useValue: httpMock }
      ]
    });

    service = TestBed.inject(DataService);
  });

  it('should fetch users from API', (done) => {
    const mockUsers = [
      { id: 1, name: 'Alice' },
      { id: 2, name: 'Bob' }
    ];

    httpMock.get.mockReturnValue(of(mockUsers));

    service.fetchUsers().subscribe(users => {
      expect(users).toEqual(mockUsers);
      expect(httpMock.get).toHaveBeenCalledWith('/api/users');
      done();
    });
  });
});

What just happened here? We used vi.fn() to create a mock function—cleaner and more flexible than Jasmine spies.

5. Browser-Like Environment with happy-dom

Vitest uses happy-dom by default, providing DOM APIs without a real browser:

// storage.service.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';

describe('LocalStorage Mocking', () => {
  beforeEach(() => {
    // Clear storage before each test
    localStorage.clear();
  });

  it('should save and retrieve data from localStorage', () => {
    localStorage.setItem('theme', 'dark');
    expect(localStorage.getItem('theme')).toBe('dark');
  });

  it('should handle missing keys gracefully', () => {
    expect(localStorage.getItem('nonexistent')).toBeNull();
  });
});

Happy-dom provides localStorage, sessionStorage, and other browser APIs out of the box.

Have you tried running Angular tests with instant hot reload yet? If not, you're missing out on one of the best DX improvements in years.

Migration from Karma/Jasmine to Vitest: Step-by-Step Guide

Migrating might sound daunting, but Angular 21 makes it surprisingly smooth. Let's walk through it.

Step 1: Update Angular to Version 21

ng update @angular/core@21 @angular/cli@21

Step 2: Add Vitest to Your Project

ng add @angular/vitest

This command automatically:

• Installs Vitest and related dependencies

• Creates vitest.config.ts

• Updates angular.json test configuration

• Migrates existing test setup files

Step 3: Understanding the Configuration

Your new vitest.config.ts will look like this:

// vitest.config.ts
import { defineConfig } from 'vitest/config';
import angular from '@analogjs/vite-plugin-angular';

export default defineConfig({
  plugins: [angular()],
  test: {
    globals: true,
    environment: 'happy-dom',
    setupFiles: ['src/test-setup.ts'],
    include: ['**/*.spec.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html', 'lcov', 'icov'],
      exclude: [
        'node_modules/',
        'src/test-setup.ts',
      ],
      thresholds: {
        lines: 80,
        functions: 80,
        branches: 80,
        statements: 80
      }
    }
  }
});

Step 4: Migrating Test Syntax

Here's a comparison table of common patterns:

Step 5: Real Migration Example

Before (Jasmine):

// auth.service.spec.ts (Jasmine)
import { TestBed } from '@angular/core/testing';
import { AuthService } from './auth.service';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';

describe('AuthService - Jasmine', () => {
  let service: AuthService;
  let httpSpy: jasmine.SpyObj<HttpClient>;

  beforeEach(() => {
    const spy = jasmine.createSpyObj('HttpClient', ['post']);

    TestBed.configureTestingModule({
      providers: [
        AuthService,
        { provide: HttpClient, useValue: spy }
      ]
    });

    service = TestBed.inject(AuthService);
    httpSpy = TestBed.inject(HttpClient) as jasmine.SpyObj<HttpClient>;
  });

  it('should login user successfully', (done) => {
    const mockResponse = { token: 'abc123', user: { id: 1, name: 'John' } };
    httpSpy.post.and.returnValue(of(mockResponse));

    service.login('john@example.com', 'password').subscribe(response => {
      expect(response.token).toBe('abc123');
      expect(httpSpy.post).toHaveBeenCalledWith('/api/auth/login', {
        email: 'john@example.com',
        password: 'password'
      });
      done();
    });
  });
});

After (Vitest):

// auth.service.spec.ts (Vitest)
import { describe, it, expect, beforeEach, vi } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { AuthService } from './auth.service';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';

describe('AuthService - Vitest', () => {
  let service: AuthService;
  let httpMock: any;

  beforeEach(() => {
    httpMock = {
      post: vi.fn()
    };

    TestBed.configureTestingModule({
      providers: [
        AuthService,
        { provide: HttpClient, useValue: httpMock }
      ]
    });

    service = TestBed.inject(AuthService);
  });

  it('should login user successfully', async () => {
    const mockResponse = { token: 'abc123', user: { id: 1, name: 'John' } };
    httpMock.post.mockReturnValue(of(mockResponse));

    const response = await service.login('john@example.com', 'password');

    expect(response.token).toBe('abc123');
    expect(httpMock.post).toHaveBeenCalledWith('/api/auth/login', {
      email: 'john@example.com',
      password: 'password'
    });
  });
});

Key Changes:

• Import from vitest instead of relying on globals

• Use vi.fn() instead of jasmine.createSpyObj()

• Use mockReturnValue() instead of and.returnValue()

• Can use async/await instead of done callback

Step 6: Migrating Async Tests

Jasmine fakeAsync:

it('should handle delayed response', fakeAsync(() => {
  let result: string;
  setTimeout(() => result = 'done', 1000);

  tick(1000);

  expect(result).toBe('done');
}));

Vitest equivalent:

it('should handle delayed response', async () => {
  vi.useFakeTimers();

  let result: string;
  setTimeout(() => result = 'done', 1000);

  await vi.advanceTimersByTimeAsync(1000);

  expect(result).toBe('done');

  vi.useRealTimers();
});

What's your biggest concern about migrating your existing test suite? Is it the time investment or the learning curve?

Coverage in Vitest & Angular 21

Code coverage isn't just a metric—it's a conversation about quality. Here's how to make it work for you in Angular 21.

Enabling Coverage

Run tests with coverage:

ng test --coverage

Or configure it to run automatically in vitest.config.ts:

export default defineConfig({
  test: {
    coverage: {
      enabled: true,
      provider: 'v8', // or 'istanbul'
      reporter: ['text', 'json', 'html', 'lcov', 'icov'],
      reportsDirectory: './coverage',
      exclude: [
        'node_modules/',
        'src/test-setup.ts',
        '**/*.spec.ts',
        '**/*.config.ts',
        '**/index.ts'
      ],
      thresholds: {
        lines: 80,
        functions: 75,
        branches: 70,
        statements: 80
      }
    }
  }
});

Understanding Coverage Providers

Vitest supports two coverage providers:

1. v8 (Default)

• Faster execution

• Native to V8 JavaScript engine

• Better for large codebases

2. Istanbul (c8)

• More detailed reports

• Better source map support

• Industry standard

Setting Coverage Thresholds

Make your CI/CD fail if coverage drops:

coverage: {
  thresholds: {
    lines: 80,
    functions: 80,
    branches: 75,
    statements: 80,
    // Per-file thresholds
    perFile: true
  }
}

Reading Coverage Reports

After running tests with coverage, open coverage/index.html:

Coverage Summary
================
Statements   : 87.5% ( 350/400 )
Branches     : 82.3% ( 142/172 )
Functions    : 91.2% ( 104/114 )
Lines        : 88.1% ( 339/385 )

Red files need attention. Green files are well-tested. Focus on the red.

ICOV File Support in Angular 21: The Game-Changer

This is one of the most underrated features in Angular 21. Let me explain why it matters.

What is ICOV?

ICOV (Improved Coverage) is a new coverage format introduced by Microsoft. Think of it as LCOV's smarter, more efficient cousin.

Traditional LCOV Format:

TN:
SF:/src/app/services/user.service.ts
FN:10,fetchUser
FN:25,updateUser
FNDA:5,fetchUser
FNDA:2,updateUser
DA:10,5
DA:11,5
DA:12,4

New ICOV Format:

{
  "version": "1.0.0",
  "files": {
    "/src/app/services/user.service.ts": {
      "functions": {
        "fetchUser": { "line": 10, "count": 5 },
        "updateUser": { "line": 25, "count": 2 }
      },
      "branches": {},
      "lines": {
        "10": 5,
        "11": 5,
        "12": 4
      }
    }
  }
}

Why Angular Introduced ICOV Support

1. Better Tooling Integration Azure DevOps, GitHub Actions, and modern CI/CD platforms prefer JSON-based formats for easier parsing.

2. Smaller File Sizes JSON compression works better than LCOV's text format—important for large monorepos.

3. Richer Metadata ICOV can include source maps, branch details, and function coverage in a structured way.

4. Future-Proof As tools like SonarQube and CodeCov adopt ICOV, Angular is ready.

How Angular 21 Generates ICOV

Simply add 'icov' to your coverage reporters:

// vitest.config.ts
export default defineConfig({
  test: {
    coverage: {
      reporter: ['text', 'html', 'lcov', 'icov'], // Add 'icov'
      reportsDirectory: './coverage'
    }
  }
});

After running ng test --coverage, you'll find:

• coverage/lcov.info (traditional)

• coverage/coverage.icov (new format)

Where ICOV is Used

Azure DevOps:

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'icov'
    summaryFileLocation: '$(Build.SourcesDirectory)/coverage/coverage.icov'

GitHub Actions:

- name: Upload Coverage
  uses: codecov/codecov-action@v3
  with:
    files: ./coverage/coverage.icov
    format: icov

SonarQube (Future Support):

sonar.javascript.icov.reportPaths=coverage/coverage.icov

Sample ICOV Output

{
  "version": "1.0.0",
  "timestamp": "2025-11-29T10:30:00.000Z",
  "files": {
    "/src/app/components/user-list.component.ts": {
      "lines": {
        "5": 10,
        "8": 10,
        "12": 8,
        "15": 0,
        "20": 6
      },
      "functions": {
        "ngOnInit": { "line": 5, "count": 10 },
        "loadUsers": { "line": 12, "count": 8 },
        "deleteUser": { "line": 15, "count": 0 }
      },
      "branches": {
        "12:0": { "count": 5 },
        "12:1": { "count": 3 }
      }
    }
  }
}

What this tells us:

• Line 15 (deleteUser function) was never executed—needs test coverage

• Branch at line 12 has both paths tested

• ngOnInit and loadUsers are well-covered

Terminal Output in Vitest: What You'll Actually See

Let's look at real terminal output so you know what to expect.

Single File Test Summary

$ ng test user.service.spec.ts

 ✓ src/app/services/user.service.spec.ts (4)
   ✓ UserService (4)
     ✓ should be created
     ✓ should fetch users from API
     ✓ should handle API errors gracefully
     ✓ should cache user data correctly

 Test Files  1 passed (1)
      Tests  4 passed (4)
   Start at  10:30:45
   Duration  127ms

Overall Test Summary

$ ng test

 ✓ src/app/components/user-list.component.spec.ts (6) 89ms
 ✓ src/app/services/user.service.spec.ts (4) 127ms
 ✓ src/app/pipes/format-date.pipe.spec.ts (3) 45ms
 ✓ src/app/guards/auth.guard.spec.ts (5) 156ms

 Test Files  4 passed (4)
      Tests  18 passed (18)
   Start at  10:30:45
   Duration  412ms (transform 89ms, setup 12ms, collect 134ms, tests 177ms)

Coverage Summary

$ ng test --coverage

 % Coverage report from v8
------------------------------------|---------|----------|---------|---------|
File                                | % Stmts | % Branch | % Funcs | % Lines |
------------------------------------|---------|----------|---------|---------|
All files                           |   87.50 |    82.35 |   91.17 |   88.12 |
 src/app/components                 |   92.30 |    88.88 |   95.00 |   93.10 |
  user-list.component.ts            |   95.45 |    91.66 |  100.00 |   96.29 |
  user-detail.component.ts          |   89.47 |    85.71 |   90.00 |   90.47 |
 src/app/services                   |   84.21 |    77.77 |   88.23 |   85.00 |
  user.service.ts                   |   91.66 |    87.50 |   93.75 |   92.30 |
  auth.service.ts                   |   76.92 |    66.66 |   83.33 |   78.26 |
 src/app/guards                     |   80.00 |    75.00 |   85.00 |   81.81 |
  auth.guard.ts                     |   80.00 |    75.00 |   85.00 |   81.81 |
------------------------------------|---------|----------|---------|---------|

Failed Tests Output

$ ng test

 ✓ src/app/services/user.service.spec.ts (3)
 ✗ src/app/components/user-list.component.spec.ts (1 failed)

 FAIL  src/app/components/user-list.component.spec.ts > UserListComponent > should display user names
AssertionError: expected 'John Smith' to be 'John Doe'
 ❯ src/app/components/user-list.component.spec.ts:45:52
    43|     fixture.detectChanges();
    44|     const nameElement = fixture.nativeElement.querySelector('.user-name');
    45|     expect(nameElement.textContent).toBe('John Doe');
      |                                     ^
    46|   });
    47| });

 Test Files  1 failed | 1 passed (2)
      Tests  1 failed | 3 passed (4)

Slow Tests Warning

 SLOW  src/app/services/heavy-computation.service.spec.ts > should calculate complex data
       Duration: 2.5s (threshold: 1s)

Vitest automatically highlights tests that take longer than expected—super helpful for identifying performance bottlenecks.

Handling Edge Cases in Vitest: Real Angular Examples

This is where Vitest really shines. Let's tackle the tricky stuff.

1. Testing Async Operations

Async/Await Pattern:

// notification.service.ts
import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { firstValueFrom } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class NotificationService {
  private http = inject(HttpClient);

  async sendNotification(message: string): Promise<{ success: boolean }> {
    const response = await firstValueFrom(
      this.http.post<{ success: boolean }>('/api/notifications', { message })
    );
    return response;
  }

  async getNotifications(): Promise<any[]> {
    return firstValueFrom(this.http.get<any[]>('/api/notifications'));
  }
}

// notification.service.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { NotificationService } from './notification.service';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';

describe('NotificationService - Async Tests', () => {
  let service: NotificationService;
  let httpMock: any;

  beforeEach(() => {
    httpMock = {
      post: vi.fn(),
      get: vi.fn()
    };

    TestBed.configureTestingModule({
      providers: [
        { provide: HttpClient, useValue: httpMock }
      ]
    });

    service = TestBed.inject(NotificationService);
  });

  it('should send notification successfully', async () => {
    httpMock.post.mockReturnValue(of({ success: true }));

    const result = await service.sendNotification('Hello World');

    expect(result.success).toBe(true);
    expect(httpMock.post).toHaveBeenCalledWith('/api/notifications', {
      message: 'Hello World'
    });
  });

  it('should handle network errors gracefully', async () => {
    httpMock.post.mockReturnValue(
      new Promise((_, reject) => reject(new Error('Network error')))
    );

    await expect(service.sendNotification('Test')).rejects.toThrow('Network error');
  });
});

2. Testing Timers with Fake Timers

setTimeout/setInterval:

// polling.service.ts
import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PollingService {
  private intervalId?: number;
  public callCount = 0;

  startPolling(callback: () => void, interval: number): void {
    this.intervalId = window.setInterval(() => {
      this.callCount++;
      callback();
    }, interval);
  }

  stopPolling(): void {
    if (this.intervalId) {
      clearInterval(this.intervalId);
      this.intervalId = undefined;
    }
  }
}

// polling.service.spec.ts
import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { PollingService } from './polling.service';

describe('PollingService - Timer Tests', () => {
  let service: PollingService;

  beforeEach(() => {
    vi.useFakeTimers();
    TestBed.configureTestingModule({});
    service = TestBed.inject(PollingService);
  });

  afterEach(() => {
    vi.useRealTimers();
  });

  it('should call callback every 1000ms', async () => {
    const callback = vi.fn();

    service.startPolling(callback, 1000);

    // Advance time by 3000ms
    await vi.advanceTimersByTimeAsync(3000);

    expect(callback).toHaveBeenCalledTimes(3);
    expect(service.callCount).toBe(3);

    service.stopPolling();
  });

  it('should stop polling when stopPolling is called', async () => {
    const callback = vi.fn();

    service.startPolling(callback, 1000);
    await vi.advanceTimersByTimeAsync(2000);

    service.stopPolling();

    await vi.advanceTimersByTimeAsync(2000);

    // Should still be 2, not 4
    expect(callback).toHaveBeenCalledTimes(2);
  });
});

3. Mocking Browser APIs

LocalStorage:

// theme.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class ThemeService {
  theme = signal<'light' | 'dark'>('light');

  constructor() {
    const savedTheme = localStorage.getItem('theme');
    if (savedTheme === 'dark' || savedTheme === 'light') {
      this.theme.set(savedTheme);
    }
  }

  toggleTheme(): void {
    const newTheme = this.theme() === 'light' ? 'dark' : 'light';
    this.theme.set(newTheme);
    localStorage.setItem('theme', newTheme);
  }
}

// theme.service.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';
import { TestBed } from '@angular/core/testing';
import { ThemeService } from './theme.service';

describe('ThemeService - LocalStorage Tests', () => {
  beforeEach(() => {
    localStorage.clear();
  });

  it('should initialize with light theme by default', () => {
    const service = TestBed.inject(ThemeService);
    expect(service.theme()).toBe('light');
  });

  it('should load saved theme from localStorage', () => {
    localStorage.setItem('theme', 'dark');

    const service = TestBed.inject(ThemeService);
    expect(service.theme()).toBe('dark');
  });

  it('should save theme to localStorage when toggled', () => {
    const service = TestBed.inject(ThemeService);

    service.toggleTheme();

    expect(localStorage.getItem('theme')).toBe('dark');
    expect(service.theme()).toBe('dark');
  });
});

Window.location:

// navigation.service.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';

describe('Window Location Mocking', () => {
  beforeEach(() => {
    // Mock window.location
    delete (window as any).location;
    window.location = {
      href: '<http://localhost:4200/>',
      pathname: '/',
      search: '',
      hash: ''
    } as any;
  });

  it('should navigate to external URL', () => {
    const navigateSpy = vi.spyOn(window.location, 'href', 'set');

    window.location.href = '<https://example.com>';

    expect(navigateSpy).toHaveBeenCalledWith('<https://example.com>');
  });
});

IntersectionObserver:

// lazy-load.directive.spec.ts
import { describe, it, expect, beforeEach, vi } from 'vitest';

describe('IntersectionObserver Mocking', () => {
  let observeMock: any;
  let unobserveMock: any;

  beforeEach(() => {
    observeMock = vi.fn();
    unobserveMock = vi.fn();

    global.IntersectionObserver = vi.fn().mockImplementation((callback) => ({
      observe: observeMock,
      unobserve: unobserveMock,
      disconnect: vi.fn(),
    }));
  });

  it('should observe element for lazy loading', () => {
    const element = document.createElement('img');
    const observer = new IntersectionObserver(() => {});

    observer.observe(element);

    expect(observeMock).toHaveBeenCalledWith(element);
  });
});

4. Testing DOM Interactions with Happy-DOM

// dropdown.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-dropdown',
  template: `
    <div class="dropdown">
      <button (click)="toggle()" class="dropdown-toggle">
        {{ isOpen() ? 'Close' : 'Open' }} Menu
      </button>
      @if (isOpen()) {
        <ul class="dropdown-menu">
          <li><a href="/profile">Profile</a></li>
          <li><a href="/settings">Settings</a></li>
          <li><a href="/logout">Logout</a></li>
        </ul>
      }
    </div>
  `,
  styles: [`
    .dropdown { position: relative; }
    .dropdown-menu { position: absolute; top: 100%; }
  `]
})
export class DropdownComponent {
  isOpen = signal(false);

  toggle(): void {
    this.isOpen.update(value => !value);
  }
}

// dropdown.component.spec.ts
import { describe, it, expect, beforeEach } from 'vitest';
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { DropdownComponent } from './dropdown.component';

describe('DropdownComponent - DOM Interactions', () => {
  let component: DropdownComponent;
  let fixture: ComponentFixture<DropdownComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingComponent({
      imports: [DropdownComponent]
    }).compileComponents();

    fixture = TestBed.createComponent(DropdownComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should toggle dropdown menu on button click', () => {
    const button = fixture.nativeElement.querySelector('.dropdown-toggle');

    // Initially closed
    expect(component.isOpen()).toBe(false);
    expect(fixture.nativeElement.querySelector('.dropdown-menu')).toBeNull();

    // Click to open
    button.click();
    fixture.detectChanges();

    expect(component.isOpen()).toBe(true);
    expect(fixture.nativeElement.querySelector('.dropdown-menu')).not.toBeNull();

    // Click to close
    button.click();
    fixture.detectChanges();

    expect(component.isOpen()).toBe(false);
    expect(fixture.nativeElement.querySelector('.dropdown-menu')).toBeNull();
  });

  it('should display correct button text based on state', () => {
    const button = fixture.nativeElement.querySelector('.dropdown-toggle');

    expect(button.textContent.trim()).toBe('Open Menu');

    button.click();
    fixture.detectChanges();

    expect(button.textContent.trim()).toBe('Close Menu');
  });

  it('should render menu items when open', () => {
    component.isOpen.set(true);
    fixture.detectChanges();

    const menuItems = fixture.nativeElement.querySelectorAll('.dropdown-menu li');
    expect(menuItems.length).toBe(3);
    expect(menuItems[0].textContent).toBe('Profile');
    expect(menuItems[1].textContent).toBe('Settings');
    expect(menuItems[2].textContent).toBe('Logout');
  });
});

Have you run into issues testing browser APIs in the past? This approach makes it way simpler.

Component Testing in Angular 21 + Vitest: Complete Example

Let's build a realistic component test using Angular Testing Library integration.

The Component

// todo-list.component.ts
import { Component, signal, computed } from '@angular/core';
import { FormsModule } from '@angular/forms';

interface Todo {
  id: number;
  text: string;
  completed: boolean;
}

@Component({
  selector: 'app-todo-list',
  imports: [FormsModule],
  template: `
    <div class="todo-container">
      <h2>My Todo List</h2>

      <div class="todo-input">
        <input
          type="text"
          [(ngModel)]="newTodoText"
          (keyup.enter)="addTodo()"
          placeholder="Add a new todo..."
          data-testid="todo-input"
        />
        <button
          (click)="addTodo()"
          [disabled]="!newTodoText().trim()"
          data-testid="add-button"
        >
          Add
        </button>
      </div>

      <div class="todo-stats">
        <span data-testid="total-count">Total: {{ totalCount() }}</span>
        <span data-testid="completed-count">Completed: {{ completedCount() }}</span>
        <span data-testid="pending-count">Pending: {{ pendingCount() }}</span>
      </div>

      <ul class="todo-list">
        @for (todo of todos(); track todo.id) {
          <li [class.completed]="todo.completed" [attr.data-testid]="'todo-' + todo.id">
            <input
              type="checkbox"
              [checked]="todo.completed"
              (change)="toggleTodo(todo.id)"
              [attr.data-testid]="'checkbox-' + todo.id"
            />
            <span class="todo-text">{{ todo.text }}</span>
            <button
              (click)="deleteTodo(todo.id)"
              [attr.data-testid]="'delete-' + todo.id"
              class="delete-btn"
            >
              Delete
            </button>
          </li>
        }
      </ul>

      @if (todos().length === 0) {
        <p class="empty-state" data-testid="empty-state">
          No todos yet. Add one above!
        </p>
      }
    </div>
  `,
  styles: [`
    .todo-container { max-width: 600px; margin: 0 auto; padding: 20px; }
    .todo-input { display: flex; gap: 10px; margin-bottom: 20px; }
    .todo-input input { flex: 1; padding: 8px; }
    .todo-stats { display: flex; gap: 15px; margin-bottom: 20px; color: #666; }
    .todo-list { list-style: none; padding: 0; }
    .todo-list li { display: flex; align-items: center; gap: 10px; padding: 10px; border-bottom: 1px solid #eee; }
    .todo-list li.completed .todo-text { text-decoration: line-through; color: #999; }
    .delete-btn { margin-left: auto; color: red; }
    .empty-state { text-align: center; color: #999; padding: 40px; }
  `]
})
export class TodoListComponent {
  todos = signal<Todo[]>([]);
  newTodoText = signal('');
  private nextId = 1;

  totalCount = computed(() => this.todos().length);
  completedCount = computed(() => this.todos().filter(t => t.completed).length);
  pendingCount = computed(() => this.todos().filter(t => !t.completed).length);

  addTodo(): void {
    const text = this.newTodoText().trim();
    if (!text) return;

    this.todos.update(todos => [
      ...todos,
      { id: this.nextId++, text, completed: false }
    ]);
    this.newTodoText.set('');
  }

  toggleTodo(id: number): void {
    this.todos.update(todos =>
      todos.map(todo =>
        todo.id === id ? { ...todo, completed: !todo.completed } : todo
      )
    );
  }

  deleteTodo(id: number): void {
    this.todos.update(todos => todos.filter(todo => todo.id !== id));
  }
}

Comprehensive Test Suite

// todo-list.component.spec.ts
import { describe, it, expect, beforeEach } from 'vitest';
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { TodoListComponent } from './todo-list.component';

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

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

    fixture = TestBed.createComponent(TodoListComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

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

    it('should display empty state when no todos', () => {
      const emptyState = fixture.nativeElement.querySelector('[data-testid="empty-state"]');
      expect(emptyState).toBeTruthy();
      expect(emptyState.textContent).toContain('No todos yet');
    });

    it('should display correct initial stats', () => {
      const total = fixture.nativeElement.querySelector('[data-testid="total-count"]');
      const completed = fixture.nativeElement.querySelector('[data-testid="completed-count"]');
      const pending = fixture.nativeElement.querySelector('[data-testid="pending-count"]');

      expect(total.textContent).toBe('Total: 0');
      expect(completed.textContent).toBe('Completed: 0');
      expect(pending.textContent).toBe('Pending: 0');
    });
  });

  describe('Adding Todos', () => {
    it('should add a new todo when clicking add button', () => {
      const input = fixture.nativeElement.querySelector('[data-testid="todo-input"]');
      const button = fixture.nativeElement.querySelector('[data-testid="add-button"]');

      input.value = 'Buy groceries';
      input.dispatchEvent(new Event('input'));
      fixture.detectChanges();

      button.click();
      fixture.detectChanges();

      const todoItems = fixture.nativeElement.querySelectorAll('.todo-list li');
      expect(todoItems.length).toBe(1);
      expect(todoItems[0].textContent).toContain('Buy groceries');
    });

    it('should add todo when pressing Enter key', () => {
      const input = fixture.nativeElement.querySelector('[data-testid="todo-input"]');

      input.value = 'Write tests';
      input.dispatchEvent(new Event('input'));
      fixture.detectChanges();

      const enterEvent = new KeyboardEvent('keyup', { key: 'Enter' });
      input.dispatchEvent(enterEvent);
      fixture.detectChanges();

      expect(component.todos().length).toBe(1);
      expect(component.todos()[0].text).toBe('Write tests');
    });

    it('should not add empty todos', () => {
      const button = fixture.nativeElement.querySelector('[data-testid="add-button"]');

      component.newTodoText.set('   ');
      fixture.detectChanges();

      button.click();
      fixture.detectChanges();

      expect(component.todos().length).toBe(0);
    });

    it('should clear input after adding todo', () => {
      const input = fixture.nativeElement.querySelector('[data-testid="todo-input"]');
      const button = fixture.nativeElement.querySelector('[data-testid="add-button"]');

      input.value = 'Test todo';
      input.dispatchEvent(new Event('input'));
      component.newTodoText.set('Test todo');
      fixture.detectChanges();

      button.click();
      fixture.detectChanges();

      expect(component.newTodoText()).toBe('');
    });

    it('should update stats after adding todos', () => {
      component.newTodoText.set('First todo');
      component.addTodo();
      component.newTodoText.set('Second todo');
      component.addTodo();
      fixture.detectChanges();

      const total = fixture.nativeElement.querySelector('[data-testid="total-count"]');
      const pending = fixture.nativeElement.querySelector('[data-testid="pending-count"]');

      expect(total.textContent).toBe('Total: 2');
      expect(pending.textContent).toBe('Pending: 2');
    });
  });

  describe('Toggling Todos', () => {
    beforeEach(() => {
      component.newTodoText.set('Test todo');
      component.addTodo();
      fixture.detectChanges();
    });

    it('should toggle todo completion on checkbox click', () => {
      const checkbox = fixture.nativeElement.querySelector('[data-testid="checkbox-1"]');

      expect(component.todos()[0].completed).toBe(false);

      checkbox.click();
      fixture.detectChanges();

      expect(component.todos()[0].completed).toBe(true);
    });

    it('should apply completed class when todo is completed', () => {
      const checkbox = fixture.nativeElement.querySelector('[data-testid="checkbox-1"]');

      checkbox.click();
      fixture.detectChanges();

      const todoItem = fixture.nativeElement.querySelector('[data-testid="todo-1"]');
      expect(todoItem.classList.contains('completed')).toBe(true);
    });

    it('should update completed count when toggling', () => {
      const checkbox = fixture.nativeElement.querySelector('[data-testid="checkbox-1"]');

      checkbox.click();
      fixture.detectChanges();

      const completedCount = fixture.nativeElement.querySelector('[data-testid="completed-count"]');
      const pendingCount = fixture.nativeElement.querySelector('[data-testid="pending-count"]');

      expect(completedCount.textContent).toBe('Completed: 1');
      expect(pendingCount.textContent).toBe('Pending: 0');
    });
  });

  describe('Deleting Todos', () => {
    beforeEach(() => {
      component.newTodoText.set('Todo 1');
      component.addTodo();
      component.newTodoText.set('Todo 2');
      component.addTodo();
      fixture.detectChanges();
    });

    it('should delete todo when clicking delete button', () => {
      const deleteButton = fixture.nativeElement.querySelector('[data-testid="delete-1"]');

      expect(component.todos().length).toBe(2);

      deleteButton.click();
      fixture.detectChanges();

      expect(component.todos().length).toBe(1);
      expect(component.todos()[0].text).toBe('Todo 2');
    });

    it('should show empty state after deleting all todos', () => {
      const delete1 = fixture.nativeElement.querySelector('[data-testid="delete-1"]');
      const delete2 = fixture.nativeElement.querySelector('[data-testid="delete-2"]');

      delete1.click();
      fixture.detectChanges();

      delete2.click();
      fixture.detectChanges();

      const emptyState = fixture.nativeElement.querySelector('[data-testid="empty-state"]');
      expect(emptyState).toBeTruthy();
    });

    it('should update stats after deletion', () => {
      const deleteButton = fixture.nativeElement.querySelector('[data-testid="delete-1"]');

      deleteButton.click();
      fixture.detectChanges();

      const total = fixture.nativeElement.querySelector('[data-testid="total-count"]');
      expect(total.textContent).toBe('Total: 1');
    });
  });

  describe('Computed Properties', () => {
    it('should correctly calculate total count', () => {
      component.todos.set([
        { id: 1, text: 'Todo 1', completed: false },
        { id: 2, text: 'Todo 2', completed: true },
        { id: 3, text: 'Todo 3', completed: false }
      ]);

      expect(component.totalCount()).toBe(3);
    });

    it('should correctly calculate completed count', () => {
      component.todos.set([
        { id: 1, text: 'Todo 1', completed: false },
        { id: 2, text: 'Todo 2', completed: true },
        { id: 3, text: 'Todo 3', completed: true }
      ]);

      expect(component.completedCount()).toBe(2);
    });

    it('should correctly calculate pending count', () => {
      component.todos.set([
        { id: 1, text: 'Todo 1', completed: false },
        { id: 2, text: 'Todo 2', completed: true },
        { id: 3, text: 'Todo 3', completed: false }
      ]);

      expect(component.pendingCount()).toBe(2);
    });
  });
});

This test suite covers:

• Initial rendering and empty states

• Adding todos via button and Enter key

• Input validation and clearing

• Toggling completion status

• Deleting todos

• Stats calculations

• Edge cases like empty strings and multiple operations

Integration with CI/CD: Making It Production-Ready

Let's make sure your tests run smoothly in your pipeline.

GitHub Actions Example

# .github/workflows/test.yml
name: Run Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests with coverage
        run: npm run test:ci

      - name: Check coverage thresholds
        run: npm run test:coverage:check

      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v3
        with:
          files: ./coverage/coverage.icov,./coverage/lcov.info
          format: icov
          fail_ci_if_error: true

      - name: Upload coverage artifacts
        uses: actions/upload-artifact@v3
        with:
          name: coverage-report
          path: coverage/

Package.json Scripts

{
  "scripts": {
    "test": "ng test",
    "test:ci": "ng test --run --coverage",
    "test:coverage": "ng test --coverage",
    "test:coverage:check": "vitest --run --coverage --coverage.thresholds.lines=80"
  }
}

Azure DevOps Pipeline

# azure-pipelines.yml
trigger:
  - main
  - develop

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'
    displayName: 'Install Node.js'

  - script: npm ci
    displayName: 'Install dependencies'

  - script: npm run test:ci
    displayName: 'Run Vitest tests'

  - task: PublishCodeCoverageResults@1
    inputs:
      codeCoverageTool: 'icov'
      summaryFileLocation: '$(Build.SourcesDirectory)/coverage/coverage.icov'
      pathToSources: '$(Build.SourcesDirectory)/src'
    displayName: 'Publish coverage results'

  - task: PublishTestResults@2
    inputs:
      testResultsFormat: 'JUnit'
      testResultsFiles: '**/junit.xml'
      failTaskOnFailedTests: true
    displayName: 'Publish test results'

Fail on Coverage Threshold

Update your vitest.config.ts:

export default defineConfig({
  test: {
    coverage: {
      thresholds: {
        lines: 80,
        functions: 75,
        branches: 70,
        statements: 80
      },
      // Fail CI if thresholds aren't met
      thresholdAutoUpdate: false
    }
  }
});

When coverage drops below threshold:

ERROR: Coverage for lines (78.5%) does not meet global threshold (80%)

Your CI/CD pipeline will fail, preventing low-quality code from merging.

Best Practices and Recommendations

Let me share some hard-won wisdom from real-world Angular testing.

1. Folder Structure

src/
├── app/
│   ├── components/
│   │   ├── user-list/
│   │   │   ├── user-list.component.ts
│   │   │   ├── user-list.component.spec.ts
│   │   │   └── user-list.component.css
│   ├── services/
│   │   ├── user.service.ts
│   │   ├── user.service.spec.ts
│   ├── guards/
│   │   ├── auth.guard.ts
│   │   ├── auth.guard.spec.ts
│   ├── pipes/
│   │   ├── format-date.pipe.ts
│   │   ├── format-date.pipe.spec.ts
├── test/
│   ├── helpers/
│   │   ├── mock-data.ts
│   │   ├── test-utils.ts
│   │   └── custom-matchers.ts
│   └── fixtures/
│       ├── user-fixtures.ts
│       └── api-responses.ts
├── test-setup.ts
└── vitest.config.ts

Why this works:

• Tests live next to the code they test

• Shared test utilities in dedicated folder

• Easy to find and maintain

2. Naming Conventions

// Good: Descriptive, action-oriented
it('should display error message when API call fails', () => {});
it('should disable submit button when form is invalid', () => {});

// Bad: Vague, implementation-focused
it('should work', () => {});
it('should test the method', () => {});

Pattern to follow:

• Start with "should"

• Describe the behavior, not the implementation

• Include the condition and expected outcome

3. Organize Test Utilities

// test/helpers/test-utils.ts
import { ComponentFixture } from '@angular/core/testing';

export function findByTestId<T>(
  fixture: ComponentFixture<T>,
  testId: string
): HTMLElement {
  return fixture.nativeElement.querySelector(`[data-testid="${testId}"]`);
}

export function clickButton<T>(
  fixture: ComponentFixture<T>,
  testId: string
): void {
  const button = findByTestId(fixture, testId);
  button.click();
  fixture.detectChanges();
}

export async function fillInput<T>(
  fixture: ComponentFixture<T>,
  testId: string,
  value: string
): Promise<void> {
  const input = findByTestId(fixture, testId) as HTMLInputElement;
  input.value = value;
  input.dispatchEvent(new Event('input'));
  fixture.detectChanges();
  await fixture.whenStable();
}

// Usage in tests
import { findByTestId, clickButton, fillInput } from '../../../test/helpers/test-utils';

it('should add todo', async () => {
  await fillInput(fixture, 'todo-input', 'New todo');
  clickButton(fixture, 'add-button');

  const todoItem = findByTestId(fixture, 'todo-1');
  expect(todoItem).toBeTruthy();
});

4. Mocking Guidelines

Do mock:

• External HTTP calls

• Browser APIs (localStorage, navigator, etc.)

• Third-party services

• Time-dependent code (setTimeout, Date.now())

Don't mock:

• Angular core functionality (TestBed, ComponentFixture)

• Simple utility functions

• Your own business logic (test it instead)

// Good: Mock external dependency
const httpMock = {
  get: vi.fn().mockReturnValue(of(mockData))
};

// Bad: Mocking your own logic defeats the purpose
const userServiceMock = {
  calculateAge: vi.fn().mockReturnValue(25) // Just test the real calculateAge!
};

5. Avoid Snapshot Overuse

Snapshots are useful but can become a maintenance nightmare.

Use snapshots for:

• Complex, static HTML structures

• Generated content that rarely changes

• Third-party component output

Don't use snapshots for:

• Dynamic content

• Forms with user interaction

• Anything that changes frequently

// Good: Targeted assertion
it('should display user name', () => {
  expect(fixture.nativeElement.querySelector('.user-name').textContent).toBe('John');
});

// Questionable: Entire component snapshot
it('should render correctly', () => {
  expect(fixture.nativeElement.innerHTML).toMatchSnapshot();
});

6. Test Behavior, Not Implementation

// Bad: Testing implementation details
it('should call ngOnInit', () => {
  const spy = vi.spyOn(component, 'ngOnInit');
  component.ngOnInit();
  expect(spy).toHaveBeenCalled();
});

// Good: Testing behavior
it('should load users on component initialization', () => {
  // ngOnInit is called automatically by TestBed
  expect(component.users().length).toBeGreaterThan(0);
});

7. Keep Tests Independent

// Bad: Tests depend on each other
describe('UserService', () => {
  let users: User[];

  it('should add user', () => {
    users = service.addUser({ name: 'John' });
    expect(users.length).toBe(1);
  });

  it('should find user', () => {
    // Depends on previous test!
    const user = service.findUser('John');
    expect(user).toBeTruthy();
  });
});

// Good: Each test is independent
describe('UserService', () => {
  beforeEach(() => {
    service.reset();
  });

  it('should add user', () => {
    const users = service.addUser({ name: 'John' });
    expect(users.length).toBe(1);
  });

  it('should find user', () => {
    service.addUser({ name: 'John' });
    const user = service.findUser('John');
    expect(user).toBeTruthy();
  });
});

8. Use Descriptive Test Data

// Bad: Magic numbers and strings
it('should calculate discount', () => {
  expect(service.calculate(100, 0.1)).toBe(90);
});

// Good: Named constants with context
it('should apply 10% discount correctly', () => {
  const originalPrice = 100;
  const discountRate = 0.1;
  const expectedPrice = 90;

  expect(service.calculate(originalPrice, discountRate)).toBe(expectedPrice);
});

Bonus Tips: Level Up Your Vitest Game

Here are some insider tricks that most developers miss.

Tip 1: Use Custom Matchers

// test/helpers/custom-matchers.ts
import { expect } from 'vitest';

expect.extend({
  toBeWithinRange(received: number, floor: number, ceiling: number) {
    const pass = received >= floor && received <= ceiling;
    return {
      pass,
      message: () =>
        pass
          ? `expected ${received} not to be within range ${floor} - ${ceiling}`
          : `expected ${received} to be within range ${floor} - ${ceiling}`
    };
  }
});

// Usage
expect(response.time).toBeWithinRange(100, 200);

Tip 2: Parallel Test Execution

// vitest.config.ts
export default defineConfig({
  test: {
    pool: 'threads',
    poolOptions: {
      threads: {
        singleThread: false,
        isolate: true
      }
    },
    maxConcurrency: 5 // Run up to 5 test files in parallel
  }
});

Tip 3: Test-Specific Timeouts

// For slow integration tests
it('should handle large dataset', async () => {
  await service.processLargeFile();
  expect(service.processed).toBe(true);
}, 10000); // 10 second timeout for this test only

Tip 4: Debug Failing Tests

// vitest.config.ts
export default defineConfig({
  test: {
    // Stop on first failure
    bail: 1,

    // Retry flaky tests
    retry: 2
  }
});

Run specific test file:

ng test src/app/services/user.service.spec.ts

Run tests matching pattern:

ng test --reporter=verbose --grep="should handle errors"

Tip 5: Environment Variables for Tests

// test-setup.ts
import { beforeAll } from 'vitest';

beforeAll(() => {
  process.env.API_URL = '<http://localhost:4200/api>';
  process.env.NODE_ENV = 'test';
});

// Usage in tests
it('should use test API URL', () => {
  expect(service.apiUrl).toBe('<http://localhost:4200/api>');
});

Recap: Why Vitest is Angular's Future

Let's bring it all together.

What we've covered:

1. The Why: Angular dropped Karma because Vitest is faster, more modern, and built for today's JavaScript ecosystem.

2. Key Features: Instant hot reload, native TypeScript, powerful mocking with vi, and browser-like environments without the browser overhead.

3. Migration: Step-by-step guide from Jasmine to Vitest, including syntax changes and real code examples.

4. Coverage: How to enable ICOV format, set thresholds, and integrate with modern CI/CD pipelines.

5. Real-World Testing: Async operations, timers, browser APIs, DOM interactions—all the tricky stuff you actually need.

6. Best Practices: Folder structure, naming conventions, when to mock, and how to keep tests maintainable.

The Bottom Line:

Vitest isn't just a testing framework—it's a developer experience upgrade. Your tests run 10x faster. Your feedback loop is instant. Your CI/CD pipeline finishes before you context-switch.

If you're starting a new Angular 21 project, Vitest is a no-brainer. If you have an existing app, the migration effort pays for itself in saved time within weeks.

The Angular team made the right call. Now it's your turn.

What Did You Think?

I'd genuinely love to hear your experience with Vitest. Have you migrated from Karma yet? What challenges did you face? Drop a comment below—especially if you've run into edge cases not covered here.

Found this helpful? Give it a clap (or five) so other Angular developers can discover this guide.

Want more Angular insights? Follow me for weekly deep-dives into Angular best practices, performance optimization, and modern development techniques. I also share exclusive tips in my newsletter—join the community of developers who want to level up their Angular game.

Action Points:

1. Try Vitest in a small project first—get comfortable before migrating your main app

2. Set up CI/CD integration early—automated testing saves teams

3. Share this with your team—discuss migration timeline and strategy

4. Bookmark this guide—you'll reference it during migration

What topic should I cover next? Vote in the comments:

• A) Advanced Vitest patterns and custom utilities

• B) Angular Signals testing strategies

• C) E2E testing with Playwright in Angular 21

Let's keep the conversation going. See you in the comments.

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

If you're like most developers (myself included for way too long), the answer is probably "every single time." But here's the thing — that innocent little line might be quietly bloating your app and creating memory leaks you didn't even know existed.

By the end of this article, you'll know:

• Why root-level services aren't always the best choice

• When and how to scope services properly

• Practical examples with real code you can use today

• How to write unit tests for scoped services

• Pro tips that'll make your Angular apps leaner and faster

💬 Before we dive in, tell me: Have you ever wondered why your Angular app feels sluggish even with lazy loading? Drop a comment — I bet service scoping is part of the puzzle!

The Root Problem (Pun Intended) 🤔

Let's start with a scenario that probably sounds familiar. You're building an e-commerce app, and you create a ProductService:

@Injectable({
  providedIn: 'root'  // 👈 The automatic choice
})
export class ProductService {
  private products: Product[] = [];

  constructor(private http: HttpClient) {
    // Load all products immediately
    this.loadProducts();
  }

  private loadProducts() {
    this.http.get<Product[]>('/api/products').subscribe(
      products => this.products = products
    );
  }

  getProducts(): Product[] {
    return this.products;
  }
}

Looks innocent, right? But here's what's happening under the hood:

1. Your service loads ALL products the moment your app starts

2. It stays in memory even when users are on completely unrelated pages

3. It's creating unnecessary HTTP requests before users even need the data

Question for you: How many of your services are doing exactly this? 🤯

The Smarter Approach: Strategic Service Scoping 🎯

Instead of making everything root-level, let's be intentional about where our services live. Here are the three main scoping strategies:

1. Component-Level Scoping

Perfect for services that should have a fresh instance per component:

@Injectable()
export class ShoppingCartService {
  private items: CartItem[] = [];

  addItem(item: CartItem) {
    this.items.push(item);
  }

  getItems(): CartItem[] {
    return [...this.items];
  }

  clearCart() {
    this.items = [];
  }
}

// In your component
@Component({
  selector: 'app-product-list',
  templateUrl: './product-list.component.html',
  providers: [ShoppingCartService]  // 👈 Scoped to this component
})
export class ProductListComponent {
  constructor(private cartService: ShoppingCartService) {}
}

2. Module-Level Scoping

Great for services that should be shared within a feature module:

@Injectable()
export class UserProfileService {
  private userProfile: UserProfile | null = null;

  constructor(private http: HttpClient) {}

  loadUserProfile(userId: string): Observable<UserProfile> {
    if (!this.userProfile) {
      return this.http.get<UserProfile>(`/api/users/${userId}`).pipe(
        tap(profile => this.userProfile = profile)
      );
    }
    return of(this.userProfile);
  }
}

// In your feature module
@NgModule({
  providers: [UserProfileService],  // 👈 Scoped to this module
  // ... other module config
})
export class UserModule {}

3. Smart Root-Level Services

Only use root-level for truly global services:

@Injectable({
  providedIn: 'root'
})
export class AuthenticationService {
  private currentUser$ = new BehaviorSubject<User | null>(null);

  constructor(private http: HttpClient) {
    // Only load auth state - truly global concern
    this.loadStoredAuthState();
  }

  // Methods that are needed app-wide
  getCurrentUser(): Observable<User | null> {
    return this.currentUser$.asObservable();
  }
}

💡 Pro tip: Ask yourself: "Does every single page of my app need this service?" If not, don't make it root-level!

Real-World Example: E-Commerce Product Categories 🛍️

Let's build a practical example. Imagine you have different product categories, and each category has its own complex filtering logic:

// ❌ Bad: Root-level service loading everything
@Injectable({
  providedIn: 'root'
})
export class BadProductService {
  private electronicsProducts: Product[] = [];
  private clothingProducts: Product[] = [];
  private booksProducts: Product[] = [];

  constructor(private http: HttpClient) {
    // Loading everything immediately - wasteful!
    this.loadAllCategories();
  }

  private loadAllCategories() {
    // This runs even if user only visits electronics
    this.http.get<Product[]>('/api/electronics').subscribe(/*...*/);
    this.http.get<Product[]>('/api/clothing').subscribe(/*...*/);
    this.http.get<Product[]>('/api/books').subscribe(/*...*/);
  }
}

// ✅ Good: Category-specific services
@Injectable()
export class ElectronicsService {
  private products: Product[] = [];
  private filters: ElectronicsFilter = {};

  constructor(private http: HttpClient) {}

  loadProducts(): Observable<Product[]> {
    if (this.products.length === 0) {
      return this.http.get<Product[]>('/api/electronics').pipe(
        tap(products => this.products = products)
      );
    }
    return of(this.products);
  }

  applyFilters(filters: ElectronicsFilter): Product[] {
    // Category-specific filtering logic
    return this.products.filter(product => {
      return this.matchesElectronicsFilters(product, filters);
    });
  }

  private matchesElectronicsFilters(product: Product, filters: ElectronicsFilter): boolean {
    // Complex electronics-specific filtering
    return true; // Simplified for demo
  }
}

// Provide it only in the Electronics module
@NgModule({
  providers: [ElectronicsService],
  // ... other config
})
export class ElectronicsModule {}

Think about it: Why should your app load clothing filters when the user is browsing electronics? 🤷‍♂️

Unit Testing Scoped Services 🧪

Here's how to properly test your scoped services:

describe('ElectronicsService', () => {
  let service: ElectronicsService;
  let httpMock: jasmine.SpyObj<HttpClient>;

  beforeEach(() => {
    const httpSpy = jasmine.createSpyObj('HttpClient', ['get']);

    TestBed.configureTestingModule({
      providers: [
        ElectronicsService,
        { provide: HttpClient, useValue: httpSpy }
      ]
    });

    service = TestBed.inject(ElectronicsService);
    httpMock = TestBed.inject(HttpClient) as jasmine.SpyObj<HttpClient>;
  });

  it('should load products only once', fakeAsync(() => {
    const mockProducts = [
      { id: 1, name: 'iPhone', category: 'electronics' },
      { id: 2, name: 'MacBook', category: 'electronics' }
    ];

    httpMock.get.and.returnValue(of(mockProducts));

    // First call
    service.loadProducts().subscribe();
    tick();

    // Second call
    service.loadProducts().subscribe();
    tick();

    // HTTP should be called only once
    expect(httpMock.get).toHaveBeenCalledTimes(1);
  }));

  it('should apply filters correctly', () => {
    // Test your filtering logic
    const filters: ElectronicsFilter = { brand: 'Apple', maxPrice: 1000 };
    const results = service.applyFilters(filters);

    expect(results).toBeDefined();
    // Add more specific assertions based on your filter logic
  });
});

Quick question: How do you usually test your services? Are you testing the scoping behavior too? 💭

Pro Tips That'll Make You Stand Out 🔥

1. Lazy Service Loading Pattern

@Injectable()
export class LazyDataService {
  private data$ = new BehaviorSubject<any[]>([]);

  constructor(private http: HttpClient) {}

  getData(): Observable<any[]> {
    if (this.data$.getValue().length === 0) {
      this.http.get<any[]>('/api/data').subscribe(
        data => this.data$.next(data)
      );
    }
    return this.data$.asObservable();
  }
}

2. Service Cleanup Pattern

@Injectable()
export class CleanupService implements OnDestroy {
  private destroy$ = new Subject<void>();

  constructor(private http: HttpClient) {}

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }

  getData(): Observable<any> {
    return this.http.get('/api/data').pipe(
      takeUntil(this.destroy$)
    );
  }
}

3. Service Factory Pattern

export function createCategoryService(category: string) {
  return new CategoryService(category);
}

@NgModule({
  providers: [
    {
      provide: CategoryService,
      useFactory: createCategoryService,
      deps: ['categoryName']
    }
  ]
})
export class DynamicCategoryModule {}

👏 If these patterns are new to you, give this article a clap so others can discover these techniques too!

Bonus Tips for Angular Performance 💨

1. Use OnPush Change Detection with scoped services for better performance

2. Implement proper service disposal in your modules

3. Consider using Angular's tree-shakable providers for truly optional services

4. Monitor your bundle size — scoped services help keep chunks smaller

Your turn: What's one performance tip you wish you'd known earlier? Share it in the comments! 👇

Recap: Your Service Scoping Cheat Sheet 📋

✅ Use Root-Level Services For:

• Authentication and authorization

• Global configuration

• App-wide state management

• Core utilities (logging, error handling)

✅ Use Module-Level Services For:

• Feature-specific business logic

• Data services for specific domains

• Services shared within a feature module

✅ Use Component-Level Services For:

• Temporary state management

• Component-specific calculations

• Services that need fresh instances

❌ Avoid Root-Level Services For:

• Heavy data loading services

• Feature-specific utilities

• Services that aren't needed app-wide

What's Next? 🚀

Now that you know how to scope your services properly, your Angular apps will be:

• Faster at startup (no unnecessary service initialization)

• Smaller in memory footprint

• More maintainable with clear service boundaries

• Better performing with lazy loading

Action points for you:

1. Audit your current services — how many are unnecessarily root-level?

2. Refactor one service this week using the patterns above

3. Add proper unit tests for your scoped services

4. Monitor your app's performance before and after

Let's Connect! 🤝

💬 What did you think? Have you been over-using root-level services too? Or do you have a different approach to service scoping? I'd love to hear your experience in the comments!

👏 Found this helpful? If this article saved you from a performance headache, smash that clap button (or give it 5 claps!) so other developers can find it too.

📬 Want more Angular tips like this? I share practical Angular insights every week. Follow me here on Medium or connect with me on LinkedIn [@sadhana_dev] for more developer tips that actually work.

🔥 What should I write about next? Vote in the comments:

• A) Advanced Angular Testing Patterns

• B) Angular Performance Optimization Deep Dive

• C) Building Scalable Angular Architecture

Let's build better Angular apps together! 🚀

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Have you ever felt like Angular was carrying too much legacy weight? Like you were constantly fighting with zone.js, or wished your forms could be more reactive and type-safe without all that boilerplate?

Angular v21 just changed the game.

After working with Angular for over a decade and building multiple component libraries, I can confidently say this is the most strategic release since standalone components. The Angular team has delivered features that fundamentally reshape how we think about change detection, forms, testing, and accessibility.

In this article, you'll learn:

• How to leverage Signal-based Forms for fully type-safe, reactive form handling

• Why zoneless change detection matters and how to migrate

• Building accessible UIs with Angular Aria's headless components

• Setting up Vitest as your default test runner

• Practical migration strategies for existing applications

Let's dive into what makes Angular v21 a milestone release and, more importantly, how you can start using these features today.

The Big Picture: Why Angular v21 Matters

Angular v21 isn't just another incremental update. It represents a fundamental shift in Angular's philosophy:

From zone.js-driven change detection to signals-first reactive primitivesFrom verbose forms API to declarative, type-safe signal formsFrom Karma/Jasmine to Vitest for faster, modern testingFrom building accessibility from scratch to headless, reusable patterns

For library authors and enterprise teams, this means rethinking architectural decisions around state management, change detection, and component design patterns.

Feature #1: Signal-Based Forms (Experimental)

What's Different?

The new signal-based forms API lets you define your entire form model using signals, with full type safety and schema-based validation—no ControlValueAccessor boilerplate needed.

Traditional Forms vs Signal Forms

Old Approach (Reactive Forms):

import { Component } from '@angular/core';
import { FormBuilder, FormGroup, Validators, ReactiveFormsModule } from '@angular/forms';

@Component({
  selector: 'app-user-form',
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="userForm" (ngSubmit)="onSubmit()">
      <input formControlName="email" type="email" />
      <input formControlName="password" type="password" />
      <button type="submit">Submit</button>
    </form>
  `
})
export class UserFormComponent {
  userForm: FormGroup;

  constructor(private fb: FormBuilder) {
    this.userForm = this.fb.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(8)]]
    });
  }

  onSubmit() {
    if (this.userForm.valid) {
      console.log(this.userForm.value);
    }
  }
}

New Approach (Signal Forms):

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

interface UserForm {
  email: string;
  password: string;
}

@Component({
  selector: 'app-user-form',
  imports: [],
  template: `
    <form (submit)="onSubmit()">
      <input
        [value]="form().email"
        (input)="updateEmail($event)"
        type="email"
      />
      @if (emailError()) {
        <span class="error">{{ emailError() }}</span>
      }

      <input
        [value]="form().password"
        (input)="updatePassword($event)"
        type="password"
      />
      @if (passwordError()) {
        <span class="error">{{ passwordError() }}</span>
      }

      <button type="submit" [disabled]="!isValid()">Submit</button>
    </form>
  `,
  styles: [`
    .error { color: red; font-size: 0.875rem; }
  `]
})
export class SignalUserFormComponent {
  form = signal<UserForm>({
    email: '',
    password: ''
  });

  emailError = signal<string | null>(null);
  passwordError = signal<string | null>(null);

  isValid = () => !this.emailError() && !this.passwordError() &&
                   this.form().email && this.form().password;

  updateEmail(event: Event) {
    const value = (event.target as HTMLInputElement).value;
    this.form.update(f => ({ ...f, email: value }));

    // Validation
    if (!value) {
      this.emailError.set('Email is required');
    } else if (!this.isValidEmail(value)) {
      this.emailError.set('Invalid email format');
    } else {
      this.emailError.set(null);
    }
  }

  updatePassword(event: Event) {
    const value = (event.target as HTMLInputElement).value;
    this.form.update(f => ({ ...f, password: value }));

    // Validation
    if (!value) {
      this.passwordError.set('Password is required');
    } else if (value.length < 8) {
      this.passwordError.set('Password must be at least 8 characters');
    } else {
      this.passwordError.set(null);
    }
  }

  isValidEmail(email: string): boolean {
    return /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(email);
  }

  onSubmit() {
    if (this.isValid()) {
      console.log('Form submitted:', this.form());
    }
  }
}

Key Benefits

Full Type Safety: TypeScript knows your form structure Reactive by Default: Every change automatically triggers updates No Boilerplate: Direct signal manipulation, no FormControl wrapper needed Composable Validation: Write validators as simple functions

Want to see how this scales with nested forms or arrays? Let me know in the comments what form patterns you'd like to explore.

Unit Testing Signal Forms

import { TestBed } from '@angular/core/testing';
import { SignalUserFormComponent } from './signal-user-form.component';

describe('SignalUserFormComponent', () => {
  let component: SignalUserFormComponent;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [SignalUserFormComponent]
    });

    const fixture = TestBed.createComponent(SignalUserFormComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

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

  it('should initialize with empty form', () => {
    expect(component.form()).toEqual({
      email: '',
      password: ''
    });
  });

  it('should update email and validate', () => {
    const input = { target: { value: 'test@example.com' } } as any;
    component.updateEmail(input);

    expect(component.form().email).toBe('test@example.com');
    expect(component.emailError()).toBeNull();
  });

  it('should show error for invalid email', () => {
    const input = { target: { value: 'invalid-email' } } as any;
    component.updateEmail(input);

    expect(component.emailError()).toBe('Invalid email format');
  });

  it('should validate password length', () => {
    const input = { target: { value: 'short' } } as any;
    component.updatePassword(input);

    expect(component.passwordError()).toBe('Password must be at least 8 characters');
  });

  it('should mark form as valid when all fields are correct', () => {
    component.updateEmail({ target: { value: 'test@example.com' } } as any);
    component.updatePassword({ target: { value: 'password123' } } as any);

    expect(component.isValid()).toBe(true);
  });
});

Feature #2: Zoneless Change Detection

What Changed?

New Angular v21 apps run without zone.js by default. This means:

• Smaller bundle sizes (no zone.js overhead)

• Better performance (explicit change detection)

• More control over when updates happen

• Cleaner async handling

How to Build Zoneless Components

import { Component, signal, effect } from '@angular/core';
import { HttpClient } from '@angular/common/http';

interface User {
  id: number;
  name: string;
  email: string;
}

@Component({
  selector: 'app-user-list',
  imports: [],
  template: `
    <div>
      <h2>Users</h2>

      @if (loading()) {
        <p>Loading users...</p>
      }

      @if (error()) {
        <p class="error">{{ error() }}</p>
      }

      @if (users().length > 0) {
        <ul>
          @for (user of users(); track user.id) {
            <li>
              <strong>{{ user.name }}</strong> - {{ user.email }}
            </li>
          }
        </ul>
      }

      <button (click)="loadUsers()">Refresh</button>
    </div>
  `,
  styles: [`
    .error { color: red; }
    ul { list-style: none; padding: 0; }
    li { padding: 0.5rem; border-bottom: 1px solid #eee; }
  `]
})
export class UserListComponent {
  users = signal<User[]>([]);
  loading = signal(false);
  error = signal<string | null>(null);

  constructor(private http: HttpClient) {
    this.loadUsers();
  }

  loadUsers() {
    this.loading.set(true);
    this.error.set(null);

    this.http.get<User[]>('<https://jsonplaceholder.typicode.com/users>')
      .subscribe({
        next: (data) => {
          this.users.set(data);
          this.loading.set(false);
        },
        error: (err) => {
          this.error.set('Failed to load users');
          this.loading.set(false);
        }
      });
  }
}

Notice What's Different?

No more NgZone.run() calls No manual change detection triggers Signals handle reactivity automatically Control flow syntax (@if, @for) works seamlessly

Unit Testing Zoneless Components

import { TestBed } from '@angular/core/testing';
import { provideHttpClient } from '@angular/common/http';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';
import { UserListComponent } from './user-list.component';

describe('UserListComponent (Zoneless)', () => {
  let component: UserListComponent;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [UserListComponent],
      providers: [
        provideHttpClient(),
        provideHttpClientTesting()
      ]
    });

    httpMock = TestBed.inject(HttpTestingController);
    const fixture = TestBed.createComponent(UserListComponent);
    component = fixture.componentInstance;
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should load users on initialization', () => {
    const mockUsers = [
      { id: 1, name: 'John Doe', email: 'john@example.com' }
    ];

    const req = httpMock.expectOne('<https://jsonplaceholder.typicode.com/users>');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);

    expect(component.users()).toEqual(mockUsers);
    expect(component.loading()).toBe(false);
  });

  it('should handle errors gracefully', () => {
    const req = httpMock.expectOne('<https://jsonplaceholder.typicode.com/users>');
    req.error(new ProgressEvent('error'));

    expect(component.error()).toBe('Failed to load users');
    expect(component.loading()).toBe(false);
  });

  it('should refresh users on button click', () => {
    // Clear initial request
    httpMock.expectOne('<https://jsonplaceholder.typicode.com/users>').flush([]);

    component.loadUsers();

    const req = httpMock.expectOne('<https://jsonplaceholder.typicode.com/users>');
    expect(component.loading()).toBe(true);
    req.flush([{ id: 2, name: 'Jane', email: 'jane@example.com' }]);

    expect(component.loading()).toBe(false);
  });
});

Feature #3: Angular Aria - Headless Accessibility

Angular Aria provides fully accessible, headless UI components. You bring the styling, Angular brings the accessibility logic.

Building an Accessible Combobox

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

interface Option {
  id: string;
  label: string;
}

@Component({
  selector: 'app-search-combobox',
  imports: [],
  template: `
    <div class="combobox-container">
      <label for="search-input">Search frameworks:</label>

      <input
        id="search-input"
        type="text"
        [value]="searchTerm()"
        (input)="onSearch($event)"
        (focus)="isOpen.set(true)"
        role="combobox"
        aria-expanded="{{ isOpen() }}"
        aria-controls="options-list"
        aria-autocomplete="list"
      />

      @if (isOpen() && filteredOptions().length > 0) {
        <ul
          id="options-list"
          role="listbox"
          class="options-list"
        >
          @for (option of filteredOptions(); track option.id) {
            <li
              role="option"
              [attr.aria-selected]="selectedId() === option.id"
              [class.selected]="selectedId() === option.id"
              (click)="selectOption(option)"
            >
              {{ option.label }}
            </li>
          }
        </ul>
      }

      @if (selectedOption()) {
        <p>Selected: <strong>{{ selectedOption()!.label }}</strong></p>
      }
    </div>
  `,
  styles: [`
    .combobox-container {
      position: relative;
      width: 300px;
    }

    input {
      width: 100%;
      padding: 0.5rem;
      border: 1px solid #ccc;
      border-radius: 4px;
    }

    .options-list {
      position: absolute;
      width: 100%;
      max-height: 200px;
      overflow-y: auto;
      background: white;
      border: 1px solid #ccc;
      border-radius: 4px;
      margin: 0;
      padding: 0;
      list-style: none;
      box-shadow: 0 2px 8px rgba(0,0,0,0.1);
    }

    .options-list li {
      padding: 0.5rem;
      cursor: pointer;
    }

    .options-list li:hover {
      background: #f0f0f0;
    }

    .options-list li.selected {
      background: #007bff;
      color: white;
    }
  `]
})
export class SearchComboboxComponent {
  options = signal<Option[]>([
    { id: '1', label: 'Angular' },
    { id: '2', label: 'React' },
    { id: '3', label: 'Vue' },
    { id: '4', label: 'Svelte' },
    { id: '5', label: 'Solid' }
  ]);

  searchTerm = signal('');
  isOpen = signal(false);
  selectedId = signal<string | null>(null);

  filteredOptions = signal<Option[]>([]);
  selectedOption = signal<Option | null>(null);

  constructor() {
    this.filteredOptions.set(this.options());
  }

  onSearch(event: Event) {
    const value = (event.target as HTMLInputElement).value;
    this.searchTerm.set(value);

    const filtered = this.options().filter(opt =>
      opt.label.toLowerCase().includes(value.toLowerCase())
    );

    this.filteredOptions.set(filtered);
    this.isOpen.set(true);
  }

  selectOption(option: Option) {
    this.selectedId.set(option.id);
    this.selectedOption.set(option);
    this.searchTerm.set(option.label);
    this.isOpen.set(false);
  }
}

Unit Testing Accessible Components

import { TestBed } from '@angular/core/testing';
import { SearchComboboxComponent } from './search-combobox.component';

describe('SearchComboboxComponent', () => {
  let component: SearchComboboxComponent;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [SearchComboboxComponent]
    });

    const fixture = TestBed.createComponent(SearchComboboxComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should filter options based on search term', () => {
    const event = { target: { value: 'ang' } } as any;
    component.onSearch(event);

    expect(component.filteredOptions().length).toBe(1);
    expect(component.filteredOptions()[0].label).toBe('Angular');
  });

  it('should select option when clicked', () => {
    const option = { id: '1', label: 'Angular' };
    component.selectOption(option);

    expect(component.selectedOption()).toEqual(option);
    expect(component.selectedId()).toBe('1');
    expect(component.isOpen()).toBe(false);
  });

  it('should open dropdown on focus', () => {
    component.isOpen.set(false);
    const event = { target: { value: '' } } as any;
    component.onSearch(event);

    expect(component.isOpen()).toBe(true);
  });
});

Feature #4: Vitest as Default Test Runner

Vitest is now the default for new Angular projects. Here's why it matters:

Faster test execution Better ESM support Hot module reloading for tests Compatible with Vite's ecosystem

Setting Up Vitest in Existing Projects

npm install -D vitest @vitest/ui @angular/build

vitest.config.ts:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: ['src/test-setup.ts'],
    include: ['src/**/*.{test,spec}.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
    },
  },
});

Migration Strategies for Existing Apps

Step 1: Audit Your Codebase

Run this command to see what needs updating:

ng update @angular/core@21 @angular/cli@21

Step 2: Enable Zoneless Gradually

import { bootstrapApplication } from '@angular/platform-browser';
import { provideExperimentalZonelessChangeDetection } from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

Step 3: Migrate Forms Selectively

Don't migrate all forms at once. Start with new features using Signal Forms, then gradually refactor existing forms.

Step 4: Update Test Configuration

Switch to Vitest for new test files while keeping existing Karma tests running.

Bonus Tips

Tip 1: Use the Angular CLI's built-in migration schematics to automate control flow syntax updates.

Tip 2: Leverage the new CLDR updates (v47) for better internationalization support—especially if you're building multi-language apps.

Tip 3: Explore the Material Design utility classes for design tokens. They make theming much easier.

Tip 4: Check out the new Angular + AI documentation section on angular.dev if you're building AI-powered features.

Tip 5: The regex support in templates is a game-changer for validation without custom validators.

Quick Recap

Angular v21 is a strategic inflection point for the framework:

Signal-based Forms bring type safety and reactivity to form handling Zoneless architecture means better performance and smaller bundles Angular Aria makes accessibility a first-class citizen Vitest provides a modern, faster testing experience The ecosystem is maturing toward signals-first, reactive patterns

For new projects, adopt v21 immediately. For existing apps, plan a phased migration focusing on high-impact areas first.

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Reference: Official Angular v21 Announcement

I've been there too. Font icons seemed like the obvious choice until I realized they're actually holding us back. What if I told you there's a cleaner, more scalable way to handle icons in Angular Material that gives you pixel-perfect results every time?

Here's what you'll learn by the end of this article:

• Why SVG icons are superior to font icons (and when you should make the switch)

• How to properly configure Angular Material's mat-icon for SVG icons

• Step-by-step setup with real code examples

• Pro tips for organizing and optimizing your icon workflow

• Common pitfalls and how to avoid them

Before we dive in—what's your biggest frustration with icons in Angular? Drop a comment below; I genuinely want to know what's been tripping you up!

Why SVG Icons Beat Font Icons Every Time

Let's be honest—font icons were a clever hack for their time, but they come with baggage:

• Accessibility issues (screen readers struggle with them)

• Loading dependencies (entire font files for a few icons)

• Styling limitations (you're stuck with single colors)

• Rendering inconsistencies across different browsers

SVG icons, on the other hand, are:

Scalable without quality loss

Accessible with proper ARIA labels

Lightweight (only load what you need)

Customizable (colors, gradients, animations)

Crisp on all screen densities

Setting Up Your Angular Material Project

First things first—let's make sure you have Angular Material properly installed. If you're starting fresh:

ng add @angular/material

Choose your theme, enable animations, and include the Angular Material typography styles when prompted.

Already have Angular Material? Perfect! Let's jump into the icon setup.

Step 1: Configure the MatIconModule

In your app.module.ts (or wherever you're importing Angular Material modules):

import { NgModule } from '@angular/core';
import { MatIconModule } from '@angular/material/icon';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  imports: [
    // ... other imports
    MatIconModule,
    HttpClientModule, // Required for loading SVG icons
  ],
  // ... rest of your module
})
export class AppModule { }

Why do we need HttpClientModule? Angular Material fetches SVG icons via HTTP requests, so this is essential for the setup to work.

Step 2: Register Your SVG Icons

Here's where the magic happens. In your component or service, you'll register your SVG icons with Angular Material's MatIconRegistry:

import { Component, OnInit } from '@angular/core';
import { MatIconRegistry } from '@angular/material/icon';
import { DomSanitizer } from '@angular/platform-browser';

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.scss']
})
export class DashboardComponent implements OnInit {

  constructor(
    private matIconRegistry: MatIconRegistry,
    private domSanitizer: DomSanitizer
  ) {}

  ngOnInit() {
    // Register a single SVG icon
    this.matIconRegistry.addSvgIcon(
      'custom-user',
      this.domSanitizer.bypassSecurityTrustResourceUrl('assets/icons/user.svg')
    );

    // Register an entire icon set
    this.matIconRegistry.addSvgIconSet(
      this.domSanitizer.bypassSecurityTrustResourceUrl('assets/icons/icon-set.svg')
    );
  }
}

Hold up—what's with the DomSanitizer? Angular's security model blocks external resources by default. The bypassSecurityTrustResourceUrl method tells Angular that your SVG files are safe to load.

Step 3: Use Your SVG Icons in Templates

Now comes the satisfying part—actually using your icons:

<!-- Using a registered custom icon -->
<mat-icon svgIcon="custom-user"></mat-icon>

<!-- Using Material Design icons (if you have the icon font loaded) -->
<mat-icon>home</mat-icon>

<!-- Styling your icons -->
<mat-icon svgIcon="custom-user" class="large-icon"></mat-icon>

And in your CSS:

.large-icon {
  width: 48px;
  height: 48px;
  font-size: 48px;
}

// Custom colors
mat-icon {
  color: #3f51b5;
}

// Hover effects
mat-icon:hover {
  color: #303f9f;
  transform: scale(1.1);
  transition: all 0.2s ease;
}

Quick question for you: Are you currently using font icons in your Angular project? What's holding you back from switching to SVG?

Pro Tip: Create an Icon Service

For larger projects, I recommend creating a dedicated service to manage your icons. This keeps your components clean and your icon registration centralized:

import { Injectable } from '@angular/core';
import { MatIconRegistry } from '@angular/material/icon';
import { DomSanitizer } from '@angular/platform-browser';

@Injectable({
  providedIn: 'root'
})
export class IconService {

  constructor(
    private matIconRegistry: MatIconRegistry,
    private domSanitizer: DomSanitizer
  ) {
    this.registerIcons();
  }

  private registerIcons(): void {
    const icons = [
      'user',
      'settings',
      'dashboard',
      'notifications',
      'logout'
    ];

    icons.forEach(icon => {
      this.matIconRegistry.addSvgIcon(
        icon,
        this.domSanitizer.bypassSecurityTrustResourceUrl(`assets/icons/${icon}.svg`)
      );
    });
  }
}

Then inject this service in your AppComponent constructor:

export class AppComponent {
  constructor(private iconService: IconService) {
    // Icons are automatically registered when the service is injected
  }
}

Step 4: Organize Your SVG Files

Here's how I structure my icon assets:

src/
  assets/
    icons/
      ui/
        user.svg
        settings.svg
        dashboard.svg
      social/
        facebook.svg
        twitter.svg
        linkedin.svg
      actions/
        save.svg
        delete.svg
        edit.svg

This organization makes it easy to:

• Find icons quickly

• Maintain consistent naming

• Scale your icon library

• Implement icon namespacing if needed

Common Pitfalls (And How to Avoid Them)

1. Forgetting the HttpClientModule

// This won't work without HttpClientModule
this.matIconRegistry.addSvgIcon(...)

// Import HttpClientModule in your module
imports: [HttpClientModule, MatIconModule]

2. SVG viewBox Issues Make sure your SVG files have proper viewBox attributes:

<!-- Good SVG structure -->
<svg viewBox="0 0 24 24" xmlns="<http://www.w3.org/2000/svg>">
  <!-- icon content -->
</svg>

3. Icon Not Showing Up Check your browser's network tab—you might see 404 errors for missing SVG files.

4. Security Errors Always use DomSanitizer.bypassSecurityTrustResourceUrl() when registering icons.

Bonus: Icon Sets for Multiple Namespaces

Want to organize icons by category? Use icon sets with namespaces:

// Register namespaced icon sets
this.matIconRegistry.addSvgIconSetInNamespace(
  'ui',
  this.domSanitizer.bypassSecurityTrustResourceUrl('assets/icons/ui-icons.svg')
);

this.matIconRegistry.addSvgIconSetInNamespace(
  'social',
  this.domSanitizer.bypassSecurityTrustResourceUrl('assets/icons/social-icons.svg')
);

Then use them like this:

<mat-icon svgIcon="ui:user"></mat-icon>
<mat-icon svgIcon="social:facebook"></mat-icon>

Performance Optimization Tips

1. Lazy Load Icons Only register icons when they're needed:

async loadDashboardIcons() {
  const icons = await import('./dashboard-icons');
  icons.registerDashboardIcons(this.matIconRegistry, this.domSanitizer);
}

2. Use Angular's Built-in Icon Library For common icons, consider using Angular Material's built-in icons:

<!-- No registration needed -->
<mat-icon>home</mat-icon>
<mat-icon>settings</mat-icon>
<mat-icon>person</mat-icon>

3. Optimize Your SVG Files Use tools like SVGO to compress your SVG files:

npm install -g svgo
svgo assets/icons/*.svg

Real-World Example: Building a Navigation Menu

Let's put it all together with a practical example:

// navigation.component.ts
export class NavigationComponent implements OnInit {
  menuItems = [
    { icon: 'dashboard', label: 'Dashboard', route: '/dashboard' },
    { icon: 'custom-user', label: 'Profile', route: '/profile' },
    { icon: 'settings', label: 'Settings', route: '/settings' },
    { icon: 'logout', label: 'Logout', route: '/logout' }
  ];

  constructor(
    private matIconRegistry: MatIconRegistry,
    private domSanitizer: DomSanitizer
  ) {}

  ngOnInit() {
    this.registerCustomIcons();
  }

  private registerCustomIcons() {
    this.matIconRegistry.addSvgIcon(
      'custom-user',
      this.domSanitizer.bypassSecurityTrustResourceUrl('assets/icons/user.svg')
    );
  }
}

<!-- navigation.component.html -->
<nav class="sidebar">
  <div class="nav-item" *ngFor="let item of menuItems">
    <mat-icon
      [svgIcon]="item.icon.startsWith('custom-') ? item.icon : null"
      class="nav-icon">
      {{ item.icon.startsWith('custom-') ? '' : item.icon }}
    </mat-icon>
    <span class="nav-label">{{ item.label }}</span>
  </div>
</nav>

/* navigation.component.scss */
.sidebar {
  .nav-item {
    display: flex;
    align-items: center;
    padding: 12px 16px;
    cursor: pointer;
    transition: background-color 0.2s ease;

    &:hover {
      background-color: #f5f5f5;
    }

    .nav-icon {
      margin-right: 12px;
      color: #666;
    }

    .nav-label {
      font-size: 14px;
      color: #333;
    }
  }
}

Try this yourself: Can you modify the example above to add hover animations to the icons? Share your solution in the comments!

What's Next?

You now have everything you need to implement SVG icons in your Angular Material projects. But don't stop here—consider exploring:

• Icon animation libraries like LottieFiles for complex animations

• Icon generation tools that create optimized SVG sprites

• Design system integration for consistent icon usage across teams

Key Takeaways

SVG icons are superior to font icons for modern web applications

Angular Material's mat-icon makes SVG integration straightforward

Proper organization and service-based architecture scales well

Performance optimization keeps your app fast and responsive

Security considerations are handled by Angular's DomSanitizer

Let's Keep the Conversation Going!

I want to hear from you:

What did you learn? Have you tried implementing SVG icons in your Angular project yet? What challenges did you face?

Drop a comment below—I read every single one and often turn great questions into future articles!

🔥 Found this helpful? 👏 Hit that clap button (or give it 5 claps!) so other developers can discover this guide too.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Have you ever struggled to mock services, constants, timers, or injected dependencies in Angular—especially after switching to standalone components?

You're not alone.

With Angular moving towards standalone APIs and modular design, our testing practices must evolve too. If you're still using TestBed.configureTestingModule() for everything—you might be doing more than you need.

In this guide, you'll learn exactly how to mock Angular services, RxJS-based timers, external libraries, constants, and directives in Jest, using modern Angular testing practices that are clean, scalable, and memory-safe.

🎯 What You’ll Learn

• How to test standalone Angular services with Jest

• Mocking HTTP requests using HttpClientTestingModule with standalone setup

• Handling dependency injection with external libraries, constants, pipes, or directives

• Simulating timers and RxJS interval, timer, or setTimeout with jest.useFakeTimers()

• Making Jest tests memory-efficient (why and how)

• Practical code demos for each use case

• Jest best practice

• Angular best practice

🔧 Example: Standalone Angular Service

📦 user.service.ts

import { inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, timer } from 'rxjs';
import { map } from 'rxjs/operators';
import { API_URL } from './tokens'; // a custom InjectionToken

@Injectable({ providedIn: 'root' })
export class UserService {
  private http = inject(HttpClient);
  private baseUrl = inject(API_URL); // Using custom token

  getUser(id: number): Observable<any> {
    return this.http.get(`${this.baseUrl}/users/${id}`);
  }

  getUserWithDelay(id: number): Observable<any> {
    return timer(1000).pipe(
      map(() => ({ id, name: 'Delayed User' }))
    );
  }
}

✅ Unit Test Using Standalone Jest Setup

🔬 user.service.spec.ts

import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { TestBed } from '@angular/core/testing';
import { UserService } from './user.service';
import { API_URL } from './tokens';
import { jest } from '@jest/globals';

describe('UserService (Standalone + Jest)', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [
        UserService,
        { provide: API_URL, useValue: '<https://mock.api>' }
      ]
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify(); // ✅ Ensures no memory leaks from open HTTP calls
    jest.clearAllTimers(); // ✅ Reset timers between tests
  });

  it('should fetch user by ID', () => {
    const mockUser = { id: 1, name: 'Jane' };

    service.getUser(1).subscribe(user => {
      expect(user).toEqual(mockUser);
    });

    const req = httpMock.expectOne('<https://mock.api/users/1>');
    expect(req.request.method).toBe('GET');
    req.flush(mockUser);
  });

  it('should return delayed user with fake timer', () => {
    jest.useFakeTimers(); // ✅ Prevent real timer execution
    let result: any;

    service.getUserWithDelay(2).subscribe(user => (result = user));

    jest.advanceTimersByTime(1000); // Simulate delay
    expect(result).toEqual({ id: 2, name: 'Delayed User' });
  });
});

🧠 Section: Spying and Mocking With jest.fn()

How to:

• Replace service methods

• Simulate return values or throw errors

• Combine jest.spyOn() with dependency injection

const mockUserService = {
  getUser: jest.fn().mockReturnValue(of({ id: 1, name: 'Mock User' })),
};

🛠️ Section: Error Handling & Retry Tests

Demo:

• Simulating 500 errors

• Handling retries with retry() operator

• Verifying failure UI states

📦 Bonus: Shared Mocks & DRY Test Setup

How to:

• Create reusable mock-user.service.ts

• Abstract mocks in __mocks__ folder for auto-mocking

• Mock with dynamic data using factory functions

🚀 Advanced Use Case: Injecting Pipes and Directives in Angular Services

❓ Why would a service inject a pipe or directive?

• You may be using custom pipes for transformation logic you want to reuse (e.g., formatting currency, date, slugs).

• You might inject a directive that provides some shared behavior or config via @Directive({ providers: [...] }).

👉 These scenarios are uncommon but powerful—especially in design systems, custom form libraries, or rendering engines.

🎯 Demo Use Case: Injecting a Pipe and a Directive in a Service

🧩 slugify.pipe.ts

import { Pipe, PipeTransform, inject } from '@angular/core';

@Pipe({ name: 'slugify', standalone: true })
export class SlugifyPipe implements PipeTransform {
  transform(value: string): string {
    return value.toLowerCase().replace(/\\s+/g, '-');
  }
}

📍 feature-toggle.directive.ts

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

@Directive({
  selector: '[appFeatureToggle]',
  standalone: true,
  providers: [{ provide: FeatureToggleDirective, useExisting: FeatureToggleDirective }]
})
export class FeatureToggleDirective {
  isFeatureEnabled = true; // Could be dynamically set
}

💡 seo.service.ts — Using Both

import { Injectable, inject } from '@angular/core';
import { SlugifyPipe } from './slugify.pipe';
import { FeatureToggleDirective } from './feature-toggle.directive';

@Injectable({ providedIn: 'root' })
export class SeoService {
  private slugify = inject(SlugifyPipe);
  private featureToggle = inject(FeatureToggleDirective);

  getSeoSlug(title: string): string {
    if (this.featureToggle.isFeatureEnabled) {
      return this.slugify.transform(title);
    }
    return 'seo-disabled';
  }
}

✅ Jest Unit Test: Mocking Pipes and Directives

🧪 seo.service.spec.ts

import { TestBed } from '@angular/core/testing';
import { SeoService } from './seo.service';
import { SlugifyPipe } from './slugify.pipe';
import { FeatureToggleDirective } from './feature-toggle.directive';

describe('SeoService with Pipe & Directive Injection', () => {
  let service: SeoService;

  const mockSlugifyPipe: Partial<SlugifyPipe> = {
    transform: jest.fn().mockImplementation((s: string) => `slug--${s}`)
  };

  const mockFeatureToggleDirective: Partial<FeatureToggleDirective> = {
    isFeatureEnabled: true
  };

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        SeoService,
        { provide: SlugifyPipe, useValue: mockSlugifyPipe },
        { provide: FeatureToggleDirective, useValue: mockFeatureToggleDirective }
      ]
    });

    service = TestBed.inject(SeoService);
  });

  it('should return slugified title when feature is enabled', () => {
    const result = service.getSeoSlug('Hello World');
    expect(result).toBe('slug--Hello World');
  });

  it('should return "seo-disabled" if feature is off', () => {
    (mockFeatureToggleDirective.isFeatureEnabled as boolean) = false;
    const result = service.getSeoSlug('Hello World');
    expect(result).toBe('seo-disabled');
  });
});

🧵 Real Developer Talk: Why You Should Care

💡 The standalone approach is Angular’s future—and Jest is your ticket to faster, smarter, and more scalable tests.

Say goodbye to heavy test modules and long setup code.

Say hello to on-demand injection, fast feedback loops, and confidence in every refactor.

📌 Best Practices Summary

✅ Angular Testing Best Practices

• Use inject() instead of constructor injection where practical

• Avoid global providers when not needed

• Always call httpMock.verify() in afterEach

• Use jest.useFakeTimers() + jest.clearAllTimers() for memory-safe timer mocks

✅ Jest Best Practices

• Prefer jest.fn() for mocks, not manual stubs

• Use jest.mock() or jest.spyOn() for external dependencies

• Clean up side effects (timers, mocks) in afterEach

• Keep test cases small, focused, and stateless

🧠 Takeaway Best Practices

✅ Never directly depend on DOM-based directive logic in services, unless:

• The directive is logic-based (feature flags, configuration, etc.)

• It’s provided via DI using useExisting

✅ For pipes, prefer:

• @Pipe({ standalone: true }) with proper providedIn injection

• Creating mock pipes using jest.fn() in unit tests

✅ Avoid leaking real logic in tests. Always:

• Use fake timers

• Use jest mocks for all dependencies

• Avoid DOM usage in unit tests

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I'd love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Master Angular component cleanup with real-world unit tests for setTimeout, Observables, DOM listeners, AsyncPipe, and more. A complete guide to writing leak-free Angular apps.

Perfect — here are 10 comprehensive unit test cases in Angular to ensure memory leaks are avoided. These cover all critical and edge async scenarios, such as:

• setTimeout

• setInterval

• RxJS subscriptions

• AsyncPipe

• EventListeners

• Subjects

• AnimationFrames

• WebSocket/Custom cleanup

• ResizeObserver

• MutationObserver

✅ 1. Unsubscribe from RxJS with takeUntil

it('should call destroy$.next() and complete() on ngOnDestroy', () => {
  const nextSpy = jest.spyOn((component as any).destroy$, 'next');
  const completeSpy = jest.spyOn((component as any).destroy$, 'complete');

component.ngOnDestroy();
  expect(nextSpy).toHaveBeenCalledTimes(1);
  expect(completeSpy).toHaveBeenCalledTimes(1);
});

✅ 2. Clear setInterval on Destroy

it('should clear interval on destroy', () => {
  const clearSpy = jest.spyOn(window, 'clearInterval');
  component.intervalId = setInterval(() => {}, 1000);

component.ngOnDestroy();
  expect(clearSpy).toHaveBeenCalledWith(component.intervalId);
  clearInterval(component.intervalId); // cleanup
});

✅ 3. Clear setTimeout on Destroy

it('should clear timeout on destroy', () => {
  const clearSpy = jest.spyOn(window, 'clearTimeout');
  component.timeoutId = setTimeout(() => {}, 1000);

component.ngOnDestroy();
  expect(clearSpy).toHaveBeenCalledWith(component.timeoutId);
  clearTimeout(component.timeoutId); // cleanup
});

✅ 4. Remove Event Listener on Destroy

it('should remove event listener on destroy', () => {
  const removeSpy = jest.spyOn(document, 'removeEventListener');
  component.listener = jest.fn();

document.addEventListener('click', component.listener);
  component.ngOnDestroy();
  expect(removeSpy).toHaveBeenCalledWith('click', component.listener);
});

✅ 5. Verify AsyncPipe Usage — No Manual Cleanup Required

it('should have data$ defined for async pipe usage', () => {
  expect(component.data$).toBeDefined();
});

Note: AsyncPipe automatically unsubscribes on destroy.

✅ 6. Unsubscribe from Manual Subject

it('should unsubscribe from subject', () => {
  const sub = new Subject<void>();
  const spy = jest.fn();
  sub.subscribe(spy);

sub.next();
  sub.complete();
  expect(spy).toHaveBeenCalled();
});

✅ 7. Cancel requestAnimationFrame on Destroy

it('should cancel requestAnimationFrame on destroy', () => {
  const cancelSpy = jest.spyOn(window, 'cancelAnimationFrame');
  component.rafId = requestAnimationFrame(() => {});

component.ngOnDestroy();
  expect(cancelSpy).toHaveBeenCalledWith(component.rafId);
});

✅ 8. Close Custom WebSocket or Observer on Destroy

it('should close websocket connection on destroy', () => {
  component.socket = { close: jest.fn() } as any;
  component.ngOnDestroy();

expect(component.socket.close).toHaveBeenCalled();
});

✅ 9. Disconnect ResizeObserver on Destroy

it('should disconnect ResizeObserver on destroy', () => {
  component.resizeObserver = { disconnect: jest.fn() } as any;
  component.ngOnDestroy();

expect(component.resizeObserver.disconnect).toHaveBeenCalled();
});

✅ 10. Disconnect MutationObserver on Destroy

it('should disconnect MutationObserver on destroy', () => {
  component.mutationObserver = { disconnect: jest.fn() } as any;
  component.ngOnDestroy();

expect(component.mutationObserver.disconnect).toHaveBeenCalled();
});

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Angular is a powerful framework, but as your app grows, so does the size of your JavaScript bundles — and with that, your initial load time. Users today expect near-instant experiences, and waiting even a few extra seconds can lead to frustration and bounce. That’s where Angular’s lazy loading and preloading strategies come into play. These two techniques can dramatically improve your app’s performance by smartly loading only what’s needed — exactly when it’s needed.

❓ Start With a Hook Question

Is your Angular app feeling slower than it should?

In this article, I’ll walk you through how I use lazy loading and preloading strategies in Angular to optimize real-world projects.

You’ll get:

• 🚀 Real code examples

• 📊 A deep dive into when and why to preload

• 🔁 An interactive way to toggle loading strategies

• ✅ Performance results and best practices

By the end, you’ll be able to implement a hybrid strategy that keeps your initial load fast but prepares key routes ahead of time for instant transitions.

💡 Why Performance Optimization Matters

Page speed is not just about numbers — it directly impacts UX, SEO, and retention.

Angular gives us incredible flexibility with route-based code splitting (aka lazy loading) and preload strategies, but many developers stop at just lazy loading. Let’s go beyond that!

📁 Basic Lazy Loading Setup in Angular

Here’s a simple route-based lazy loading module setup:

// app-routing.module.ts
const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/admin.module').then((m) => m.AdminModule),
  },
];

✅ Explanation: This ensures the AdminModule is not part of the initial bundle. It’s loaded only when the user visits /admin.

⚙️ What’s Preloading, Then?

Preloading helps load lazily-loaded routes in the background after the app initializes.

Angular comes with a built-in strategy:

@NgModule({
  imports: [
    RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules }),
  ],
})
export class AppRoutingModule {}

🎯 This improves navigation without slowing down the first paint.

🚀 Custom Preloading Strategy (Smart Preload)

Sometimes you don’t want to preload everything. You can use route metadata:

const routes: Routes = [
  {
    path: 'dashboard',
    loadChildren: () =>
      import('./dashboard/dashboard.module').then((m) => m.DashboardModule),
    data: { preload: true },
  },
];

And create a custom strategy:

@Injectable({ providedIn: 'root' })
export class SelectivePreloadingStrategy implements PreloadingStrategy {
  preload(route: Route, fn: () => Observable<any>): Observable<any> {
    return route.data?.['preload'] ? fn() : of(null);
  }
}

Use it like this:

RouterModule.forRoot(routes, {
  preloadingStrategy: SelectivePreloadingStrategy,
});

✅ Now you control what preloads, and what doesn’t.

🧠 Pro Tips for Real-World Projects

• 🚫 Don’t lazy load core modules or auth-related module

• ✅ Always lazy load heavy feature modules (charts, tables)

• 🧠 Preload modules based on user behavior prediction

• ⏳ Consider quicklink-style preloading for anchor tag hover (advanced)

📊 Real Performance Gains

After using this strategy on a production Angular app:

• First load time dropped from 5.8s → 2.3s

• Route navigation delays reduced from ~1.2s → ❤00ms

• Google PageSpeed score improved by 18 points

✅ What You’ll Walk Away With

By now, you’ve learned:

• ✅ How to lazy load Angular modules properly

• ✅ How to preload selected modules for a smooth experience

• ✅ How to write a custom preload strategy

• ✅ How to use route metadata to control behavior

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Ever feel like you’re typing the same long Git commands over and over again?

If you’re a developer (especially a frontend or Angular developer), Git is part of your daily life. But let me ask you: What if you could save time, avoid typos, and streamline your Git workflow — all by typing just a few letters?

By the end of this article, you’ll know:

• What Git aliases are and why they matter

• How to create your own Git aliases (with real examples)

• Some must-have aliases for frontend developers

• How to make them global and persist across projects

• Bonus: How to alias complex commands and combine flags like a pro

So grab a cup of chai (or coffee ☕) — let’s optimize your Git life.

What Are Git Aliases?

A Git alias is a custom shortcut you define to avoid typing long or repetitive commands.

Think of it like a speed dial for Git.

Instead of typing:

git status

You can just type:

git s

And it works the same. Magic? Nope. Just smart config.

How to Set Up a Git Alias (Step-by-Step)

Git stores aliases in your .gitconfig file.

To add one, you can run this command:

git config --global alias.s status

Now whenever you type:

git s

It will run git status. Simple, right?

Must-Have Git Aliases for Developers

Here are some popular and time-saving aliases:

git config --global alias.s status
git config --global alias.c commit
git config --global alias.ca 'commit -a'
git config --global alias.cm 'commit -m'
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.hist "log --oneline --graph --decorate --all"

Tip: You can open your ~/.gitconfig file and edit aliases manually too.

Demo: My Favorite Git Alias — The “Hist” Log View

This one is a game-changer for visualizing branches:

git config --global alias.hist "log --oneline --graph --decorate --all"

Then just run:

git hist

And you’ll see:

* a3c9d22 (HEAD -> main) Updated README
* 934a7cd (feature/login) Added login logic
* e1a8e5b Initial commit

It’s like Git turned visual!

Advanced Git Aliases (with Parameters)

Yes, you can alias even complex commands like this:

git config --global alias.undo "reset --soft HEAD~1"

This gives you the power to “undo” your last commit, keeping changes in staging.

Usage:

git undo

Boom! Like Ctrl+Z for Git commits.

Pro Tip: Use Functions in Bash or Zsh

Want to create more interactive or multi-step Git shortcuts? Use shell functions in .bashrc or .zshrc like this:

gpush() {
  git push origin $(git branch --show-current)
}

Now just type:

gpush

It’ll push your current branch automatically.

Why Devs Should Care

As Angular/React developers, we switch branches, commit often, stash changes, and cherry-pick bug fixes. Git aliases let you do all this faster and error-free.

• Save time in daily workflows

• Reduce mental fatigue

• Look like a pro in front of your team 👨‍💻👩‍💻

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪

✨ Share Your Thoughts To 📣 Set Your Notification Preference

In this article, I’ll walk you through the key concepts, common pitfalls, and best practices when using Git submodules — explained clearly and politely, with a special focus on working with 10 or more micro frontends.

What Are Git Submodules?

Git submodules allow you to include one Git repository inside another as a subdirectory. This is especially useful when:

• Your team shares a common library across multiple applications.

• You want to keep each micro frontend in a separate Git repo, but still orchestrate and manage them from a parent repo.

Cloning a Repo with Submodules

When cloning a parent repository that contains submodules, the submodules are not downloaded by default.

Recommended way:

git clone --recursive <parent-repo-url>

If you cloned without -recursive, do:

git submodule update --init --recursive

This will initialize and fetch all submodules and their history.

How Git Handles Submodule References

Each submodule is pinned to a specific commit. This information is not stored in the .gitmodules file, but rather inside the parent repo’s .git directory.

You can find what commit the submodule is pinned to using:

git submodule status

This ensures that the parent repo can keep track of exact versions of each micro frontend, leading to consistent builds and deployments.

Making Changes Inside a Submodule

Submodules are treated as completely separate repositories. So if you:

1. Navigate into a submodule:

2. Make changes and commit them:

The parent repo still points to the old commit. To update the reference:

cd ../
git add microfrontend-one
git commit -m "Update microfrontend-one to latest commit"

This step is crucial to notify the parent repo that it should now track the new commit of the submodule.

Switching Branches in the Parent Repo

When switching branches in the parent repo, Git does not automatically update the submodules to match the new commit references.

To sync submodules after switching branches:

git submodule update --init --recursive

This ensures that each micro frontend is on the right commit for the selected parent repo branch.

Automating Submodule Updates (Recommended for Teams)

To avoid having to manually run the above command all the time, update your Git config globally:

git config --global submodule.recurse true
git config --global fetch.recurseSubmodules true

This enables automatic updates during common Git operations like pull and checkout.

Adding a New Micro Frontend as a Submodule

To include a new micro frontend repository:

git submodule add <repo-url> microfrontend-new/

This will:

• Clone the repo

• Create or update the .gitmodules file

• Pin the submodule to the latest commit on its default branch

You may then switch to a specific commit or branch in that submodule and commit the change in the parent repo.

Removing a Submodule

To safely remove a submodule:

git rm --cached <path-to-submodule>
rm -rf <path-to-submodule>

Then commit the changes in the parent repo. Modern Git versions handle submodule removal more gracefully than older ones.

🧠 Best Practices for Using Submodules in Micro Frontend Setups

1. Use the latest Git version — submodule UX is significantly improved.

2. Pin to specific commits for deterministic builds.

3. Keep submodules clean — avoid mixing parent and submodule changes in one commit.

4. Add aliases for common submodule commands to streamline workflows.

5. Ensure all team members are trained in submodule workflows to avoid accidental breakage.

Alternatives to Git Submodules

Before committing to submodules, consider these alternatives:

1. Package Manager Approach

Publish each micro frontend as a package via npm (public or private). Then reference them via package.json.

✅ Easier for CI/CD and version management

⛔ Requires package management setup and publishing

2. Monorepo Approach

Manage all micro frontends inside one repo using tools like Nx, Turborepo, or Lerna.

✅ Centralized development and tooling

⛔ Heavier for large codebases if not structured well

📢 Final Thoughts

While Git submodules offer a clean and elegant mechanism to manage independent micro frontend repositories, they can introduce complexity. If your team is already using them, the tips above should help you manage them more effectively. Otherwise, evaluate whether alternatives like npm packages or a monorepo better suit your workflow.

If you’re working with a large team and find Git submodules confusing, it might be time to:

• Set up clear documentation

• Provide Git training or workshops

• Automate repetitive tasks with aliases or scripts

🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Ever felt like Angular's change detection was that one friend who shows up uninvited to every party? You know, constantly checking if anything changed, even when nothing did? 🤔

Well, Angular Signals just changed the game—and if you're not using computed and linkedSignal yet, you're missing out on some serious performance gains and cleaner code.

By the end of this article, you'll know:

• When to reach for computed vs linkedSignal (and why it matters)

• How to build reactive features without Zone.js breathing down your neck

• Real-world patterns that'll make your senior devs do a double-take

• The performance tricks that separate good Angular apps from great ones

Let's dive in! But first, quick question: Are you still manually managing subscriptions in 2025? Drop a comment below—I'm genuinely curious! 👇

Why Angular Signals Are Your New Best Friend

Remember the days of wrestling with RxJS subscriptions, memory leaks, and that one ngOnDestroy you forgot to implement? Angular Signals are here to save us from that chaos.

Signals bring fine-grained reactivity to Angular—meaning your app only updates what needs updating, when it needs updating. No more Zone.js checking everything under the sun.

// The old way (we've all been there)
export class OldSchoolComponent {
  count$ = new BehaviorSubject(0);
  doubled$ = this.count$.pipe(map(n => n * 2));

  ngOnDestroy() {
    // Don't forget this! (But we always do...)
  }
}

// The signals way (clean and simple)
export class ModernComponent {
  count = signal(0);
  doubled = computed(() => this.count() * 2);
  // No cleanup needed! 🎉
}

Computed Signals: Your Reactive Calculator 🧮

What Are Computed Signals?

Think of computed as that smart friend who always knows the answer because they're constantly doing the math in their head. Computed signals automatically derive values from other signals and update whenever their dependencies change.

The Magic in Action

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

export class PriceCalculatorComponent {
  // Base signals
  quantity = signal(1);
  pricePerUnit = signal(99.99);
  discountPercent = signal(0);

  // Computed magic happens here
  subtotal = computed(() =>
    this.quantity() * this.pricePerUnit()
  );

  discountAmount = computed(() =>
    this.subtotal() * (this.discountPercent() / 100)
  );

  total = computed(() =>
    this.subtotal() - this.discountAmount()
  );

  // Update quantity, everything recalculates automatically!
  addToCart() {
    this.quantity.update(q => q + 1);
  }
}

When should you use computed?

• ✅ Deriving values from other signals

• ✅ Calculations that depend on multiple signals

• ✅ Read-only derived state

• ✅ Performance-critical computations (they're memoized!)

💡 Pro tip: Computed signals are lazy and cached. They only recalculate when accessed AND their dependencies changed. That's free performance right there!

LinkedSignal: The Two-Way Street 🔄

Enter LinkedSignal: Computed's Flexible Cousin

While computed is read-only, linkedSignal is that friend who listens but also has opinions. It can derive from other signals AND be manually updated—perfect for syncing with external sources or handling bi-directional data flow.

LinkedSignal in the Wild

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

export class UserPreferencesComponent {
  // Source signal
  fahrenheit = signal(72);

  // LinkedSignal that syncs both ways
  celsius = linkedSignal(() =>
    Math.round((this.fahrenheit() - 32) * 5/9)
  );

  // You can update it directly!
  updateCelsius(value: number) {
    this.celsius.set(value);
    // Now fahrenheit is out of sync, but that's okay!
    // LinkedSignal allows this flexibility
  }

  // Or sync it back
  syncFromCelsius() {
    const c = this.celsius();
    this.fahrenheit.set(Math.round(c * 9/5 + 32));
  }
}

Real-World Example: Form Input Sync

Here's where linkedSignal really shines—syncing form inputs with formatted displays:

export class PaymentFormComponent {
  // Raw input value
  rawCardNumber = signal('');

  // Formatted display that can also be edited
  formattedCardNumber = linkedSignal(() => {
    const raw = this.rawCardNumber().replace(/\\s/g, '');
    return raw.match(/.{1,4}/g)?.join(' ') || '';
  });

  onFormattedInput(value: string) {
    // Update the formatted version
    this.formattedCardNumber.set(value);
    // Extract and update raw
    this.rawCardNumber.set(value.replace(/\\s/g, ''));
  }
}

When to reach for linkedSignal?

• ✅ Two-way data binding scenarios

• ✅ Syncing with external APIs or localStorage

• ✅ Form inputs that need formatting

• ✅ Temporary overrides of computed values

The Ultimate Comparison: Computed vs LinkedSignal 🥊

What They Share

• 🎯 Both derive from other signals

• 🎯 Both update reactively

• 🎯 Both are lazy (compute on-demand)

• 🎯 Both integrate seamlessly with Angular's template system

The Key Differences

Decision Tree (Yes, I Made One for You!)

// Ask yourself:
const shouldUseComputed = () => {
  if (needToManuallyUpdate) return false;
  if (pureCalculation) return true;
  if (externalDataSync) return false;
  return true; // When in doubt, computed is usually right
};

Quick question: What's your most complex reactive state scenario? I'd love to hear how you'd solve it with signals! Drop it in the comments 💬

Real-World Example: Dynamic Pricing Calculator 💰

Let's build something practical—a pricing calculator with tax, discounts, and currency conversion:

@Component({
  selector: 'app-pricing',
  template: `
    <div class="pricing-calculator">
      <h3>Product Pricing</h3>

      <label>
        Quantity:
        <input type="number"
               [value]="quantity()"
               (input)="quantity.set(+$event.target.value)">
      </label>

      <label>
        Discount Code:
        <input [value]="discountCode()"
               (input)="applyDiscount($event.target.value)">
      </label>

      <div class="results">
        <p>Subtotal: {{ subtotal() | currency }}</p>
        <p>Discount: -{{ discountAmount() | currency }}</p>
        <p>Tax: {{ taxAmount() | currency }}</p>
        <h4>Total: {{ finalPrice() | currency }}</h4>

        <!-- LinkedSignal for currency display -->
        <p>In EUR: € {{ priceInEur() }}</p>
        <button (click)="overrideEurPrice()">
          Set Custom EUR Price
        </button>
      </div>
    </div>
  `
})
export class PricingCalculatorComponent {
  // Base signals
  quantity = signal(1);
  unitPrice = signal(49.99);
  discountCode = signal('');
  taxRate = signal(0.08); // 8% tax

  // Computed for calculations
  subtotal = computed(() =>
    this.quantity() * this.unitPrice()
  );

  discountPercent = computed(() => {
    const code = this.discountCode();
    // Simple discount logic
    switch(code) {
      case 'SAVE10': return 0.10;
      case 'SAVE20': return 0.20;
      case 'HALFOFF': return 0.50;
      default: return 0;
    }
  });

  discountAmount = computed(() =>
    this.subtotal() * this.discountPercent()
  );

  taxableAmount = computed(() =>
    this.subtotal() - this.discountAmount()
  );

  taxAmount = computed(() =>
    this.taxableAmount() * this.taxRate()
  );

  finalPrice = computed(() =>
    this.taxableAmount() + this.taxAmount()
  );

  // LinkedSignal for currency conversion
  // Can be overridden by user or API
  priceInEur = linkedSignal(() =>
    // Assuming 1 USD = 0.92 EUR
    Math.round(this.finalPrice() * 0.92 * 100) / 100
  );

  applyDiscount(code: string) {
    this.discountCode.set(code.toUpperCase());
  }

  overrideEurPrice() {
    // Maybe from an API or user input
    const customPrice = prompt('Enter custom EUR price:');
    if (customPrice) {
      this.priceInEur.set(parseFloat(customPrice));
    }
  }
}

Unit Testing Your Signals (Because We're Professionals) 🧪

Nobody talks about testing signals, but here's how to do it right:

describe('PricingCalculatorComponent', () => {
  let component: PricingCalculatorComponent;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [PricingCalculatorComponent]
    });

    const fixture = TestBed.createComponent(PricingCalculatorComponent);
    component = fixture.componentInstance;
  });

  it('should calculate subtotal correctly', () => {
    component.quantity.set(3);
    component.unitPrice.set(10);

    expect(component.subtotal()).toBe(30);
  });

  it('should apply discount code', () => {
    component.quantity.set(2);
    component.unitPrice.set(50);
    component.discountCode.set('SAVE20');

    expect(component.discountAmount()).toBe(20);
    expect(component.finalPrice()).toBe(86.4); // 80 + 8% tax
  });

  it('should allow EUR price override with linkedSignal', () => {
    component.finalPrice = signal(100); // Mock final price

    // Check computed value
    expect(component.priceInEur()).toBeCloseTo(92);

    // Override it
    component.priceInEur.set(95);
    expect(component.priceInEur()).toBe(95);

    // It's now disconnected from the source
    component.finalPrice.set(200);
    expect(component.priceInEur()).toBe(95); // Still 95!
  });
});

Best Practices & Performance Tips 🚀

Do's ✅

1. Keep computed signals pure

    // Good
    total = computed(() => this.price() * this.quantity());
   
    // Bad - side effects!
    total = computed(() => {
      console.log('Computing...'); // Don't do this
      return this.price() * this.quantity();
    });
   

2. Use linkedSignal for temporary overrides

    // Perfect use case
    autoSavedValue = linkedSignal(() => this.userInput());
    // User can override, but it resyncs on source change
   

3. Batch signal updates

    updateMultiple() {
      // Angular batches these automatically!
      this.firstName.set('John');
      this.lastName.set('Doe');
      this.age.set(30);
      // Only one change detection cycle!
    }
   

Don'ts ❌

1. Don't create circular dependencies

    // This will cause infinite loops!
    a = computed(() => this.b() + 1);
    b = computed(() => this.a() - 1);
   

2. Don't overuse linkedSignal

    // If you never need to set(), use computed instead
    readonly = linkedSignal(() => this.source());
    // Better: readonly = computed(() => this.source());
   

💡 Bonus Tip: The Signal Effect Pattern

Here's a pattern I love for side effects with signals:

export class NotificationComponent {
  message = signal('');

  constructor() {
    // React to signal changes with effects
    effect(() => {
      const msg = this.message();
      if (msg) {
        this.showToast(msg);
        // Auto-clear after 3 seconds
        setTimeout(() => this.message.set(''), 3000);
      }
    });
  }

  private showToast(msg: string) {
    // Your toast logic here
  }
}

Recap: Your Signal Superpowers 🦸‍♂️

Let's wrap this up with what you've learned:

🎯 Computed signals are your go-to for:

• Derived values that are always in sync

• Performance-critical calculations

• Read-only reactive state

🎯 LinkedSignals shine when you need:

• Bi-directional data flow

• Manual overrides of computed values

• Syncing with external sources

🎯 Key takeaway: Start with computed. Only reach for linkedSignal when you actually need that write capability. Your future self (and your team) will thank you.

Let's Keep This Conversation Going! 🚀

💭 What did you think?

Did this clear up the computed vs linkedSignal confusion? What's your take on Angular's new reactive model? Drop a comment below—I read every single one and love the discussions that follow!

👏 Found this helpful?

If this saved you from a signals-induced headache (or taught you something new), smash that clap button! Seriously, even one clap makes my day—and helps other devs discover this content.

🎯 Your Action Items:

1. Try this out: Refactor one component to use signals this week

2. Spread the knowledge: Share this with that one colleague still using RxJS for everything

One last question before you go:

What Angular topic should I tackle next?

A) Signal-based state management patterns

B) Standalone components deep dive

C) Performance profiling in Angular 18+

Vote in the comments! 👇

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠🚀

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Here's the thing: Angular Signals are incredibly powerful for managing reactive state, but they come with gotchas that can drive even experienced developers crazy. The good news? Once you understand why Signals sometimes refuse to update, you'll never get stuck on these issues again.

By the end of this article, you'll:

• ✅ Understand the 5 most common reasons Signals fail to update

• ✅ Know exactly how to debug Signal issues like a pro

• ✅ Have battle-tested patterns to avoid these problems entirely

• ✅ Get working code examples you can copy-paste right now

Quick question before we dive in: Have you ever had a Signal that just wouldn't update no matter what you tried? Drop a comment below with your weirdest Signal bug — I bet we've all been there! 💬

The Big Problem: Why Your Signals Aren't Updating

Let's start with the uncomfortable truth: 90% of Signal update issues come from treating them like regular variables. Signals need special care, and the Angular reactivity system has specific rules we need to follow.

Think of Signals like a notification system — they only notify subscribers when they detect a real change. And here's where things get tricky: what you consider a change might not be what Angular considers a change.

Let me show you exactly what I mean with real code...

🐛 Common Reason #1: Mutating Objects/Arrays Instead of Replacing Them

This is the number one killer of Signal updates. Let's look at a typical bug:

The Buggy Code:

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

export class TodoComponent {
  todos = signal<Todo[]>([]);

  addTodo(newTodo: Todo) {
    // ❌ This WON'T trigger updates!
    this.todos().push(newTodo);
  }

  removeTodo(index: number) {
    // ❌ Also won't work!
    this.todos().splice(index, 1);
  }
}

Why doesn't this work? You're mutating the existing array. The Signal still points to the same array reference, so Angular thinks nothing changed!

The Fix:

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

export class TodoComponent {
  todos = signal<Todo[]>([]);

  addTodo(newTodo: Todo) {
    // ✅ Create a new array reference
    this.todos.update(currentTodos => [...currentTodos, newTodo]);
  }

  removeTodo(index: number) {
    // ✅ Filter creates a new array
    this.todos.update(currentTodos =>
      currentTodos.filter((_, i) => i !== index)
    );
  }

  // Alternative using set()
  addTodoAlt(newTodo: Todo) {
    // ✅ Also works!
    this.todos.set([...this.todos(), newTodo]);
  }
}

Pro tip: Always think "immutable updates" when working with Signals. If you're using methods like push(), pop(), splice(), or directly modifying object properties, you're probably doing it wrong!

🐛 Common Reason #2: Misusing set(), update()

Angular gives us three ways to update Signals, and using the wrong one can cause issues:

Understanding the Methods:

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

export class UserProfileComponent {
  // For objects
  userProfile = signal({
    name: 'John',
    age: 30,
    preferences: {
      theme: 'dark',
      notifications: true
    }
  });

  // ❌ WRONG: This won't trigger updates for nested properties
  updateThemeWrong() {
    const profile = this.userProfile();
    profile.preferences.theme = 'light'; // Direct mutation!
  }

  // ✅ CORRECT: Using update() with spread operator
  updateThemeCorrect() {
    this.userProfile.update(profile => ({
      ...profile,
      preferences: {
        ...profile.preferences,
        theme: 'light'
      }
    }));
  }

  // ✅ CORRECT: Using set() with a new object
  updateThemeWithSet() {
    const currentProfile = this.userProfile();
    this.userProfile.set({
      ...currentProfile,
      preferences: {
        ...currentProfile.preferences,
        theme: 'light'
      }
    });
  }
}

When to use each:

• set(): When you have the complete new value ready

• update(): When you need to compute the new value based on the current one

🐛 Common Reason #3: Computed Signals with Side Effects

Here's a sneaky one that catches many developers:

The Buggy Code:

export class CartComponent {
  items = signal<CartItem[]>([]);

  // ❌ WRONG: Side effects in computed!
  totalPrice = computed(() => {
    const total = this.items().reduce((sum, item) =>
      sum + item.price * item.quantity, 0
    );

    // This is a side effect - DON'T do this!
    console.log('Total calculated:', total);
    this.saveToLocalStorage(total); // Another side effect!

    return total;
  });
}

The Fix:

export class CartComponent {
  items = signal<CartItem[]>([]);

  // ✅ CORRECT: Pure computed signal
  totalPrice = computed(() => {
    return this.items().reduce((sum, item) =>
      sum + item.price * item.quantity, 0
    );
  });

  // Use effect for side effects
  constructor() {
    effect(() => {
      const total = this.totalPrice();
      console.log('Total calculated:', total);
      this.saveToLocalStorage(total);
    });
  }
}

Remember: Computed signals must be pure functions — no side effects allowed!

🐛 Common Reason #4: Missing Dependencies in Effects

Effects can be tricky when you're not explicitly tracking all dependencies:

The Buggy Code:

export class NotificationComponent {
  userId = signal<number>(1);
  notifications = signal<Notification[]>([]);

  constructor() {
    // ❌ This won't re-run when userId changes!
    const id = this.userId();
    effect(() => {
      // userId is read outside the effect
      this.loadNotifications(id);
    });
  }
}

The Fix:

export class NotificationComponent {
  userId = signal<number>(1);
  notifications = signal<Notification[]>([]);

  constructor() {
    // ✅ CORRECT: Read signals inside the effect
    effect(() => {
      const id = this.userId(); // Read inside effect!
      this.loadNotifications(id);
    });
  }
}

Golden rule: Always read Signal values inside the effect function to ensure proper dependency tracking.

🐛 Common Reason #5: Async Updates Not Handled Properly

This one's a classic — async operations need special handling:

The Buggy Code:

export class DataComponent {
  data = signal<any[]>([]);

  async loadData() {
    // ❌ Signal might not update as expected
    this.data().push(...await this.apiService.getData());
  }
}

The Fix:

export class DataComponent {
  data = signal<any[]>([]);
  loading = signal<boolean>(false);

  async loadData() {
    this.loading.set(true);
    try {
      // ✅ CORRECT: Create new array with async data
      const newData = await this.apiService.getData();
      this.data.update(current => [...current, ...newData]);
    } finally {
      this.loading.set(false);
    }
  }

  // Even better with proper error handling
  async loadDataWithError() {
    this.loading.set(true);
    try {
      const response = await this.apiService.getData();
      this.data.set(response); // Replace entirely
    } catch (error) {
      console.error('Failed to load data:', error);
      // Handle error appropriately
    } finally {
      this.loading.set(false);
    }
  }
}

Quick check: Which of these issues have you run into? I'm curious — drop a comment with the number (1-5) that's bitten you the most! 👇

🔍 Debugging Signals Like a Pro

When things aren't working, here's your debugging toolkit:

1. Effect Logging Pattern

export class DebugComponent {
  mySignal = signal({ count: 0, name: 'test' });

  constructor() {
    // Debug effect - remove in production!
    effect(() => {
      console.log('🔄 Signal updated:', {
        value: this.mySignal(),
        timestamp: new Date().toISOString()
      });
    });
  }
}

2. Custom Debug Wrapper

// Create a debug signal wrapper
function debugSignal<T>(initialValue: T, name: string) {
  const sig = signal(initialValue);

  // Wrap the update method
  const originalUpdate = sig.update.bind(sig);
  sig.update = (updateFn: (value: T) => T) => {
    const oldValue = sig();
    const result = originalUpdate(updateFn);
    const newValue = sig();
    console.log(`📊 ${name} updated:`, { oldValue, newValue });
    return result;
  };

  return sig;
}

// Usage
export class MyComponent {
  todos = debugSignal<Todo[]>([], 'todos');
}

3. Angular DevTools Integration

export class DevToolsComponent {
  // Make signals visible in DevTools
  readonly debugState = computed(() => ({
    todos: this.todos(),
    filter: this.filter(),
    filtered: this.filteredTodos(),
    timestamp: Date.now()
  }));
}

📝 Real-World Example: Todo List with Common Pitfalls

Let's put it all together with a real example that shows both problems and solutions:

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

interface Todo {
  id: number;
  text: string;
  completed: boolean;
  createdAt: Date;
}

@Component({
  selector: 'app-todo-list',
  template: `
    <div class="todo-container">
      <input #todoInput (keyup.enter)="addTodo(todoInput.value); todoInput.value=''" />

      <div class="filters">
        <button (click)="filter.set('all')"
                [class.active]="filter() === 'all'">All</button>
        <button (click)="filter.set('active')"
                [class.active]="filter() === 'active'">Active</button>
        <button (click)="filter.set('completed')"
                [class.active]="filter() === 'completed'">Completed</button>
      </div>

      <ul>
        @for (todo of filteredTodos(); track todo.id) {
          <li [class.completed]="todo.completed">
            <input type="checkbox"
                   [checked]="todo.completed"
                   (change)="toggleTodo(todo.id)">
            <span>{{ todo.text }}</span>
            <button (click)="removeTodo(todo.id)">❌</button>
          </li>
        }
      </ul>

      <div class="stats">
        Active: {{ stats().active }} |
        Completed: {{ stats().completed }} |
        Total: {{ stats().total }}
      </div>
    </div>
  `
})
export class TodoListComponent {
  // Signals for state
  todos = signal<Todo[]>([]);
  filter = signal<'all' | 'active' | 'completed'>('all');
  nextId = signal(1);

  // Computed signals (pure, no side effects!)
  filteredTodos = computed(() => {
    const currentFilter = this.filter();
    const allTodos = this.todos();

    switch (currentFilter) {
      case 'active':
        return allTodos.filter(t => !t.completed);
      case 'completed':
        return allTodos.filter(t => t.completed);
      default:
        return allTodos;
    }
  });

  stats = computed(() => {
    const allTodos = this.todos();
    return {
      total: allTodos.length,
      active: allTodos.filter(t => !t.completed).length,
      completed: allTodos.filter(t => t.completed).length
    };
  });

  constructor() {
    // Effect for side effects (localStorage persistence)
    effect(() => {
      const todosToSave = this.todos();
      if (todosToSave.length > 0) {
        localStorage.setItem('todos', JSON.stringify(todosToSave));
      }
    });

    // Load initial data
    this.loadFromStorage();
  }

  addTodo(text: string) {
    if (!text.trim()) return;

    const newTodo: Todo = {
      id: this.nextId(),
      text: text.trim(),
      completed: false,
      createdAt: new Date()
    };

    // ✅ CORRECT: Using update to create new array
    this.todos.update(current => [...current, newTodo]);
    this.nextId.update(id => id + 1);
  }

  toggleTodo(id: number) {
    // ✅ CORRECT: Creating new array with updated object
    this.todos.update(todos =>
      todos.map(todo =>
        todo.id === id
          ? { ...todo, completed: !todo.completed }
          : todo
      )
    );
  }

  removeTodo(id: number) {
    // ✅ CORRECT: Filter creates new array
    this.todos.update(todos => todos.filter(t => t.id !== id));
  }

  private loadFromStorage() {
    const stored = localStorage.getItem('todos');
    if (stored) {
      try {
        const parsed = JSON.parse(stored);
        this.todos.set(parsed);
        const maxId = Math.max(...parsed.map((t: Todo) => t.id), 0);
        this.nextId.set(maxId + 1);
      } catch (e) {
        console.error('Failed to load todos:', e);
      }
    }
  }
}

🧪 Unit Testing Your Signals

Don't forget to test! Here's how to properly test Signal-based components:

import { TestBed } from '@angular/core/testing';
import { signal, effect } from '@angular/core';

describe('TodoListComponent', () => {
  let component: TodoListComponent;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [TodoListComponent]
    });
    component = TestBed.createComponent(TodoListComponent).componentInstance;
  });

  it('should add a new todo', () => {
    const initialCount = component.todos().length;

    component.addTodo('Test todo');

    expect(component.todos().length).toBe(initialCount + 1);
    expect(component.todos()[initialCount].text).toBe('Test todo');
  });

  it('should filter todos correctly', () => {
    // Setup
    component.todos.set([
      { id: 1, text: 'Active', completed: false, createdAt: new Date() },
      { id: 2, text: 'Completed', completed: true, createdAt: new Date() }
    ]);

    // Test active filter
    component.filter.set('active');
    expect(component.filteredTodos().length).toBe(1);
    expect(component.filteredTodos()[0].text).toBe('Active');

    // Test completed filter
    component.filter.set('completed');
    expect(component.filteredTodos().length).toBe(1);
    expect(component.filteredTodos()[0].text).toBe('Completed');
  });

  it('should update stats when todos change', () => {
    component.todos.set([
      { id: 1, text: 'Task 1', completed: false, createdAt: new Date() },
      { id: 2, text: 'Task 2', completed: true, createdAt: new Date() },
      { id: 3, text: 'Task 3', completed: false, createdAt: new Date() }
    ]);

    const stats = component.stats();
    expect(stats.total).toBe(3);
    expect(stats.active).toBe(2);
    expect(stats.completed).toBe(1);
  });

  it('should handle async operations correctly', (done) => {
    // Mock async operation
    spyOn(component, 'loadFromStorage').and.callFake(async () => {
      await new Promise(resolve => setTimeout(resolve, 100));
      component.todos.set([
        { id: 1, text: 'Loaded', completed: false, createdAt: new Date() }
      ]);
    });

    component.loadFromStorage().then(() => {
      expect(component.todos().length).toBe(1);
      expect(component.todos()[0].text).toBe('Loaded');
      done();
    });
  });
});

✨ Best Practices to Avoid Signal Update Issues

After debugging countless Signal issues, here are my battle-tested best practices:

1. Always Use Immutable Updates

// ✅ DO THIS
signal.update(arr => [...arr, newItem]);
signal.update(obj => ({ ...obj, newProp: value }));

// ❌ NOT THIS
signal().push(newItem);
signal().newProp = value;

2. Keep Computed Signals Pure

// ✅ DO THIS
totalPrice = computed(() =>
  this.items().reduce((sum, item) => sum + item.price, 0)
);

// ❌ NOT THIS
totalPrice = computed(() => {
  const total = this.items().reduce((sum, item) => sum + item.price, 0);
  this.saveToDatabase(total); // Side effect!
  return total;
});

3. Use Effects Wisely for Debugging

// Development debugging
constructor() {
  if (!environment.production) {
    effect(() => {
      console.log('State changed:', {
        todos: this.todos(),
        filter: this.filter()
      });
    });
  }
}

4. Create Helper Functions for Complex Updates

// Instead of complex inline updates
private updateNestedProperty<T>(
  signal: WritableSignal<T>,
  path: string[],
  value: any
): void {
  signal.update(current => {
    const updated = JSON.parse(JSON.stringify(current)); // Deep clone
    let ref = updated;
    for (let i = 0; i < path.length - 1; i++) {
      ref = ref[path[i]];
    }
    ref[path[path.length - 1]] = value;
    return updated;
  });
}

5. Document Your Signal Patterns

/**
 * Cart state management using Signals
 * - items: Array of cart items (immutable updates only!)
 * - total: Computed from items (pure function)
 * - Effects: Persist to localStorage, sync with backend
 */
export class CartService {
  // ... your code
}

💡 Bonus Tips

Here are some extra nuggets of wisdom I've learned the hard way:

1. Use Signal Inputs for Components (Angular 17.1+):

    export class ProductCard {
      // Instead of @Input()
      product = input.required<Product>();
      quantity = input(1);
    }
   

2. Batch Updates for Performance:

    // Multiple updates in one go
    batch(() => {
      this.todos.update(/* ... */);
      this.filter.set('all');
      this.loading.set(false);
    });
   

3. Create Custom Signal Factories:

    function createAsyncSignal<T>(initialValue: T) {
      const data = signal(initialValue);
      const loading = signal(false);
      const error = signal<Error | null>(null);
   
      return { data, loading, error };
    }
   

🎯 Recap: Your Signal Debugging Checklist

Let's wrap this up with a quick checklist you can bookmark:

✅ Not updating? Check if you're mutating instead of replacing

✅ Using update/set correctly? Remember the difference

✅ Computed not working? Remove side effects

✅ Effect not triggering? Read signals inside the effect

✅ Async issues? Handle promises properly with try/catch

✅ Still stuck? Add debug effects to trace changes

The truth is, 99% of Signal update issues come down to one thing: treating Signals like regular variables. Once you internalize that Signals need immutable updates and proper method usage, these problems disappear.

💬 Your Turn!

Alright, I've shared my Signal debugging war stories — now I want to hear yours!

Here's my challenge for you:

1. What's the weirdest Signal bug you've encountered? Drop it in the comments — I'll personally reply with a solution if you're still stuck! 👇

2. Which of these 5 issues surprised you the most? Let me know — I'm genuinely curious which ones catch developers off guard.

3. Got a different approach to handling Signals? Share it! The best part about our dev community is learning from each other.

🚀 Want to Level Up Your Angular Skills?

If this helped you squash that annoying Signal bug, here's how you can help me and get more content like this:

👏 Hit that clap button (you can clap up to 50 times — just saying 😉). It helps other devs discover these solutions!

📬 Follow me for more Angular deep dives — I publish practical tutorials every week, always with working code you can use immediately.

💌 Join my newsletter where I share exclusive tips, early access to articles, and answer reader questions directly. No spam, just solid dev content.

🔥 Bookmark this article — trust me, you'll need this reference when debugging Signals at 11 PM on a Friday (we've all been there).

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠🚀

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Here's the thing: Even experienced Angular developers are making these mistakes. I've seen production apps crash, performance tank, and developers scratch their heads wondering why their "modern" code isn't working as expected.

In this article, you'll discover the 5 most common (and dangerous) mistakes developers make with Angular Signals, plus 3 bonus pitfalls that could save you hours of debugging. By the end, you'll have actionable strategies to write cleaner, more performant Angular code.

💡 Quick win: Hit that 👏 if you've ever been confused about when to use Signals vs Observables - you're not alone!

Mistake #1: Not Using Signals for Dynamic State (The Future-Proofing Killer)

The Problem: You're still using traditional properties for state that changes during your app's lifecycle.

Here's what I see way too often:

@Component({
  template: `
    <div>{{ userStatus }}</div>
    <button (click)="updateStatus('active')">Set Active</button>
  `
})
export class UserComponent {
  userStatus = 'inactive'; // ❌ This will bite you later

  updateStatus(newStatus: string) {
    this.userStatus = newStatus; // ❌ No change detection optimization
  }
}

Why this hurts: When Angular rolls out Signal Components (and they will), this code will break. Your UI won't update because Angular won't know the state changed.

The Fix:

@Component({
  template: `
    <div>{{ userStatus() }}</div>
    <button (click)="updateStatus('active')">Set Active</button>
  `
})
export class UserComponent {
  userStatus = signal('inactive'); // ✅ Future-proof

  updateStatus(newStatus: string) {
    this.userStatus.set(newStatus); // ✅ Angular knows what changed
  }
}

Pro tip: Even if you're updating from a subscription, you won't need markForCheck() anymore! Angular's change detection becomes laser-focused on what actually changed.

👇 Have you been caught off-guard by change detection issues? Drop a comment below!

Mistake #2: Signal Overuse (When More Isn't Better)

The Problem: Using signals for everything, even when they're not rendered or don't need reactivity.

I've seen developers go signal-crazy:

@Component({})
export class OverEnthusiasticComponent {
  private isFirstClick = signal(true); // ❌ Overkill
  private debugMode = signal(false); // ❌ Unnecessary overhead

  handleClick() {
    if (this.isFirstClick()) {
      this.isFirstClick.set(false);
      return;
    }
    // Handle subsequent clicks
  }
}

Why this matters: You're adding unnecessary reactive overhead for values that never need to trigger UI updates.

The Fix:

@Component({})
export class SmartComponent {
  #isFirstClick = true; // ✅ Simple and efficient
  #debugMode = false; // ✅ Private and lightweight

  handleClick() {
    if (this.#isFirstClick) {
      this.#isFirstClick = false;
      return;
    }
    // Handle subsequent clicks
  }
}

Rule of thumb: If it's not rendered in the template and doesn't need reactivity, keep it simple.

📬 Want more performance tips? Subscribe to my newsletter for weekly Angular insights!

Mistake #3: Unnecessary Signal Conversions (The Verbose Trap)

The Problem: Converting Observables to Signals just to use them in effects, when you could work with the Observable directly.

Here's the verbose approach I see too often:

@Component({})
export class VerboseComponent {
  form = new FormGroup({
    email: new FormControl(''),
    password: new FormControl('')
  });

  constructor() {
    // ❌ Unnecessary conversion
    const formValue = toSignal(this.form.valueChanges);

    effect(() => {
      const value = formValue();
      // Handle form changes
      console.log('Form changed:', value);
    });
  }
}

The cleaner approach:

@Component({})
export class CleanComponent {
  form = new FormGroup({
    email: new FormControl(''),
    password: new FormControl('')
  });

  constructor() {
    // ✅ Direct and predictable
    this.form.valueChanges.pipe(
      takeUntilDestroyed()
    ).subscribe(value => {
      // Handle form changes
      console.log('Form changed:', value);
    });
  }
}

Key insight: Effects run during change detection, while Observables run immediately. Choose based on your timing needs.

Mistake #4: Unanalyzed Effect Dependencies (The Hidden Subscription Bomb)

The Problem: Writing effects without considering what signals they're actually tracking.

This innocent-looking code can cause performance nightmares:

@Component({})
export class ProblematicComponent {
  #userStore = inject(UserStore);

  constructor() {
    effect(() => {
      const currentAccount = this.#userStore.currentAccount();
      const defaultAccount = this.#userStore.defaultAccount();
      const activeAccount = currentAccount || defaultAccount;

      if (!activeAccount) return;

      // ❌ This might run twice for the same account!
      this.fetchAccountData(activeAccount);
    });
  }
}

What happens: If both currentAccount and defaultAccount change to the same value, your effect runs twice, making duplicate API calls.

The optimized solution:

@Component({})
export class OptimizedComponent {
  #userStore = inject(UserStore);

  constructor() {
    // ✅ Single source of truth
    const activeAccount = computed(() =>
      this.#userStore.currentAccount() || this.#userStore.defaultAccount()
    );

    effect(() => {
      const account = activeAccount();
      if (!account) return;

      // ✅ Runs only when the actual active account changes
      this.fetchAccountData(account);
    });
  }
}

Pro technique: Use explicitEffect from ngxtension for maximum control:

import { explicitEffect } from 'ngxtension/explicit-effect';

constructor() {
  const activeAccount = computed(() =>
    this.#userStore.currentAccount() || this.#userStore.defaultAccount()
  );

  // ✅ Crystal clear dependencies
  explicitEffect([activeAccount], ([account]) => {
    if (!account) return;
    this.fetchAccountData(account);
  });
}

💬 Have you been bitten by unexpected effect runs? Share your story in the comments!

Mistake #5: Mixing Async Pipes with Signals (The Inconsistency Problem)

The Problem: Using async pipes in a Signal-heavy codebase creates inconsistency and missed opportunities.

Mixed approach:

@Component({
  template: `
    <!-- ❌ Mixing paradigms -->
    @for (item of items$ | async; track item.id) {
      <div>{{ item.name }}</div>
    }

    <!-- ✅ Consistent signal usage -->
    @for (item of items(); track item.id) {
      <div>{{ item.name }}</div>
    }
  `
})
export class InconsistentComponent {
  #service = inject(DataService);

  // ❌ Requires async pipe, harder to access in TS
  items$ = this.#service.getData();

  // ✅ Easy synchronous access, no async pipe needed
  items = toSignal(this.#service.getData(), { initialValue: [] });
}

Benefits of the Signal approach:

• Smaller bundle size (no async pipe)

• Synchronous access to current state

• Consistent reactive patterns

• Better TypeScript integration

Bonus Mistake #6: Ignoring Signal Equality (The Unnecessary Render Trap)

The Problem: Not understanding how Signal equality works, leading to unnecessary re-renders.

@Component({})
export class InefficientComponent {
  users = signal<User[]>([]);

  addUser(user: User) {
    // ❌ Always creates new array reference
    this.users.set([...this.users(), user]);
  }

  updateUser(id: string, updates: Partial<User>) {
    // ❌ Creates new array even if user wasn't found
    this.users.set(
      this.users().map(u => u.id === id ? { ...u, ...updates } : u)
    );
  }
}

The optimized approach:

@Component({})
export class EfficientComponent {
  users = signal<User[]>([]);

  addUser(user: User) {
    // ✅ Only update if user is actually new
    if (this.users().find(u => u.id === user.id)) return;
    this.users.update(users => [...users, user]);
  }

  updateUser(id: string, updates: Partial<User>) {
    // ✅ Only update if user exists and changes
    this.users.update(users => {
      const index = users.findIndex(u => u.id === id);
      if (index === -1) return users; // No change

      const updatedUser = { ...users[index], ...updates };
      if (JSON.stringify(updatedUser) === JSON.stringify(users[index])) {
        return users; // No actual change
      }

      const newUsers = [...users];
      newUsers[index] = updatedUser;
      return newUsers;
    });
  }
}

Bonus Mistake #7: Not Using Computed Signals for Derived State

The Problem: Manually managing derived state instead of letting Angular handle it.

@Component({})
export class ManualComponent {
  firstName = signal('');
  lastName = signal('');
  fullName = signal(''); // ❌ Manual management

  updateFirstName(name: string) {
    this.firstName.set(name);
    this.fullName.set(`${name} ${this.lastName()}`); // ❌ Manual sync
  }

  updateLastName(name: string) {
    this.lastName.set(name);
    this.fullName.set(`${this.firstName()} ${name}`); // ❌ Manual sync
  }
}

The reactive approach:

@Component({})
export class ReactiveComponent {
  firstName = signal('');
  lastName = signal('');

  // ✅ Automatically updates when dependencies change
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);

  updateFirstName(name: string) {
    this.firstName.set(name);
    // ✅ fullName updates automatically
  }

  updateLastName(name: string) {
    this.lastName.set(name);
    // ✅ fullName updates automatically
  }
}

👏 If this helped you avoid a potential bug, give it a clap!

The Bottom Line

Angular Signals are powerful, but they require a shift in thinking. The key is knowing when to use them, how to use them efficiently, and what to avoid.

Quick recap of the main pitfalls:

1. Not using Signals for dynamic state - Future-proof your code

2. Overusing Signals - Keep non-reactive state simple

3. Unnecessary conversions - Don't convert just to convert

4. Unanalyzed effect dependencies - Think about what you're tracking

5. Mixing async pipes with Signals - Stay consistent

6. Ignoring Signal equality - Optimize your updates

7. Manual derived state - Let computed signals do the work

What's Next?

What did you think? Which mistake surprised you the most? Have you encountered any of these in your own projects? Drop a comment below and let's discuss! 💬

Found this helpful? Hit that 👏 button - it helps other developers discover these tips and avoid the same pitfalls.

Want more Angular insights like this? Follow me for weekly deep-dives into Angular best practices, performance tips, and the latest framework updates. I also send out a newsletter with exclusive content and early access to new articles. 📬

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠🚀

✨ Share Your Thoughts To 📣 Set Your Notification Preference

Have you ever wondered why some Angular applications load lightning-fast while others feel sluggish and unresponsive?

The secret lies in mastering three fundamental Angular concepts that separate amateur developers from seasoned professionals: Lazy Loading, Route Guards, and Resolvers. These aren’t just fancy terms thrown around in Angular documentation — they’re your weapons against slow load times, security vulnerabilities, and poor user experience.

Picture this: You’ve built an amazing Angular application with dozens of features, but users are abandoning it before it even loads. Sound familiar? You’re not alone. According to recent studies, 53% of users abandon mobile sites that take longer than 3 seconds to load. That’s where smart routing strategies come into play.

By the end of this comprehensive guide, you’ll master:

• Advanced lazy loading techniques that cut initial bundle size by up to 70%

• Bulletproof route guards that secure your application like Fort Knox

• Data resolvers that eliminate loading spinners and improve UX

• Performance optimization strategies used by top-tier Angular developers

• Real-world implementation examples you can use immediately

Ready to transform your Angular skills from good to exceptional? Let’s dive deep into the Angular routing maze and emerge as navigation masters.

1. Smart Lazy Loading: Load Only What You Need

Lazy loading is like having a smart waiter who only brings you the course you’re ready to eat, not the entire menu at once.

The Problem Traditional Loading Creates

// Traditional eager loading loads EVERYTHING upfront
const routes: Routes = [
  { path: 'dashboard', component: DashboardComponent },
  { path: 'users', component: UsersComponent },
  { path: 'products', component: ProductsComponent },
  { path: 'analytics', component: AnalyticsComponent },
  // All components loaded immediately = SLOW
];

The Lazy Loading Solution

// Smart lazy loading - Load modules on demand
const routes: Routes = [
  {
    path: 'dashboard',
    loadChildren: () => import('./dashboard/dashboard.module').then(m => m.DashboardModule)
  },
  {
    path: 'users',
    loadChildren: () => import('./users/users.module').then(m => m.UsersModule)
  },
  {
    path: 'products',
    loadChildren: () => import('./products/products.module').then(m => m.ProductsModule)
  }
];

Pro Tip: Feature Module Structure

// users-routing.module.ts
const routes: Routes = [
  {
    path: '',
    component: UsersComponent,
    children: [
      {
        path: 'profile/:id',
        loadChildren: () => import('./profile/profile.module').then(m => m.ProfileModule)
      },
      {
        path: 'settings',
        loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule)
      }
    ]
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class UsersRoutingModule { }

Impact: This approach can reduce your initial bundle size by 50–70%, dramatically improving first-page load times.

2. Route Guards: Your Application’s Security Checkpoint

Think of route guards as bouncer at an exclusive club — they decide who gets in and who doesn’t.

CanActivate: The Gatekeeper

// auth.guard.ts
@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {
  constructor(
    private authService: AuthService,
    private router: Router,
    private snackBar: MatSnackBar
  ) {}

  canActivate(
      route: ActivatedRouteSnapshot,
      state: RouterStateSnapshot
    ): Observable<boolean> | Promise<boolean> | boolean {
      if (this.authService.isAuthenticated()) {
        return true;
      }
      // Store the attempted URL for redirecting after login
      this.authService.setRedirectUrl(state.url);
      this.snackBar.open('Please log in to access this page', 'Close', {
        duration: 3000,
        panelClass: ['warning-snackbar']
      });
      this.router.navigate(['/login']);
      return false;
    }
  }

CanActivateChild: Protecting Child Routes

@Injectable({
  providedIn: 'root'
})
export class AdminGuard implements CanActivateChild {
  constructor(private userService: UserService) {}
  canActivateChild(
    childRoute: ActivatedRouteSnapshot,
    state: RouterStateSnapshot
  ): boolean {
    const userRole = this.userService.getCurrentUserRole();
    const requiredRole = childRoute.data['requiredRole'];
    if (userRole === 'admin' || userRole === requiredRole) {
      return true;
    }
    console.warn(`Access denied. Required role: ${requiredRole}, User role: ${userRole}`);
    return false;
  }
}

CanDeactivate: Preventing Data Loss

// unsaved-changes.guard.ts
export interface CanComponentDeactivate {
  canDeactivate: () => Observable<boolean> | Promise<boolean> | boolean;
}

@Injectable({
  providedIn: 'root'
})
export class UnsavedChangesGuard implements CanDeactivate<CanComponentDeactivate> {
  canDeactivate(
    component: CanComponentDeactivate,
    currentRoute: ActivatedRouteSnapshot,
    currentState: RouterStateSnapshot,
    nextState?: RouterStateSnapshot
  ): Observable<boolean> | Promise<boolean> | boolean {
    return component.canDeactivate ? component.canDeactivate() : true;
  }
}
// Implementation in component
export class UserFormComponent implements CanComponentDeactivate {
  hasUnsavedChanges = false;
  canDeactivate(): Observable<boolean> | Promise<boolean> | boolean {
    if (this.hasUnsavedChanges) {
      return confirm('You have unsaved changes. Are you sure you want to leave?');
    }
    return true;
  }
}

3. Resolvers: Pre-load Data Like a Pro

Resolvers are like personal assistants who fetch everything you need before you even ask.

Basic Data Resolver

// user-resolver.service.ts
@Injectable({
  providedIn: 'root'
})
export class UserResolver implements Resolve<User> {
  constructor(
    private userService: UserService,
    private router: Router
  ) {}

  resolve(
    route: ActivatedRouteSnapshot,
    state: RouterStateSnapshot
  ): Observable<User> | Promise<User> | User {
    const userId = route.paramMap.get('id');
    if (!userId) {
      this.router.navigate(['/users']);
      return null;
    }
    return this.userService.getUserById(userId).pipe(
      catchError(error => {
        console.error('Error loading user:', error);
        this.router.navigate(['/users']);
        return EMPTY;
      })
    );
  }
}

Advanced Multi-Data Resolver

// dashboard-resolver.service.ts
interface DashboardData {
  user: User;
  stats: DashboardStats;
  notifications: Notification[];
}

@Injectable({
  providedIn: 'root'
})
export class DashboardResolver implements Resolve<DashboardData> {
  constructor(
    private userService: UserService,
    private statsService: StatsService,
    private notificationService: NotificationService
  ) {}
  resolve(): Observable<DashboardData> {
    return forkJoin({
      user: this.userService.getCurrentUser(),
      stats: this.statsService.getDashboardStats(),
      notifications: this.notificationService.getRecentNotifications()
    }).pipe(
      catchError(error => {
        console.error('Error loading dashboard data:', error);
        return of({
          user: null,
          stats: null,
          notifications: []
        });
      })
    );
  }
}

4. Advanced Route Configuration Patterns

Combining Guards and Resolvers

const routes: Routes = [
  {
    path: 'admin',
    canActivate: [AuthGuard, AdminGuard],
    canActivateChild: [AdminGuard],
    children: [
      {
        path: 'dashboard',
        component: AdminDashboardComponent,
        resolve: {
          dashboardData: DashboardResolver
        },
        data: { requiredRole: 'admin' }
      },
      {
        path: 'users/:id',
        component: UserDetailComponent,
        canDeactivate: [UnsavedChangesGuard],
        resolve: {
          user: UserResolver
        }
      }
    ]
  }
];

Dynamic Route Parameters with Resolvers

@Injectable({
  providedIn: 'root'
})
export class ProductResolver implements Resolve<Product> {
  constructor(private productService: ProductService) {}

  resolve(route: ActivatedRouteSnapshot): Observable<Product> {
    const productId = route.paramMap.get('id');
    const category = route.paramMap.get('category');
    return this.productService.getProduct(productId, category).pipe(
      map(product => {
        // Add dynamic data based on route params
        return {
          ...product,
          breadcrumb: this.generateBreadcrumb(category, product.name)
        };
      })
    );
  }
  private generateBreadcrumb(category: string, productName: string): string[] {
    return ['Home', 'Products', category, productName];
  }
}

5. Performance-First Loading Strategies

Preloading Strategies

// custom-preloading.strategy.ts
@Injectable({
  providedIn: 'root'
})
export class CustomPreloadingStrategy implements PreloadingStrategy {
  preload(route: Route, load: () => Observable<any>): Observable<any> {
    // Only preload routes marked with preload: true
    if (route.data && route.data['preload']) {
      console.log('Preloading: ' + route.path);
      return load();
    }
    return of(null);
  }
}

// app-routing.module.ts
const routes: Routes = [
  {
    path: 'dashboard',
    loadChildren: () => import('./dashboard/dashboard.module').then(m => m.DashboardModule),
    data: { preload: true } // This will be preloaded
  },
  {
    path: 'archive',
    loadChildren: () => import('./archive/archive.module').then(m => m.ArchiveModule)
    // This won't be preloaded
  }
];
@NgModule({
  imports: [RouterModule.forRoot(routes, {
    preloadingStrategy: CustomPreloadingStrategy
  })],
  exports: [RouterModule]
})
export class AppRoutingModule { }

6. Advanced Security Patterns

Role-Based Access Control

// rbac.guard.ts
@Injectable({
  providedIn: 'root'
})
export class RbacGuard implements CanActivate {
  constructor(private authService: AuthService) {}

  canActivate(route: ActivatedRouteSnapshot): boolean {
    const requiredPermissions = route.data['permissions'] as string[];
    const userPermissions = this.authService.getUserPermissions();
    return requiredPermissions.every(permission =>
      userPermissions.includes(permission)
    );
  }
}
// Usage in routes
{
  path: 'sensitive-data',
  component: SensitiveDataComponent,
  canActivate: [AuthGuard, RbacGuard],
  data: {
    permissions: ['read:sensitive_data', 'access:admin_panel']
  }
}

JWT Token Validation Guard

@Injectable({
  providedIn: 'root'
})
export class TokenValidationGuard implements CanActivate {
  constructor(
    private authService: AuthService,
    private router: Router
  ) {}

    canActivate(): Observable<boolean> {
    return this.authService.validateToken().pipe(
      map(isValid => {
        if (!isValid) {
          this.authService.logout();
          this.router.navigate(['/login']);
          return false;
        }
        return true;
      }),
      catchError(() => {
        this.router.navigate(['/login']);
        return of(false);
      })
    );
  }
}

7. Error Handling and User Experience

Graceful Error Handling in Resolvers

@Injectable({
  providedIn: 'root'
})
export class ErrorHandlingResolver implements Resolve<any> {
  constructor(
    private dataService: DataService,
    private errorHandler: ErrorHandlerService,
    private loadingService: LoadingService
  ) {}

  resolve(route: ActivatedRouteSnapshot): Observable<any> {
    this.loadingService.show();
    return this.dataService.getData(route.params['id']).pipe(
      finalize(() => this.loadingService.hide()),
      catchError(error => {
        this.errorHandler.handleError(error);
        // Return fallback data instead of breaking the route
        return of({
          id: route.params['id'],
          name: 'Data Unavailable',
          error: true
        });
      })
    );
  }
}

Loading States with Resolvers

// Component implementation
export class DataComponent implements OnInit {
  data: any;
  isLoading = true;
  hasError = false;

  constructor(private route: ActivatedRoute) {}
  ngOnInit() {
    this.route.data.subscribe(({ resolvedData }) => {
      this.data = resolvedData;
      this.hasError = resolvedData?.error || false;
      this.isLoading = false;
    });
  }
}

8. User Experience Enhancements

Route Transition Animations

// route-animations.ts
export const routeAnimations = trigger('routeAnimations', [
  transition('* <=> *', [
    style({ position: 'relative' }),
    query(':enter, :leave', [
      style({
        position: 'absolute',
        top: 0,
        left: 0,
        width: '100%'
      })
    ], { optional: true }),
    query(':enter', [
      style({ transform: 'translateX(100%)' })
    ], { optional: true }),
    query(':leave', animateChild(), { optional: true }),
    group([
      query(':leave', [
        animate('200ms ease-out', style({ transform: 'translateX(-100%)' }))
      ], { optional: true }),
      query(':enter', [
        animate('200ms ease-out', style({ transform: 'translateX(0%)' }))
      ], { optional: true })
    ]),
    query(':enter', animateChild(), { optional: true }),
  ])
]);

Smart Progress Indicators

// progress-interceptor.service.ts
@Injectable()
export class ProgressInterceptor implements HttpInterceptor {
  constructor(private progressService: ProgressService) {}

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    // Show progress only for resolver requests
    if (req.context.get(IS_RESOLVER_REQUEST)) {
      this.progressService.show();
    }
    return next.handle(req).pipe(
      finalize(() => {
        if (req.context.get(IS_RESOLVER_REQUEST)) {
          this.progressService.hide();
        }
      })
    );
  }
}

9. Testing Your Navigation Logic

Testing Route Guards

// auth.guard.spec.ts
describe('AuthGuard', () => {
  let guard: AuthGuard;
  let authService: jasmine.SpyObj<AuthService>;
  let router: jasmine.SpyObj<Router>;

  beforeEach(() => {
    const authSpy = jasmine.createSpyObj('AuthService', ['isAuthenticated']);
    const routerSpy = jasmine.createSpyObj('Router', ['navigate']);
    TestBed.configureTestingModule({
      providers: [
        { provide: AuthService, useValue: authSpy },
        { provide: Router, useValue: routerSpy }
      ]
    });
    guard = TestBed.inject(AuthGuard);
    authService = TestBed.inject(AuthService) as jasmine.SpyObj<AuthService>;
    router = TestBed.inject(Router) as jasmine.SpyObj<Router>;
  });
  it('should allow access when user is authenticated', () => {
    authService.isAuthenticated.and.returnValue(true);
    expect(guard.canActivate({} as any, {} as any)).toBe(true);
  });
  it('should redirect to login when user is not authenticated', () => {
    authService.isAuthenticated.and.returnValue(false);
    expect(guard.canActivate({} as any, { url: '/dashboard' } as any)).toBe(false);
    expect(router.navigate).toHaveBeenCalledWith(['/login']);
  });
});

Testing Resolvers

// user-resolver.spec.ts
describe('UserResolver', () => {
  let resolver: UserResolver;
  let userService: jasmine.SpyObj<UserService>;

  beforeEach(() => {
    const userSpy = jasmine.createSpyObj('UserService', ['getUserById']);
    TestBed.configureTestingModule({
      providers: [
        { provide: UserService, useValue: userSpy }
      ]
    });
    resolver = TestBed.inject(UserResolver);
    userService = TestBed.inject(UserService) as jasmine.SpyObj<UserService>;
  });
  it('should resolve user data', () => {
    const mockUser = { id: '1', name: 'John Doe' };
    userService.getUserById.and.returnValue(of(mockUser));
    const route = { paramMap: { get: () => '1' } } as any;
    resolver.resolve(route, {} as any).subscribe(user => {
      expect(user).toEqual(mockUser);
    });
  });
});

10. Production-Ready Optimization Tips

Bundle Analysis and Code Splitting

# Analyze your bundle size
ng build --stats-json
npx webpack-bundle-analyzer dist/stats.json

# Optimize for production
ng build --prod --build-optimizer --vendor-chunk --common-chunk

Performance Monitoring

// performance-monitor.service.ts
@Injectable({
  providedIn: 'root'
})
export class PerformanceMonitorService {
  constructor(private analytics: AnalyticsService) {}

  measureRouteLoad(routeName: string) {
    const startTime = performance.now();
    return () => {
      const endTime = performance.now();
      const loadTime = endTime - startTime;
      this.analytics.track('route_load_time', {
        route: routeName,
        loadTime: loadTime,
        timestamp: new Date().toISOString()
      });
      if (loadTime > 2000) {
        console.warn(`Slow route detected: ${routeName} took ${loadTime}ms`);
      }
    };
  }
}

🎯 Key Takeaways

Mastering Angular’s lazy loading, route guards, and resolvers isn’t just about writing code — it’s about crafting exceptional user experiences. Here’s what separates the pros from the beginners:

1. Lazy Loading reduces initial bundle size by 50–70%

2. Route Guards provide bulletproof security and user flow control

3. Resolvers eliminate loading spinners and improve perceived performance

4. Smart preloading strategies balance performance with user experience

5. Proper error handling prevents broken user journeys

6. Testing ensures your navigation logic works flawlessly

7. Performance monitoring helps you optimize continuously

The developers who implement these patterns see dramatic improvements in Core Web Vitals, user engagement, and overall application performance.

💡 What’s Your Experience?

Have you implemented any of these patterns in your Angular applications? What challenges did you face, and how did you overcome them?

Drop a comment below and share:

• Your favorite optimization technique

• Any unique use cases you’ve encountered

• Questions about implementing these patterns

Your insights could help fellow developers navigate their own Angular challenges!

🔥 Ready for More Angular Mastery?

If this deep dive into Angular routing helped level up your skills, you’ll love my upcoming content on:

• Advanced RxJS patterns for Angular developers

• State management strategies that scale

• Performance optimization secrets from production apps

• Angular testing strategies that actually work

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks!

✨ Share Your Thoughts To 📣 Set Your Notification Preference

If you’ve been working with Angular’s dynamic components using ComponentFactory or ViewContainerRef, you know the pain of verbose code, complex event handling, and the constant worry about memory leaks. Well, Angular 20 just dropped some absolute game-changers that will make you rethink how you approach dynamic components entirely.

What you’ll learn by the end of this article:

• How to use Angular 20’s new inputBinding(), outputBinding(), and twoWayBinding() APIs

• Best practices for memory management and cleanup

• Complete unit testing strategies

• Performance optimization techniques

• Real-world implementation examples with clean, maintainable code

Ready to level up your Angular game? Let’s dive in!

The Old Way vs. The New Way: A Quick Reality Check

Before we jump into the good stuff, let’s be honest about what we used to deal with:

// The old, painful way 
const componentRef = this.viewContainer.createComponent(MyComponent);
componentRef.instance.someInput = 'value';
componentRef.instance.someOutput.subscribe(data => {
  // Handle output
});

// Don't forget cleanup... if you remember 
ngOnDestroy() {
  // Manual subscription cleanup
}

Sound familiar? We’ve all been there — wrestling with subscriptions, forgetting cleanup, and ending up with memory leaks that haunt our apps.

💬 Quick question for you: How many times have you forgotten to unsubscribe from dynamic component outputs? Be honest in the comments!

Meet the New Heroes: inputBinding(), outputBinding(), and twoWayBinding()

Angular 20 introduces three powerful methods that transform how we work with dynamic components. Let’s break them down:

1. inputBinding() — Clean Input Handling

import { Component, ViewContainerRef, inject } from '@angular/core';
import { inputBinding } from '@angular/core';

@Component({
  selector: 'app-dynamic-host',
  template: `<div #dynamicContainer></div>`
})
export class DynamicHostComponent {
  private viewContainer = inject(ViewContainerRef);
  addDynamicComponent() {
    const componentRef = this.viewContainer.createComponent(UserCardComponent);
    // New way - Clean and type-safe!
    inputBinding(componentRef, 'userName', 'John Doe');
    inputBinding(componentRef, 'isActive', true);
    inputBinding(componentRef, 'userData', { id: 1, email: 'john@example.com' });
  }
}

2. outputBinding() — Effortless Event Handling

addDynamicComponentWithEvents() {
  const componentRef = this.viewContainer.createComponent(UserCardComponent);

// Set inputs
  inputBinding(componentRef, 'userName', 'Jane Smith');
  // Handle outputs the new way
  outputBinding(componentRef, 'userClicked', (userData) => {
    console.log('User clicked:', userData);
    this.handleUserSelection(userData);
  });
  outputBinding(componentRef, 'deleteRequested', (userId) => {
    this.confirmDelete(userId);
  });
}

3. twoWayBinding() — The Holy Grail

This is where it gets really exciting. Two-way binding with dynamic components used to be a nightmare. Not anymore:

setupTwoWayBinding() {
  const componentRef = this.viewContainer.createComponent(EditableCardComponent);
  // Two-way binding made simple
  twoWayBinding(componentRef, 'value',
    // Initial value
    this.currentValue,
    // Callback when value changes
    (newValue) => {
      this.currentValue = newValue;
      this.onValueChanged(newValue);
    }
  );
}

Pretty clean, right?

Real-World Example: Dynamic Dashboard Widgets

Let’s build something practical — a dashboard that can dynamically add different widget types:

@Component({
  selector: 'app-dashboard',
  template: `
    <div class="dashboard-header">
      <h2>My Dashboard</h2>
      <button (click)="addWidget('chart')" class="btn-primary">Add Chart</button>
      <button (click)="addWidget('table')" class="btn-primary">Add Table</button>
      <button (click)="addWidget('counter')" class="btn-primary">Add Counter</button>
    </div>
    <div class="widgets-container" #widgetContainer></div>
  `,
  styles: [`
    .widgets-container {
      display: grid;
      grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
      gap: 1rem;
      padding: 1rem;
    }
  `]
})
export class DashboardComponent implements OnDestroy {
  private viewContainer = inject(ViewContainerRef);
  private activeComponents: ComponentRef<any>[] = [];
  private subscriptions = new Set<() => void>();
  addWidget(type: 'chart' | 'table' | 'counter') {
    let componentRef: ComponentRef<any>;
    switch (type) {
      case 'chart':
        componentRef = this.createChartWidget();
        break;
      case 'table':
        componentRef = this.createTableWidget();
        break;
      case 'counter':
        componentRef = this.createCounterWidget();
        break;
    }
    this.activeComponents.push(componentRef);
  }
  private createChartWidget() {
    const componentRef = this.viewContainer.createComponent(ChartWidgetComponent);
    // Set initial data
    inputBinding(componentRef, 'title', 'Sales Chart');
    inputBinding(componentRef, 'data', this.generateChartData());
    inputBinding(componentRef, 'chartType', 'line');
    // Handle widget events
    const unsubscribe1 = outputBinding(componentRef, 'refreshRequested', () => {
      inputBinding(componentRef, 'data', this.generateChartData());
    });
    const unsubscribe2 = outputBinding(componentRef, 'deleteRequested', () => {
      this.removeWidget(componentRef);
    });
    // Store cleanup functions
    this.subscriptions.add(unsubscribe1);
    this.subscriptions.add(unsubscribe2);
    return componentRef;
  }
  private createCounterWidget() {
    const componentRef = this.viewContainer.createComponent(CounterWidgetComponent);
    // Two-way binding for counter value
    const unsubscribe = twoWayBinding(componentRef, 'count',
      0, // initial value
      (newCount) => {
        // Sync with parent state or save to backend
        this.saveWidgetState(componentRef.instance.id, { count: newCount });
      }
    );
    this.subscriptions.add(unsubscribe);
    return componentRef;
  }
  private removeWidget(componentRef: ComponentRef<any>) {
    const index = this.activeComponents.indexOf(componentRef);
    if (index > -1) {
      this.activeComponents.splice(index, 1);
      componentRef.destroy();
    }
  }
  ngOnDestroy() {
    // Clean shutdown - no memory leaks!
    this.subscriptions.forEach(unsubscribe => unsubscribe());
    this.subscriptions.clear();
    this.activeComponents.forEach(ref => ref.destroy());
    this.activeComponents.length = 0;
  }
}

Pro tip: Notice how we’re storing unsubscribe functions and cleaning them up properly? This is crucial for preventing memory leaks!

Unit Testing Your Dynamic Components

Testing dynamic components can be tricky, but Angular 20’s new APIs make it much more straightforward:

describe('DashboardComponent', () => {
  let component: DashboardComponent;
  let fixture: ComponentFixture<DashboardComponent>;
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [DashboardComponent, ChartWidgetComponent, CounterWidgetComponent],
      imports: [CommonModule]
    }).compileComponents();
    fixture = TestBed.createComponent(DashboardComponent);
    component = fixture.componentInstance;
  });
  describe('Dynamic Widget Creation', () => {
    it('should create chart widget with correct inputs', () => {
      // Act
      component.addWidget('chart');
      fixture.detectChanges();
      // Assert
      const chartComponent = fixture.debugElement.query(
        By.directive(ChartWidgetComponent)
      );
      expect(chartComponent).toBeTruthy();
      expect(chartComponent.componentInstance.title).toBe('Sales Chart');
      expect(chartComponent.componentInstance.chartType).toBe('line');
    });
    it('should handle widget events correctly', fakeAsync(() => {
      // Arrange
      spyOn(component, 'removeWidget');
      // Act
      component.addWidget('chart');
      fixture.detectChanges();
      const chartComponent = fixture.debugElement.query(
        By.directive(ChartWidgetComponent)
      );
      // Simulate delete event
      chartComponent.componentInstance.deleteRequested.emit();
      tick();
      // Assert
      expect(component.removeWidget).toHaveBeenCalled();
    }));
    it('should handle two-way binding for counter widget', fakeAsync(() => {
      // Arrange
      spyOn(component, 'saveWidgetState');
      // Act
      component.addWidget('counter');
      fixture.detectChanges();
      const counterComponent = fixture.debugElement.query(
        By.directive(CounterWidgetComponent)
      );
      // Simulate count change
      counterComponent.componentInstance.count = 5;
      counterComponent.componentInstance.countChange.emit(5);
      tick();
      // Assert
      expect(component.saveWidgetState).toHaveBeenCalledWith(
        jasmine.any(String),
        { count: 5 }
      );
    }));
  });
  describe('Memory Management', () => {
    it('should clean up subscriptions on destroy', () => {
      // Arrange
      component.addWidget('chart');
      component.addWidget('counter');
      const subscriptionCount = (component as any).subscriptions.size;
      expect(subscriptionCount).toBeGreaterThan(0);
      // Act
      component.ngOnDestroy();
      // Assert
      expect((component as any).subscriptions.size).toBe(0);
      expect((component as any).activeComponents.length).toBe(0);
    });
  });
});

Testing tip: Always test both the happy path and the cleanup! Memory leaks in tests can be just as problematic as in production.

Best Practices & Memory Management

1. Always Clean Up Your Subscriptions

export class DynamicComponentManager implements OnDestroy {
  private cleanup: (() => void)[] = [];
  addComponent() {
    const componentRef = this.createComponent();
    // Store cleanup function
    const unsubscribe = outputBinding(componentRef, 'someEvent', this.handleEvent);
    this.cleanup.push(unsubscribe);
  }
  ngOnDestroy() {
    // Execute all cleanup functions
    this.cleanup.forEach(fn => fn());
    this.cleanup.length = 0;
  }
}

2. Use WeakMap for Component Metadata

export class AdvancedDynamicManager {
  private componentMetadata = new WeakMap<ComponentRef<any>, ComponentMetaData>();
  addComponent() {
    const componentRef = this.createComponent();
    // Store metadata that gets garbage collected with the component
    this.componentMetadata.set(componentRef, {
      createdAt: Date.now(),
      type: 'chart',
      subscriptions: []
    });
  }
}

3. Implement Change Detection Optimization

export class OptimizedDynamicHost {
  addComponent() {
    const componentRef = this.viewContainer.createComponent(MyComponent);
    // Optimize change detection
    componentRef.changeDetectorRef.detach();
    inputBinding(componentRef, 'data', this.data);
    // Manually trigger when needed
    componentRef.changeDetectorRef.detectChanges();
  }
}

4. Monitor Performance with Angular DevTools

export class PerformanceAwareDynamic {
  private performanceMetrics = new Map<string, number>();
  addComponent(type: string) {
    const startTime = performance.now();
    const componentRef = this.createComponent(type);
    const endTime = performance.now();
    this.performanceMetrics.set(type, endTime - startTime);
    // Log slow component creation
    if (endTime - startTime > 100) {
      console.warn(`Slow component creation for ${type}: ${endTime - startTime}ms`);
    }
  }
}

Quick question: Are you currently monitoring your dynamic component performance? Drop a comment and let me know what tools you use! 💬

Bonus Tips

1. Type Safety with Generics

function createTypedComponent<T>(
  viewContainer: ViewContainerRef,
  componentType: Type<T>,
  inputs: Partial<T> = {}
): ComponentRef<T> {
  const componentRef = viewContainer.createComponent(componentType);

Object.entries(inputs).forEach(([key, value]) => {
    inputBinding(componentRef, key as keyof T, value);
  });
  return componentRef;
}
// Usage with full type safety
const chartRef = createTypedComponent(this.viewContainer, ChartComponent, {
  title: 'My Chart',
  data: chartData,
  showLegend: true
});

2. Component Factory Service

@Injectable({
  providedIn: 'root'
})
export class DynamicComponentFactory {
  private registry = new Map<string, Type<any>>();
  registerComponent(name: string, component: Type<any>) {
    this.registry.set(name, component);
  }
  createComponent(name: string, viewContainer: ViewContainerRef) {
    const componentType = this.registry.get(name);
    if (!componentType) {
      throw new Error(`Component '${name}' not registered`);
    }
    return viewContainer.createComponent(componentType);
  }
}

3. Error Boundary for Dynamic Components

export class SafeDynamicHost {
  addComponentSafely(componentType: Type<any>) {
    try {
      const componentRef = this.viewContainer.createComponent(componentType);
      // Wrap in error handling
      const originalNgOnInit = componentRef.instance.ngOnInit;
      componentRef.instance.ngOnInit = () => {
        try {
          originalNgOnInit?.call(componentRef.instance);
        } catch (error) {
          console.error('Dynamic component initialization failed:', error);
          this.handleComponentError(componentRef, error);
        }
      };
      return componentRef;
    } catch (error) {
      console.error('Failed to create dynamic component:', error);
      return null;
    }
  }
}

Recap: Your Dynamic Component Toolkit

Let’s wrap up what we’ve covered:

Key Angular 20 Features:

• inputBinding() - Clean, type-safe input handling

• outputBinding() - Simplified event subscription with automatic cleanup options

• twoWayBinding() - Effortless two-way data binding for dynamic components

Best Practices Checklist:

• ✅ Always clean up subscriptions in ngOnDestroy

• ✅ Use WeakMap for component metadata

• ✅ Monitor performance of dynamic component creation

• ✅ Implement error boundaries for robust apps

• ✅ Leverage TypeScript generics for type safety

• ✅ Test both functionality and memory management

Memory Management Essentials:

• Store cleanup functions and execute them on destroy

• Use ChangeDetectorRef.detach() for performance optimization

• Monitor component lifecycle with Angular DevTools

• Implement proper error handling to prevent memory leaks

Your Turn!

💬 What did you think? Have you already started experimenting with Angular 20’s dynamic component features? I’d love to hear about your experience! Drop a comment below and share:

• What’s your biggest pain point with dynamic components?

• Have you tried these new APIs yet?

• What other Angular 20 features are you excited about?

Found this helpful? If this article saved you some debugging time or sparked new ideas, smash that clap button! It helps other developers discover these game-changing features too.

Want more Angular insights like this? I share practical Angular tips, advanced techniques, and the latest framework updates every week. Follow me here on Medium and never miss out on the good stuff!

Take Action:

1. Try implementing one of these examples in your current project

2. Refactor an existing dynamic component using the new APIs

3. Share this article with your team — they’ll thank you later!

4. Star the GitHub repository with the complete examples (link in my bio)

Keep coding, keep learning, and remember — the best way to master these features is to get your hands dirty with code!

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference