Forem: Rajat

Stop, Prevent, Control: Master JavaScript Event Methods Like a Pro

Rajat — Wed, 08 Apr 2026 13:30:00 +0000

The essential guide to event.stopPropagation(), event.preventDefault(), event.defaultPrevented, and event.stopImmediatePropagation() with real-world Angular examples

Have you ever clicked a button inside a card component, only to have both the button action AND the card click event fire at the same time? Or struggled with form submissions that won't behave the way you want?

If you've been there, you're not alone. Event handling in JavaScript (and Angular) can feel like trying to control a room full of excited puppies—everything happens at once, and you're not sure who's listening to what!

By the end of this article, you'll know exactly when and how to use stopPropagation(), preventDefault(), defaultPrevented, and stopImmediatePropagation() to take complete control of your events. Plus, I'll show you real Angular examples and how to test them properly.

Before we dive into the examples, a quick note: the code snippets provided here use syntax from earlier Angular versions. If you're working with Angular 20 or newer, you'll want to adjust these patterns - for instance, by adding ngModelOptions or using stricter type annotations. I'll point out these updates where relevant so you can transition smoothly.

Quick question: What's the most frustrating event behavior you've dealt with lately? Drop it in the comments—I bet others have faced the same thing!

The Event Propagation Playground

Before we dive into the methods, let's understand what we're working with. Every DOM event goes through three phases:

Capture Phase - Event travels down from document to target
Target Phase - Event reaches the actual element
Bubble Phase - Event bubbles back up to document

Think of it like dropping a stone in water—the ripples go out (bubble up) from where it hits.

1. event.stopPropagation() - "Stop the Ripples"

When to use: When you want to prevent an event from bubbling up to parent elements.

Real-World Angular Example: Card with Clickable Button

// card.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-product-card',
  template: `
    <div class="card" (click)="onCardClick()">
      <h3>{{product.name}}</h3>
      <p>{{product.description}}</p>
      <button
        class="btn-primary"
        (click)="onAddToCart($event)">
        Add to Cart
      </button>
    </div>
  `,
  styles: [`
    .card {
      border: 1px solid #ddd;
      padding: 16px;
      cursor: pointer;
      border-radius: 8px;
    }
    .btn-primary {
      background: #007bff;
      color: white;
      border: none;
      padding: 8px 16px;
      border-radius: 4px;
      cursor: pointer;
    }
  `]
})
export class ProductCardComponent {
  product = {
    name: 'Awesome Widget',
    description: 'The best widget you\'ll ever use!'
  };

  onCardClick() {
    console.log('Card clicked - navigating to details');
    // Navigate to product details
  }

  onAddToCart(event: Event) {
    event.stopPropagation(); //  This is the magic!
    console.log('Added to cart');
    // Add product to cart logic
  }
}

Without stopPropagation(): Click button → Both "Added to cart" AND "Card clicked" fire
With stopPropagation(): Click button → Only "Added to cart" fires

Unit Test for stopPropagation()

// card.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { ProductCardComponent } from './card.component';

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

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

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

  it('should stop propagation when add to cart button is clicked', () => {
    spyOn(component, 'onCardClick');
    spyOn(component, 'onAddToCart').and.callThrough();

    const button = fixture.debugElement.nativeElement.querySelector('.btn-primary');
    button.click();

    expect(component.onAddToCart).toHaveBeenCalled();
    expect(component.onCardClick).not.toHaveBeenCalled();
  });

  it('should trigger card click when clicking on card area', () => {
    spyOn(component, 'onCardClick');

    const card = fixture.debugElement.nativeElement.querySelector('.card');
    card.click();

    expect(component.onCardClick).toHaveBeenCalled();
  });
});

If this already saved you some debugging time, give it a clap so others can find it too!

2. event.preventDefault() - "Not So Fast, Browser!"

When to use: When you want to prevent the browser's default behavior for an event.

Real-World Angular Example: Custom Form Validation

// custom-form.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-custom-form',
  template: `
    <form (submit)="onSubmit($event)">
      <div class="form-group">
        <label for="email">Email:</label>
        <input
          id="email"
          type="email"
          [(ngModel)]="email"
          name="email"
          class="form-control">
      </div>

      <div class="form-group">
        <label for="password">Password:</label>
        <input
          id="password"
          type="password"
          [(ngModel)]="password"
          name="password"
          class="form-control">
      </div>

      <button type="submit" class="btn-submit">
        {{isLoading ? 'Submitting...' : 'Login'}}
      </button>

      <!-- Custom file upload -->
      <div class="file-drop-zone"
           (dragover)="onDragOver($event)"
           (drop)="onFileDrop($event)">
        Drop files here or click to upload
      </div>
    </form>
  `,
  styles: [`
    .form-group {
      margin-bottom: 16px;
    }
    .form-control {
      width: 100%;
      padding: 8px;
      border: 1px solid #ddd;
      border-radius: 4px;
    }
    .file-drop-zone {
      border: 2px dashed #ccc;
      padding: 20px;
      text-align: center;
      margin-top: 16px;
      border-radius: 4px;
    }
    .file-drop-zone.drag-over {
      border-color: #007bff;
      background-color: #f8f9fa;
    }
  `]
})
export class CustomFormComponent {
  email = '';
  password = '';
  isLoading = false;

  onSubmit(event: Event) {
    event.preventDefault(); //  Stop the default form submission!

    if (this.validateForm()) {
      this.isLoading = true;
      this.submitForm();
    }
  }

  onDragOver(event: DragEvent) {
    event.preventDefault(); //  Allow drop by preventing default
    event.currentTarget?.classList.add('drag-over');
  }

  onFileDrop(event: DragEvent) {
    event.preventDefault(); //  Prevent browser from opening the file
    event.currentTarget?.classList.remove('drag-over');

    const files = event.dataTransfer?.files;
    if (files) {
      this.handleFiles(files);
    }
  }

  private validateForm(): boolean {
    // Custom validation logic
    return this.email.includes('@') && this.password.length >= 6;
  }

  private submitForm() {
    // Custom AJAX submission
    console.log('Submitting form with custom logic');
    // Simulate API call
    setTimeout(() => {
      this.isLoading = false;
      console.log('Form submitted successfully');
    }, 2000);
  }

  private handleFiles(files: FileList) {
    console.log('Files dropped:', files);
    // Handle file upload logic
  }
}

Unit Tests for preventDefault()

// custom-form.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { FormsModule } from '@angular/forms';
import { CustomFormComponent } from './custom-form.component';

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

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

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

  it('should prevent default form submission', () => {
    const form = fixture.debugElement.nativeElement.querySelector('form');
    const event = new Event('submit');
    spyOn(event, 'preventDefault');
    spyOn(component, 'onSubmit').and.callThrough();

    form.dispatchEvent(event);

    expect(component.onSubmit).toHaveBeenCalled();
    expect(event.preventDefault).toHaveBeenCalled();
  });

  it('should prevent default on drag over', () => {
    const dropZone = fixture.debugElement.nativeElement.querySelector('.file-drop-zone');
    const event = new DragEvent('dragover');
    spyOn(event, 'preventDefault');

    dropZone.dispatchEvent(event);

    expect(event.preventDefault).toHaveBeenCalled();
  });

  it('should handle file drop and prevent default', () => {
    const dropZone = fixture.debugElement.nativeElement.querySelector('.file-drop-zone');
    const mockFile = new File(['content'], 'test.txt', { type: 'text/plain' });
    const event = new DragEvent('drop');

    Object.defineProperty(event, 'dataTransfer', {
      value: { files: [mockFile] }
    });

    spyOn(event, 'preventDefault');
    spyOn(component as any, 'handleFiles');

    dropZone.dispatchEvent(event);

    expect(event.preventDefault).toHaveBeenCalled();
    expect((component as any).handleFiles).toHaveBeenCalledWith([mockFile]);
  });
});

3. event.defaultPrevented - "Did Someone Already Stop This?"

When to use: When you want to check if preventDefault() has already been called on an event.

Real-World Angular Example: Conditional Event Handling

// modal.component.ts
import { Component, Output, EventEmitter } from '@angular/core';

@Component({
  selector: 'app-modal',
  template: `
    <div class="modal-overlay" (click)="onOverlayClick($event)">
      <div class="modal-content" (click)="onContentClick($event)">
        <div class="modal-header">
          <h2>Confirm Action</h2>
          <button class="close-btn" (click)="onCloseClick($event)">×</button>
        </div>
        <div class="modal-body">
          <p>Are you sure you want to delete this item?</p>
          <button class="btn-danger" (click)="onDeleteClick($event)">
            Delete
          </button>
          <button class="btn-cancel" (click)="onCancelClick($event)">
            Cancel
          </button>
        </div>
      </div>
    </div>
  `,
  styles: [`
    .modal-overlay {
      position: fixed;
      top: 0;
      left: 0;
      width: 100%;
      height: 100%;
      background: rgba(0, 0, 0, 0.5);
      display: flex;
      align-items: center;
      justify-content: center;
    }
    .modal-content {
      background: white;
      border-radius: 8px;
      max-width: 400px;
      width: 90%;
    }
    .modal-header {
      display: flex;
      justify-content: space-between;
      align-items: center;
      padding: 16px;
      border-bottom: 1px solid #eee;
    }
    .close-btn {
      background: none;
      border: none;
      font-size: 24px;
      cursor: pointer;
    }
    .modal-body {
      padding: 16px;
    }
    .btn-danger {
      background: #dc3545;
      color: white;
      border: none;
      padding: 8px 16px;
      border-radius: 4px;
      margin-right: 8px;
      cursor: pointer;
    }
    .btn-cancel {
      background: #6c757d;
      color: white;
      border: none;
      padding: 8px 16px;
      border-radius: 4px;
      cursor: pointer;
    }
  `]
})
export class ModalComponent {
  @Output() close = new EventEmitter<void>();
  @Output() delete = new EventEmitter<void>();

  onOverlayClick(event: Event) {
    //  Only close modal if no child element prevented the default
    if (!event.defaultPrevented) {
      console.log('Overlay clicked - closing modal');
      this.close.emit();
    }
  }

  onContentClick(event: Event) {
    // Prevent modal from closing when clicking inside content
    event.preventDefault();
    console.log('Content clicked - modal stays open');
  }

  onCloseClick(event: Event) {
    event.stopPropagation(); // Don't trigger overlay click
    this.close.emit();
  }

  onDeleteClick(event: Event) {
    event.stopPropagation(); // Don't trigger overlay click
    this.delete.emit();
  }

  onCancelClick(event: Event) {
    event.stopPropagation(); // Don't trigger overlay click
    this.close.emit();
  }
}

Unit Test for defaultPrevented

// modal.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { ModalComponent } from './modal.component';

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

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

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

  it('should close modal when overlay is clicked and default is not prevented', () => {
    spyOn(component.close, 'emit');

    const overlay = fixture.debugElement.nativeElement.querySelector('.modal-overlay');
    const event = new Event('click');

    overlay.dispatchEvent(event);

    expect(component.close.emit).toHaveBeenCalled();
  });

  it('should not close modal when content is clicked (default prevented)', () => {
    spyOn(component.close, 'emit');

    const content = fixture.debugElement.nativeElement.querySelector('.modal-content');
    content.click();

    expect(component.close.emit).not.toHaveBeenCalled();
  });

  it('should check defaultPrevented property correctly', () => {
    const event = new Event('click');

    expect(event.defaultPrevented).toBe(false);

    event.preventDefault();

    expect(event.defaultPrevented).toBe(true);
  });
});

Have you ever built a modal that closes when you don't want it to? How did you solve it?

4. event.stopImmediatePropagation() - "Stop Everything, Right Now!"

When to use: When you want to prevent other listeners on the same element from executing, AND prevent bubbling.

Real-World Angular Example: Priority Event Handling

// priority-button.component.ts
import { Component, OnInit, ElementRef } from '@angular/core';

@Component({
  selector: 'app-priority-button',
  template: `
    <button
      #priorityBtn
      class="priority-btn"
      [class.loading]="isLoading"
      [disabled]="isLoading">
      {{isLoading ? 'Processing...' : 'Submit Order'}}
    </button>
  `,
  styles: [`
    .priority-btn {
      background: #28a745;
      color: white;
      border: none;
      padding: 12px 24px;
      border-radius: 6px;
      cursor: pointer;
      font-size: 16px;
      transition: all 0.2s;
    }
    .priority-btn:hover {
      background: #218838;
    }
    .priority-btn.loading {
      background: #6c757d;
      cursor: not-allowed;
    }
    .priority-btn:disabled {
      opacity: 0.7;
    }
  `]
})
export class PriorityButtonComponent implements OnInit {
  isLoading = false;

  constructor(private elementRef: ElementRef) {}

  ngOnInit() {
    const button = this.elementRef.nativeElement.querySelector('.priority-btn');

    // High priority listener (added first, but will run last due to stopImmediatePropagation)
    button.addEventListener('click', this.highPriorityHandler.bind(this), true);

    // Medium priority listener
    button.addEventListener('click', this.mediumPriorityHandler.bind(this));

    // Low priority listener (this won't run when high priority triggers)
    button.addEventListener('click', this.lowPriorityHandler.bind(this));

    // Analytics listener (this won't run when high priority triggers)
    button.addEventListener('click', this.analyticsHandler.bind(this));
  }

  highPriorityHandler(event: Event) {
    if (this.isLoading) {
      console.log(' High Priority: Button is loading, stopping all other handlers');
      event.stopImmediatePropagation(); //  Stop everything!
      return;
    }

    console.log(' High Priority: Processing order');
    this.isLoading = true;

    // Simulate API call
    setTimeout(() => {
      this.isLoading = false;
      console.log('Order processed successfully');
    }, 3000);
  }

  mediumPriorityHandler(event: Event) {
    console.log(' Medium Priority: Validating form');
    // Form validation logic
  }

  lowPriorityHandler(event: Event) {
    console.log(' Low Priority: UI animations');
    // UI feedback logic
  }

  analyticsHandler(event: Event) {
    console.log(' Analytics: Button clicked');
    // Analytics tracking
  }
}

Unit Test for stopImmediatePropagation()

// priority-button.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { PriorityButtonComponent } from './priority-button.component';

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

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

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

  it('should stop immediate propagation when loading', () => {
    component.isLoading = true;

    spyOn(component, 'highPriorityHandler').and.callThrough();
    spyOn(component, 'mediumPriorityHandler');
    spyOn(component, 'lowPriorityHandler');
    spyOn(component, 'analyticsHandler');

    const button = fixture.debugElement.nativeElement.querySelector('.priority-btn');
    button.click();

    expect(component.highPriorityHandler).toHaveBeenCalled();
    expect(component.mediumPriorityHandler).not.toHaveBeenCalled();
    expect(component.lowPriorityHandler).not.toHaveBeenCalled();
    expect(component.analyticsHandler).not.toHaveBeenCalled();
  });

  it('should allow all handlers when not loading', () => {
    component.isLoading = false;

    spyOn(component, 'highPriorityHandler').and.callThrough();
    spyOn(component, 'mediumPriorityHandler');
    spyOn(component, 'lowPriorityHandler');
    spyOn(component, 'analyticsHandler');

    const button = fixture.debugElement.nativeElement.querySelector('.priority-btn');
    button.click();

    expect(component.highPriorityHandler).toHaveBeenCalled();
    expect(component.mediumPriorityHandler).toHaveBeenCalled();
    expect(component.lowPriorityHandler).toHaveBeenCalled();
    expect(component.analyticsHandler).toHaveBeenCalled();
  });

  it('should test stopImmediatePropagation behavior', () => {
    let handler1Called = false;
    let handler2Called = false;

    const button = document.createElement('button');

    button.addEventListener('click', (event) => {
      handler1Called = true;
      event.stopImmediatePropagation();
    });

    button.addEventListener('click', () => {
      handler2Called = true;
    });

    button.click();

    expect(handler1Called).toBe(true);
    expect(handler2Called).toBe(false);
  });
});

Quick Reference Cheat Sheet

Method	What it does	When to use
`stopPropagation()`	Stops event from bubbling to parent elements	Button inside clickable card
`preventDefault()`	Prevents browser's default behavior	Custom form handling, drag & drop
`defaultPrevented`	Checks if preventDefault() was called	Conditional event handling
`stopImmediatePropagation()`	Stops all other listeners on same element + bubbling	Priority-based event handling

Pro Tips & Bonus Tricks

1. Combining Methods for Ultimate Control

onComplexHandler(event: Event) {
  // Check if someone already handled this
  if (event.defaultPrevented) {
    return;
  }

  // Prevent default browser behavior
  event.preventDefault();

  // Stop other handlers if this is critical
  if (this.isCriticalOperation) {
    event.stopImmediatePropagation();
  } else {
    // Just stop bubbling
    event.stopPropagation();
  }
}

2. Debugging Event Flow

debugEventFlow(event: Event, handlerName: string) {
  console.log(` ${handlerName}:`, {
    type: event.type,
    target: event.target,
    currentTarget: event.currentTarget,
    defaultPrevented: event.defaultPrevented,
    bubbles: event.bubbles,
    eventPhase: event.eventPhase
  });
}

3. Angular Directive for Event Control

@Directive({
  selector: '[appEventControl]'
})
export class EventControlDirective {
  @Input() stopPropagation = false;
  @Input() preventDefault = false;

  @HostListener('click', ['$event'])
  onClick(event: Event) {
    if (this.preventDefault) {
      event.preventDefault();
    }
    if (this.stopPropagation) {
      event.stopPropagation();
    }
  }
}

// Usage:
// <button appEventControl [stopPropagation]="true">Click me</button>

Getting the hang of this? Show some love with a clap—it helps other developers discover these tips!

Common Gotchas to Avoid

Don't overuse stopPropagation() - It can break parent components that rely on events
preventDefault() doesn't stop propagation - You might need both
stopImmediatePropagation() is nuclear - Use sparingly, usually for error/loading states
Event delegation breaks with stopPropagation() - Be careful with dynamic content

Which of these gotchas have you fallen into? Share your war stories in the comments!

Recap: Your Event Control Toolkit

You now have four powerful tools in your event-handling arsenal:

stopPropagation(): Your go-to for preventing event bubbling (buttons in cards, nested clickables)
preventDefault(): Essential for custom form handling and drag-and-drop
defaultPrevented: Perfect for conditional event logic and defensive programming
stopImmediatePropagation(): The nuclear option for priority-based handling

Each method serves a specific purpose, and knowing when to use which one will make your Angular applications more predictable and bug-free.

What's Next?

I want to hear from you!

What's your biggest event handling challenge? Drop a comment—I read every single one and often turn them into future articles!

Want more Angular deep-dives like this? I share practical tips and real-world solutions every week. Follow me so you don't miss out!

Found this helpful? Smash that clap button (you can clap up to 50 times!)—it helps other developers find these solutions.

Action Points for You:

Try the examples in your own Angular project
Create unit tests for your event handlers
Share this with a teammate who's struggling with event handling
Bookmark this for future reference when debugging tricky event issues

Coming up next: I'm diving deep into Angular's Change Detection strategy. Want to be notified? Hit that follow button!

What did you think of this article? Got questions or want to share your own event handling tricks? The comment section is all yours!

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

Say Goodbye to JavaScript's Date Object: The Temporal API is Here to Save Your Sanity

Rajat — Wed, 01 Apr 2026 13:30:00 +0000

Finally, a date-time API that actually makes sense and won't make you want to pull your hair out

Ever found yourself staring at JavaScript's Date object thinking, "There has to be a better way"? You're not alone. How many times have you written new Date().getMonth() + 1 just to get the actual month number, or struggled with timezone hell that made your perfectly working local code break in production?

Quick question for you: What's the most frustrating Date-related bug you've encountered? Drop it in the comments—I bet others have been there too!

If you've ever dealt with JavaScript dates, you know the pain. But here's some great news: the Temporal API is coming to replace the Date object, and it's going to change everything. By the end of this article, you'll understand why Temporal is a game-changer and how to start using it in your Angular applications today.

Here's what you'll learn:

Why JavaScript's Date object is fundamentally broken
How the Temporal API solves these problems elegantly
Practical examples with Angular implementations
How to write unit tests for Temporal API code
Migration strategies from Date to Temporal

Ready? Let's dive in!

The Date Object Problem: Why We Need Something Better

Let's be honest—JavaScript's Date object has been a source of frustration since day one. Here are the biggest pain points:

1. Zero-Based Months (Because Why Not Confuse Everyone?)

// This creates January 15th, 2024... wait, what? 
const date = new Date(2024, 0, 15);
console.log(date.getMonth()); // 0 (January)
console.log(date.getDate());  // 15

// To get March, you write:
const march = new Date(2024, 2, 15); // Month 2 = March

Who thought this was a good idea? This has caused countless bugs in production.

2. Mutable Objects That Lead to Bugs

const originalDate = new Date(2024, 0, 15);
const modifiedDate = originalDate;

modifiedDate.setDate(20);
console.log(originalDate); // Also changed!

3. Timezone Nightmares

// This looks innocent enough...
const date = new Date('2024-01-15');
console.log(date); // Different output based on your timezone!

Sound familiar? I've seen this break so many applications when they move to different servers or users access them from different time zones.

If you've been burned by any of these issues, give this article a clap—you're definitely not alone!

Enter the Temporal API: A Modern Solution

The Temporal API is a new JavaScript proposal (currently at Stage 3) that provides a modern, immutable, and intuitive way to work with dates and times. Here's why it's revolutionary:

Key Benefits:

Immutable objects - no more accidental mutations
Intuitive API - months are 1-12, not 0-11
Timezone-aware - built-in support for different timezones
Type safety friendly - works beautifully with TypeScript
Performance optimized - faster than Date object

Hands-On Examples: Temporal in Action

Let's see how Temporal makes common tasks actually pleasant:

Basic Date Creation

// Old way with Date
const oldDate = new Date(2024, 0, 15); // Remember: 0 = January

// New way with Temporal
const newDate = Temporal.PlainDate.from('2024-01-15');
// or
const newDate2 = new Temporal.PlainDate(2024, 1, 15); // 1 = January!

Much cleaner, right? No more mental gymnastics to remember that months start at 0.

Working with Timezones

// Creating timezone-aware dates
const utcTime = Temporal.Instant.from('2024-01-15T10:30:00Z');
const localTime = utcTime.toZonedDateTimeISO('America/New_York');
const europeTime = utcTime.toZonedDateTimeISO('Europe/London');

console.log(localTime.toString()); // 2024-01-15T05:30:00-05:00[America/New_York]
console.log(europeTime.toString()); // 2024-01-15T10:30:00+00:00[Europe/London]

This is what timezone handling should look like! Crystal clear and explicit.

Date Arithmetic Made Simple

// Adding time periods
const today = Temporal.Now.plainDateISO();
const nextWeek = today.add({ days: 7 });
const nextMonth = today.add({ months: 1 });

// Calculating differences
const vacation = Temporal.PlainDate.from('2024-06-15');
const daysUntilVacation = today.until(vacation, { largestUnit: 'day' });
console.log(`${daysUntilVacation.days} days until vacation!`);

Implementing Temporal in Angular Applications

Now let's see how to use Temporal in real Angular applications. Here's a practical service example:

Date Service with Temporal

// date.service.ts
import { Injectable } from '@angular/core';
import { Temporal } from '@js-temporal/polyfill';

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

  getCurrentDate(): Temporal.PlainDate {
    return Temporal.Now.plainDateISO();
  }

  getCurrentDateTime(): Temporal.ZonedDateTime {
    return Temporal.Now.zonedDateTimeISO();
  }

  formatDate(date: Temporal.PlainDate, locale = 'en-US'): string {
    return date.toLocaleString(locale, {
      year: 'numeric',
      month: 'long',
      day: 'numeric'
    });
  }

  calculateAge(birthDate: Temporal.PlainDate): number {
    const today = this.getCurrentDate();
    const duration = birthDate.until(today, { largestUnit: 'year' });
    return duration.years;
  }

  isBusinessDay(date: Temporal.PlainDate): boolean {
    const dayOfWeek = date.dayOfWeek;
    return dayOfWeek >= 1 && dayOfWeek <= 5; // Monday = 1, Sunday = 7
  }

  getNextBusinessDay(date: Temporal.PlainDate): Temporal.PlainDate {
    let nextDay = date.add({ days: 1 });
    while (!this.isBusinessDay(nextDay)) {
      nextDay = nextDay.add({ days: 1 });
    }
    return nextDay;
  }
}

Angular Component Example

// appointment.component.ts
import { Component, OnInit } from '@angular/core';
import { DateService } from './date.service';
import { Temporal } from '@js-temporal/polyfill';

@Component({
  selector: 'app-appointment',
  template: `
    <div class="appointment-scheduler">
      <h2>Schedule Your Appointment</h2>

      <div class="date-info">
        <p>Today: {{ todayFormatted }}</p>
        <p>Next Business Day: {{ nextBusinessDayFormatted }}</p>
      </div>

      <div class="appointment-form">
        <input
          type="date"
          [(ngModel)]="selectedDateString"
          (change)="onDateChange()"
          [min]="minDate">

        <div *ngIf="selectedDate" class="date-details">
          <p>Selected: {{ selectedDateFormatted }}</p>
          <p *ngIf="!isSelectedDateBusinessDay" class="warning">
            ⚠️ This is not a business day. Consider: {{ suggestedBusinessDay }}
          </p>
        </div>
      </div>
    </div>
  `
})
export class AppointmentComponent implements OnInit {
  todayFormatted = '';
  nextBusinessDayFormatted = '';
  selectedDate?: Temporal.PlainDate;
  selectedDateString = '';
  selectedDateFormatted = '';
  isSelectedDateBusinessDay = true;
  suggestedBusinessDay = '';
  minDate = '';

  constructor(private dateService: DateService) {}

  ngOnInit() {
    const today = this.dateService.getCurrentDate();
    this.todayFormatted = this.dateService.formatDate(today);

    const nextBusinessDay = this.dateService.getNextBusinessDay(today);
    this.nextBusinessDayFormatted = this.dateService.formatDate(nextBusinessDay);

    // Set minimum date for input
    this.minDate = today.toString();
  }

  onDateChange() {
    if (this.selectedDateString) {
      this.selectedDate = Temporal.PlainDate.from(this.selectedDateString);
      this.selectedDateFormatted = this.dateService.formatDate(this.selectedDate);

      this.isSelectedDateBusinessDay = this.dateService.isBusinessDay(this.selectedDate);

      if (!this.isSelectedDateBusinessDay) {
        const suggested = this.dateService.getNextBusinessDay(this.selectedDate);
        this.suggestedBusinessDay = this.dateService.formatDate(suggested);
      }
    }
  }
}

Pretty elegant, right? The code is readable, predictable, and handles edge cases naturally.

Question for you: How would you handle recurring appointments with this setup? Share your approach in the comments!

Unit Testing Temporal API Code

Testing with Temporal is much more straightforward than with Date objects. Here are comprehensive test examples:

Testing the Date Service

// date.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { DateService } from './date.service';
import { Temporal } from '@js-temporal/polyfill';

describe('DateService', () => {
  let service: DateService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(DateService);
  });

  describe('formatDate', () => {
    it('should format date correctly', () => {
      const date = new Temporal.PlainDate(2024, 1, 15);
      const formatted = service.formatDate(date);
      expect(formatted).toBe('January 15, 2024');
    });

    it('should format date with different locale', () => {
      const date = new Temporal.PlainDate(2024, 1, 15);
      const formatted = service.formatDate(date, 'de-DE');
      expect(formatted).toBe('15. Januar 2024');
    });
  });

  describe('calculateAge', () => {
    it('should calculate age correctly', () => {
      // Mock current date to ensure consistent tests
      spyOn(service, 'getCurrentDate').and.returnValue(
        new Temporal.PlainDate(2024, 1, 15)
      );

      const birthDate = new Temporal.PlainDate(1990, 5, 20);
      const age = service.calculateAge(birthDate);
      expect(age).toBe(33);
    });

    it('should handle leap year birthdays', () => {
      spyOn(service, 'getCurrentDate').and.returnValue(
        new Temporal.PlainDate(2024, 2, 28)
      );

      const leapYearBirthday = new Temporal.PlainDate(2000, 2, 29);
      const age = service.calculateAge(leapYearBirthday);
      expect(age).toBe(23); // Not yet 24
    });
  });

  describe('isBusinessDay', () => {
    it('should return true for Monday', () => {
      const monday = new Temporal.PlainDate(2024, 1, 15); // Monday
      expect(service.isBusinessDay(monday)).toBe(true);
    });

    it('should return true for Friday', () => {
      const friday = new Temporal.PlainDate(2024, 1, 19); // Friday
      expect(service.isBusinessDay(friday)).toBe(true);
    });

    it('should return false for Saturday', () => {
      const saturday = new Temporal.PlainDate(2024, 1, 20); // Saturday
      expect(service.isBusinessDay(saturday)).toBe(false);
    });

    it('should return false for Sunday', () => {
      const sunday = new Temporal.PlainDate(2024, 1, 21); // Sunday
      expect(service.isBusinessDay(sunday)).toBe(false);
    });
  });

  describe('getNextBusinessDay', () => {
    it('should return next day if current day is Monday-Thursday', () => {
      const wednesday = new Temporal.PlainDate(2024, 1, 17);
      const nextBusinessDay = service.getNextBusinessDay(wednesday);
      expect(nextBusinessDay.toString()).toBe('2024-01-18'); // Thursday
    });

    it('should skip weekend and return Monday if current day is Friday', () => {
      const friday = new Temporal.PlainDate(2024, 1, 19);
      const nextBusinessDay = service.getNextBusinessDay(friday);
      expect(nextBusinessDay.toString()).toBe('2024-01-22'); // Monday
    });

    it('should return Monday if current day is Saturday', () => {
      const saturday = new Temporal.PlainDate(2024, 1, 20);
      const nextBusinessDay = service.getNextBusinessDay(saturday);
      expect(nextBusinessDay.toString()).toBe('2024-01-22'); // Monday
    });
  });
});

Testing Component with Temporal

// appointment.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { FormsModule } from '@angular/forms';
import { AppointmentComponent } from './appointment.component';
import { DateService } from './date.service';
import { Temporal } from '@js-temporal/polyfill';

describe('AppointmentComponent', () => {
  let component: AppointmentComponent;
  let fixture: ComponentFixture<AppointmentComponent>;
  let dateService: jasmine.SpyObj<DateService>;

  beforeEach(async () => {
    const dateServiceSpy = jasmine.createSpyObj('DateService', [
      'getCurrentDate',
      'formatDate',
      'getNextBusinessDay',
      'isBusinessDay'
    ]);

    await TestBed.configureTestingModule({
      declarations: [AppointmentComponent],
      imports: [FormsModule],
      providers: [
        { provide: DateService, useValue: dateServiceSpy }
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(AppointmentComponent);
    component = fixture.componentInstance;
    dateService = TestBed.inject(DateService) as jasmine.SpyObj<DateService>;
  });

  beforeEach(() => {
    // Setup default mock returns
    const mockToday = new Temporal.PlainDate(2024, 1, 15);
    const mockNextBusinessDay = new Temporal.PlainDate(2024, 1, 16);

    dateService.getCurrentDate.and.returnValue(mockToday);
    dateService.getNextBusinessDay.and.returnValue(mockNextBusinessDay);
    dateService.formatDate.and.returnValue('January 15, 2024');
  });

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

  it('should initialize with current date information', () => {
    component.ngOnInit();

    expect(dateService.getCurrentDate).toHaveBeenCalled();
    expect(dateService.getNextBusinessDay).toHaveBeenCalled();
    expect(component.todayFormatted).toBe('January 15, 2024');
    expect(component.minDate).toBe('2024-01-15');
  });

  it('should handle date selection for business day', () => {
    dateService.isBusinessDay.and.returnValue(true);
    dateService.formatDate.and.returnValue('January 16, 2024');

    component.selectedDateString = '2024-01-16';
    component.onDateChange();

    expect(component.selectedDate?.toString()).toBe('2024-01-16');
    expect(component.isSelectedDateBusinessDay).toBe(true);
    expect(dateService.isBusinessDay).toHaveBeenCalled();
  });

  it('should suggest next business day for weekend selection', () => {
    dateService.isBusinessDay.and.returnValue(false);
    dateService.formatDate.and.returnValue('January 20, 2024');
    dateService.getNextBusinessDay.and.returnValue(
      new Temporal.PlainDate(2024, 1, 22)
    );

    component.selectedDateString = '2024-01-20';
    component.onDateChange();

    expect(component.isSelectedDateBusinessDay).toBe(false);
    expect(component.suggestedBusinessDay).toBe('January 20, 2024');
    expect(dateService.getNextBusinessDay).toHaveBeenCalledWith(
      component.selectedDate
    );
  });
});

Notice how clean these tests are? No more mocking global Date objects or dealing with timezone-dependent tests that pass locally but fail in CI!

Migration Strategy: From Date to Temporal

Migrating from Date to Temporal doesn't have to be overwhelming. Here's a practical approach:

Step 1: Install the Polyfill

npm install @js-temporal/polyfill

Step 2: Create Wrapper Functions

// temporal-adapter.ts
import { Temporal } from '@js-temporal/polyfill';

export class TemporalAdapter {
  // Convert Date to Temporal
  static dateToTemporal(date: Date): Temporal.PlainDate {
    return Temporal.PlainDate.from({
      year: date.getFullYear(),
      month: date.getMonth() + 1, // Fix the zero-based month
      day: date.getDate()
    });
  }

  // Convert Temporal to Date (for backward compatibility)
  static temporalToDate(temporal: Temporal.PlainDate): Date {
    return new Date(temporal.year, temporal.month - 1, temporal.day);
  }
}

Step 3: Gradual Migration

Start with new features, then gradually migrate existing code:

// Before
class EventService {
  createEvent(date: Date, title: string) {
    return {
      id: this.generateId(),
      title,
      date: date.toISOString(),
      dayOfWeek: date.getDay()
    };
  }
}

// After
class EventService {
  createEvent(date: Temporal.PlainDate | Date, title: string) {
    const temporalDate = date instanceof Date
      ? TemporalAdapter.dateToTemporal(date)
      : date;

    return {
      id: this.generateId(),
      title,
      date: temporalDate.toString(),
      dayOfWeek: temporalDate.dayOfWeek
    };
  }
}

Browser Support and Production Readiness

Here's the current status: The Temporal API is still in Stage 3 of the TC39 process, which means it's not yet available in browsers natively. But don't let that stop you!

Using the Polyfill Today

// Install polyfill
npm install @js-temporal/polyfill

// Use in your app
import { Temporal } from '@js-temporal/polyfill';

The polyfill is production-ready and used by many companies already. Performance is actually better than the Date object in many cases!

Are you already using Temporal in production? Share your experience in the comments—I'd love to hear about real-world usage!

Pro Tips for Temporal Success

Here are some insider tips I've learned from using Temporal in real projects:

1. Always Be Explicit About Timezones

// Good - explicit timezone
const meeting = Temporal.ZonedDateTime.from('2024-01-15T14:30:00[America/New_York]');

// Avoid - ambiguous
const meeting = Temporal.PlainDateTime.from('2024-01-15T14:30:00');

2. Use PlainDate for Date-Only Logic

// For birthdays, holidays, etc.
const birthday = new Temporal.PlainDate(1990, 5, 15);
const christmas = new Temporal.PlainDate(2024, 12, 25);

3. Leverage Immutability for State Management

// In Angular components, this prevents accidental mutations
this.selectedDate = this.selectedDate.add({ days: 1 });

These simple patterns will save you hours of debugging!

If these tips are helpful, smash that clap button—it really helps other developers discover this content!

What About Performance?

You might be wondering: "Is Temporal slower than Date?"

Surprisingly, no! In many cases, Temporal is actually faster because:

It's designed from the ground up for modern JavaScript engines
No legacy compatibility baggage
Better memory usage patterns
More efficient string parsing

Here's a quick benchmark you can try:

// Benchmark: Creating 1000 date objects
console.time('Date creation');
for (let i = 0; i < 1000; i++) {
  new Date(2024, 0, i % 28);
}
console.timeEnd('Date creation');

console.time('Temporal creation');
for (let i = 0; i < 1000; i++) {
  new Temporal.PlainDate(2024, 1, (i % 28) + 1);
}
console.timeEnd('Temporal creation');

The results might surprise you!

Recap: Why Temporal Changes Everything

Let's wrap up what we've covered and why this matters:

The Problems Temporal Solves:

Intuitive month numbering (1-12, not 0-11)
Immutable objects prevent accidental bugs
Built-in timezone support that actually works
Clear, readable API that matches how we think about dates
Better performance and memory usage
Type-safe and testing-friendly

What You've Learned Today:

How to implement Temporal in Angular applications
Practical patterns for date handling
Comprehensive unit testing strategies
Migration approaches from Date to Temporal
Real-world examples you can use immediately

The Bottom Line: JavaScript's Date object has been a pain point for 25+ years. Temporal finally gives us the date/time API we deserve. While it's still in development, the polyfill is production-ready and will make your code more robust today.

The transition to Temporal isn't just about fixing bugs—it's about writing more maintainable, predictable code that your future self (and your teammates) will thank you for.

Let's Keep the Conversation Going!

What did you think? Have you tried Temporal yet? What's your biggest date/time pain point in JavaScript? Drop a comment below—I love hearing about real-world challenges developers face!

Here's what I want to know specifically:

Are you planning to try Temporal in your next project?
What's the weirdest Date object bug you've encountered?
How do you currently handle timezones in your apps?

Found this helpful? If this article saved you from future date-related headaches, give it a few claps so other developers can discover it too! Every clap helps the algorithm show this to more people who need it.

Want more dev insights like this? I share practical frontend tips, Angular deep-dives, and modern JavaScript techniques every week. Follow me here on Medium or [subscribe to my newsletter] to stay updated!

Take Action:

Try it today: Install the Temporal polyfill in a side project
Bookmark this: You'll want to reference these examples later
Share it: Know someone who struggles with JavaScript dates? Send them this article!
Follow up: I'm planning a deep-dive series on advanced Temporal patterns—follow to get notified!

Next up in this series: "Advanced Temporal Patterns: Building a Complete Calendar System" - follow me to catch it when it drops!

10 Game-Changing Decorator Patterns Every JavaScript Developer Should Know

Rajat — Tue, 24 Mar 2026 13:30:00 +0000

Discover how decorators can clean up your code, enhance reusability, and help you write scalable, professional-grade Angular and JavaScript applications.

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

withInMemoryScrolling in Angular: Modern Scroll Restoration and Anchor Scrolling Explained

Rajat — Wed, 14 Jan 2026 13:30:00 +0000

A complete guide to scroll restoration and anchor navigation in modern Angular apps—from basic setup to production-ready patterns

Introduction

Single-page applications (SPAs) fundamentally changed web navigation by eliminating full page reloads. However, this architectural shift introduced a UX regression: browsers lost their native ability to restore scroll positions when users navigate backward or forward through history. In traditional multi-page applications, the browser automatically remembers where you scrolled on a page and returns you to that exact position when you hit the back button. SPAs broke this behavior.

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 full article, explore the demo, and access the complete code here:
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

Why Does Your Angular Component State Reset When You Move It? A Deep Dive into CDK Portals

Rajat — Wed, 07 Jan 2026 13:30:00 +0000

Understanding the difference between recreating views and moving DOM elements

Have you ever moved a component from one part of your Angular layout to another, only to watch all its state disappear? The timer resets, the form clears, the toggle switches back—everything vanishes. Frustrating, right?

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

Migrating from Jasmine/Karma to Vitest in Angular 21: A Step-by-Step Guide Developer's Complete Guide

Rajat — Mon, 22 Dec 2025 13:30:00 +0000

Say goodbye to Karma, hello to lightning-fast tests with Vitest

Introduction

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:

Builder changed from @angular-devkit/build-angular:karma to @angular/build:unit-test
Removed the karmaConfig option
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:

Installation: Added Vitest, jsdom, and Playwright to replace Karma/Jasmine
Configuration: Updated angular.json to use the new unit-test builder
Cleanup: Removed Karma dependencies and configuration files
TypeScript: Fixed typings by updating tsconfig.spec.json
Modern Syntax: Wrote tests using signal-based inputs and standalone components
Advanced Setup: Configured vitest.config.ts for custom behavior
Browser Testing: Set up Playwright for real browser testing
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:

Back up your current test configuration
Follow the steps above in a feature branch
Run your existing tests and fix any issues
Gradually adopt explicit imports and modern patterns
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

npx knip: The Smart Way to Detect Dead Code in Your JavaScript & TypeScript Projects

Rajat — Mon, 15 Dec 2025 03:30:00 +0000

Discover how one command can clean up thousands of lines of unused code and boost your codebase health

Have you ever wondered how much of your codebase is actually being used? If you are maintaining a medium to large application, chances are you have accumulated dead code, unused dependencies, and orphaned files that nobody dares to touch. What if I told you there is a tool that can find all of this automatically in seconds?

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:

Framework-aware: It understands Angular modules (though we use standalone now), React components, Next.js pages, and more
Configurable: You can tell Knip about custom entry points or ignore certain patterns
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:

Run Knip monthly: Set a calendar reminder to audit your codebase
Review before merging: Make Knip checks part of your PR review process
Delete aggressively: If code is unused for 3+ months, it is probably safe to remove
Use feature flags: Instead of commenting out code, use feature flags and delete the code when the flag is removed
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?"

Tool	What It Finds	Speed	Configuration
Knip	Unused files, exports, dependencies, types	Fast	Moderate
ESLint	Code quality issues, unused variables	Fast	High
Depcheck	Unused dependencies only	Fast	Low
Webpack Bundle Analyzer	Bundle size, what's included	Slow	Low

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:

Day 1: Run npx knip on your project and review the report
Day 2: Create a knip.json config to tune the results
Day 3: Remove obviously unused files and dependencies
Day 4: Run your test suite to verify nothing broke
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

From 5MB to 500KB: The Hidden Cost of providedIn: 'root' in Angular – A Performance Deep Dive

Rajat — Wed, 03 Dec 2025 13:30:00 +0000

How Angular's Tree-Shaking Actually Works (And How to Keep Your Bundle Lean in 2025)

Ever shipped an Angular app and wondered why your main bundle is still bloated even after using providedIn: 'root' everywhere?

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:

Audit your services: Run bundle analyzer today. Find services in wrong bundles.
Question every providedIn: 'root': Does it really need to be global?
Use providedIn: 'any' for feature-specific services
Leverage injection tokens for swappable implementations
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

Angular 21 Vitest Testing Revolution: Complete Karma-to-Vitest Migration Guide, ICOV Coverage, Faster DX & Modern Testing

Rajat — Tue, 02 Dec 2025 13:30:00 +0000

How a Lightning-Fast Testing Framework is Making Karma + Jasmine Obsolete—And What It Means for Your Angular Projects

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:

Jasmine	Vitest
`jasmine.createSpy()`	`vi.fn()`
`spyOn(obj, 'method')`	`vi.spyOn(obj, 'method')`
`spyOn().and.returnValue()`	`vi.fn().mockReturnValue()`
`expect().toHaveBeenCalled()`	`expect().toHaveBeenCalled()` (same)
`fakeAsync()`	`vi.useFakeTimers()`
`tick(100)`	`await vi.advanceTimersByTimeAsync(100)`
`flush()`	`await vi.runAllTimersAsync()`

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:

Try Vitest in a small project first—get comfortable before migrating your main app
Set up CI/CD integration early—automated testing saves teams
Share this with your team—discuss migration timeline and strategy
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

The Angular Service Scoping Mistake That's Killing Your App Performance (And How to Fix It)

Rajat — Wed, 26 Nov 2025 13:30:00 +0000

From Bloated to Blazing: How Proper Angular Service Scoping Cut My App Size by 40%

Quick question: How many times have you added providedIn: 'root' to an Angular service without thinking twice?

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:

Your service loads ALL products the moment your app starts
It stays in memory even when users are on completely unrelated pages
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 💨

Use OnPush Change Detection with scoped services for better performance
Implement proper service disposal in your modules
Consider using Angular's tree-shakable providers for truly optional services
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:

Audit your current services — how many are unnecessarily root-level?
Refactor one service this week using the patterns above
Add proper unit tests for your scoped services
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

Angular v21 Has Landed: Are You Ready for the Signal Revolution?

Rajat — Tue, 25 Nov 2025 13:30:00 +0000

The game-changing release that transforms how you build Angular apps—with signal-based forms, zoneless architecture, and headless accessibility components

Introduction

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

How to Use SVG Icons with Angular Material's mat-icon Component (The Right Way)

Rajat — Wed, 19 Nov 2025 13:30:00 +0000

Stop fighting with icon fonts—here's how to set up scalable, crisp SVG icons in Angular Material that actually work

Ever spent hours trying to get that perfect icon to show up in your Angular app, only to end up with a frustrating square or a blurry mess?

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.

🎯 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