DEV Community: Rajat

Angular's Injection Context: The Hidden Runtime Environment Every Developer Should Master

Rajat — Wed, 27 May 2026 13:30:00 +0000

Understanding When and Where Angular's Dependency Injection Actually Works

If you have ever encountered the NG0203 error — inject() must be called from an injection context — and spent time wondering why a perfectly valid service injection works in one place but fails in another, this article explains exactly why.

Angular's dependency injection does not work everywhere. It requires a specific runtime environment called the Injection Context. Once you understand what that is, where it exists, and how to create it manually, you will stop guessing and start writing predictable, testable Angular code.

Before we dive into the examples, a quick note:
The code snippets provided here may be syntax from earlier Angular versions. Code Snippets just for understanding only.

This article covers:

What Injection Context is and why it matters
Every location where it exists in an Angular application
How to use runInInjectionContext and assertInInjectionContext
Modern DI patterns with signals and standalone components
Unit testing code that depends on injection context

What Is Dependency Injection Context?

Injection Context is the execution environment where Angular's DI system is active. It is the runtime state in which an injector is available, the inject() function can resolve tokens, and Angular understands the component or service hierarchy you are operating within.

Without it, inject() has no injector to consult and throws NG0203.

// Works — field initializer inside a component class
@Component({
  selector: 'app-user',
  template: `...`,
  standalone: true
})
export class UserComponent {
  private userService = inject(UserService); // Injection context is active here
}

// Fails — standalone function with no injector
function randomFunction() {
  const service = inject(SomeService); // Error NG0203
}

Where Injection Context Exists

Injection context is not magic — it exists in specific, predictable places.

1. Class Constructors

Any class instantiated by Angular's DI system has injection context in its constructor. Both inject() and constructor parameter injection work here.

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

  constructor() {
    // Injection context is active inside constructors of DI-managed classes
    const logger = inject(LoggerService);
  }
}

@Component({
  selector: 'app-dashboard',
  template: `
    @if (data()) {
      <div>{{ data() }}</div>
    }
  `,
  standalone: true
})
export class DashboardComponent {
  private dataService = inject(DataService);

  constructor() {
    // Also valid here
  }
}

2. Field Initializers

Field initializers on Angular-managed classes run during construction, so injection context is active. This is the modern, preferred style — no constructor boilerplate required.

@Component({
  selector: 'app-profile',
  template: `
    @for (user of users(); track user.id) {
      <user-card [user]="user" />
    }
  `,
  standalone: true,
  imports: [UserCardComponent]
})
export class ProfileComponent {
  private userService = inject(UserService);
  private destroyRef = inject(DestroyRef);

  users = signal<User[]>([]);

  ngOnInit() {
    this.userService.getUsers()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(users => this.users.set(users));
  }
}

3. Factory Functions in Providers

Factory functions used in provider definitions — including InjectionToken factories — run inside injection context. You can call inject() freely within them.

export const API_CONFIG = new InjectionToken<ApiConfig>('API_CONFIG', {
  providedIn: 'root',
  factory: () => {
    // Injection context is active inside factory functions
    const env = inject(EnvironmentService);

    return {
      baseUrl: env.apiUrl,
      timeout: 5000
    };
  }
});

@Component({
  selector: 'app-api-consumer',
  template: `...`,
  standalone: true
})
export class ApiConsumerComponent {
  private config = inject(API_CONFIG);
}

4. Functional Guards and Resolvers

Angular's functional guard and resolver APIs (CanActivateFn, ResolveFn, etc.) run inside injection context, so you can call inject() directly inside them.

export const authGuard: CanActivateFn = (route, state) => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (authService.isAuthenticated()) {
    return true;
  }

  return router.createUrlTree(['/login'], {
    queryParams: { returnUrl: state.url }
  });
};

export const routes: Routes = [
  {
    path: 'admin',
    loadComponent: () => import('./admin/admin.component'),
    canActivate: [authGuard]
  }
];

A resolver follows the same pattern:

export const userResolver: ResolveFn<User> = (route) => {
  const userService = inject(UserService);
  const userId = route.params['id'];

  return userService.getUser(userId);
};

@Component({
  selector: 'app-user-detail',
  template: `
    @if (user()) {
      <h1>{{ user()!.name }}</h1>
    }
  `,
  standalone: true
})
export class UserDetailComponent {
  private route = inject(ActivatedRoute);

  user = toSignal(
    this.route.data.pipe(map(data => data['user'] as User))
  );
}

Running Code in Injection Context: `runInInjectionContext`

Sometimes you need to call inject() from a place where injection context does not naturally exist — for example, inside a utility function called from a component method. runInInjectionContext solves this by manually establishing the context.

The Problem

// This fails — no injection context in a standalone utility function
export function logUserAction(action: string) {
  const logger = inject(LoggerService); // Error NG0203
  logger.log(`User action: ${action}`);
}

The Solution

@Component({
  selector: 'app-activity',
  template: `
    <button (click)="trackAction('clicked')">Track</button>
  `,
  standalone: true
})
export class ActivityComponent {
  private injector = inject(EnvironmentInjector);

  trackAction(action: string) {
    runInInjectionContext(this.injector, () => {
      logUserAction(action); // Now injection context is active
    });
  }
}

export function logUserAction(action: string) {
  const logger = inject(LoggerService);
  const userService = inject(UserService);

  logger.log({
    action,
    userId: userService.currentUser?.id,
    timestamp: Date.now()
  });
}

The key is injecting EnvironmentInjector (not Injector) when you need to pass it to runInInjectionContext, since that function requires an EnvironmentInjector or Injector instance.

Real-World Use: Service Method with Dynamic Injection

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

  makeAuthenticatedRequest<T>(url: string): Observable<T> {
    return runInInjectionContext(this.injector, () => {
      const auth = inject(AuthService);
      const token = auth.getToken();

      return this.http.get<T>(url, {
        headers: { Authorization: `Bearer ${token}` }
      });
    });
  }
}

Note: in most cases it is cleaner to inject AuthService as a field. runInInjectionContext is best reserved for utilities and helpers that must remain decoupled from a specific class.

Writing Defensive Code: `assertInInjectionContext`

If you are writing a utility function that relies on injection context, you should call assertInInjectionContext at the top. This produces a clear, informative error immediately if the function is called in the wrong place, rather than a cryptic failure later.

export function createSignalFromObservable<T>(
  observableFactory: () => Observable<T>
): Signal<T | undefined> {
  // Fail immediately with a helpful message if called outside injection context
  assertInInjectionContext(createSignalFromObservable);

  const result = signal<T | undefined>(undefined);
  const destroyRef = inject(DestroyRef);

  observableFactory()
    .pipe(takeUntilDestroyed(destroyRef))
    .subscribe(value => result.set(value));

  return result.asReadonly();
}

// This works — called from a field initializer (injection context is active)
@Component({
  selector: 'app-data-viewer',
  template: `
    @if (userData()) {
      <pre>{{ userData() | json }}</pre>
    }
  `,
  standalone: true,
  imports: [JsonPipe]
})
export class DataViewerComponent {
  private userService = inject(UserService);

  userData = createSignalFromObservable(() => this.userService.getCurrentUser());
}

Debugging Injection Context

This helper can be useful during development to verify whether a code path is running inside injection context:

export function debugInjectionContext(label: string): boolean {
  try {
    assertInInjectionContext(debugInjectionContext);
    console.log(`[OK] ${label}: inside injection context`);
    return true;
  } catch {
    console.error(`[FAIL] ${label}: outside injection context`);
    return false;
  }
}

@Component({
  selector: 'app-debug',
  template: `...`,
  standalone: true
})
export class DebugComponent {
  constructor() {
    debugInjectionContext('Constructor'); // Logs: [OK]
  }

  ngOnInit() {
    debugInjectionContext('ngOnInit'); // Logs: [FAIL]
  }

  someMethod() {
    debugInjectionContext('someMethod'); // Logs: [FAIL]
  }
}

ngOnInit and other lifecycle hooks run outside injection context — only constructors and field initializers are safe for inject() without runInInjectionContext.

Signals and Injection Context

Angular signals integrate naturally with the injection system. Here are two common patterns.

Reactive Service with a Signal

@Injectable({ providedIn: 'root' })
export class ThemeService {
  private storage = inject(LocalStorageService);

  private themeSignal = signal<'light' | 'dark'>(
    (this.storage.getItem('theme') as 'light' | 'dark') ?? 'light'
  );

  readonly theme = this.themeSignal.asReadonly();

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

@Component({
  selector: 'app-theme-toggle',
  template: `
    <button (click)="themeService.toggleTheme()">
      @if (themeService.theme() === 'dark') {
        Switch to Light
      } @else {
        Switch to Dark
      }
    </button>
  `,
  standalone: true
})
export class ThemeToggleComponent {
  protected themeService = inject(ThemeService);
}

Computed Signal from Multiple Injected Services

@Component({
  selector: 'app-user-stats',
  template: `
    <div class="stats-grid">
      @for (stat of userStats(); track stat.label) {
        <div class="stat-card">
          <h3>{{ stat.label }}</h3>
          <p>{{ stat.value }}</p>
        </div>
      }
    </div>
  `,
  standalone: true
})
export class UserStatsComponent {
  private userService = inject(UserService);
  private analyticsService = inject(AnalyticsService);

  private user = toSignal(this.userService.currentUser$);

  userStats = computed(() => {
    const currentUser = this.user();
    if (!currentUser) return [];

    return [
      { label: 'Posts', value: currentUser.postCount },
      { label: 'Followers', value: currentUser.followerCount },
      {
        label: 'Engagement',
        value: this.analyticsService.calculateEngagement(currentUser)
      }
    ];
  });
}

Unit Testing Code That Uses Injection Context

Testing a Component with `inject()`

describe('UserProfileComponent', () => {
  let component: UserProfileComponent;
  let fixture: ComponentFixture<UserProfileComponent>;
  let userService: jasmine.SpyObj<UserService>;

  beforeEach(() => {
    const spy = jasmine.createSpyObj('UserService', ['getUser', 'updateUser']);

    TestBed.configureTestingModule({
      imports: [UserProfileComponent],
      providers: [{ provide: UserService, useValue: spy }]
    });

    fixture = TestBed.createComponent(UserProfileComponent);
    component = fixture.componentInstance;
    userService = TestBed.inject(UserService) as jasmine.SpyObj<UserService>;
  });

  it('should inject UserService', () => {
    expect(component['userService']).toBe(userService);
  });

  it('should load user data on init', () => {
    const mockUser = { id: 1, name: 'Test User' };
    userService.getUser.and.returnValue(of(mockUser));

    component.ngOnInit();

    expect(userService.getUser).toHaveBeenCalled();
    expect(component.user()).toEqual(mockUser);
  });
});

Testing a Utility That Calls `inject()`

Use TestBed.runInInjectionContext to execute functions that require injection context:

describe('logUserAction', () => {
  let injector: EnvironmentInjector;

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

    injector = TestBed.inject(EnvironmentInjector);
  });

  it('should log the action when called inside injection context', () => {
    const loggerSpy = spyOn(TestBed.inject(LoggerService), 'log');

    TestBed.runInInjectionContext(() => {
      logUserAction('test-action');
    });

    expect(loggerSpy).toHaveBeenCalledWith(
      jasmine.objectContaining({ action: 'test-action' })
    );
  });

  it('should throw NG0203 when called outside injection context', () => {
    expect(() => logUserAction('test')).toThrowError(/NG0203/);
  });
});

Testing a Functional Guard

describe('authGuard', () => {
  let authService: jasmine.SpyObj<AuthService>;
  let router: jasmine.SpyObj<Router>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        { provide: AuthService, useValue: jasmine.createSpyObj('AuthService', ['isAuthenticated']) },
        { provide: Router, useValue: jasmine.createSpyObj('Router', ['createUrlTree']) }
      ]
    });

    authService = TestBed.inject(AuthService) as jasmine.SpyObj<AuthService>;
    router = TestBed.inject(Router) as jasmine.SpyObj<Router>;
  });

  it('should return true when the user is authenticated', () => {
    authService.isAuthenticated.and.returnValue(true);

    const result = TestBed.runInInjectionContext(() =>
      authGuard({} as ActivatedRouteSnapshot, {} as RouterStateSnapshot)
    );

    expect(result).toBe(true);
  });

  it('should redirect to /login when not authenticated', () => {
    authService.isAuthenticated.and.returnValue(false);
    const urlTree = {} as UrlTree;
    router.createUrlTree.and.returnValue(urlTree);

    const result = TestBed.runInInjectionContext(() =>
      authGuard({} as ActivatedRouteSnapshot, { url: '/protected' } as RouterStateSnapshot)
    );

    expect(router.createUrlTree).toHaveBeenCalledWith(
      ['/login'],
      { queryParams: { returnUrl: '/protected' } }
    );
    expect(result).toBe(urlTree);
  });
});

Best Practices

Prefer inject() over constructor parameter injection. The result is less boilerplate and clearer intent, especially when a class depends on many services.

// Constructor injection — verbose at scale
@Component({ selector: 'app-old', template: `...`, standalone: true })
export class OldStyleComponent {
  constructor(
    private userService: UserService,
    private router: Router,
    private http: HttpClient
  ) {}
}

// Field injection — concise and explicit
@Component({ selector: 'app-modern', template: `...`, standalone: true })
export class ModernComponent {
  private userService = inject(UserService);
  private router = inject(Router);
  private http = inject(HttpClient);
}

Use DestroyRef for subscription cleanup. Inject DestroyRef and use takeUntilDestroyed instead of managing Subject-based teardown manually.

@Component({
  selector: 'app-live-data',
  template: `...`,
  standalone: true
})
export class LiveDataComponent {
  private destroyRef = inject(DestroyRef);
  private dataService = inject(DataService);

  data = signal<any[]>([]);

  ngOnInit() {
    this.dataService.getData()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(data => this.data.set(data));
  }
}

Use InjectionToken with factory for platform-aware configuration.

export interface AppConfig {
  apiUrl: string;
  version: string;
}

export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG');

bootstrapApplication(AppComponent, {
  providers: [
    {
      provide: APP_CONFIG,
      useFactory: () => {
        const platformId = inject(PLATFORM_ID);
        return {
          apiUrl: isPlatformBrowser(platformId) ? '/api' : 'http://localhost:3000',
          version: '2.0.0'
        };
      }
    }
  ]
});

Summary

Injection context is the runtime environment in which Angular's injector is active and inject() can resolve dependencies. It exists in:

Constructors of classes managed by Angular's DI system
Field initializers of those same classes
Factory functions in provider and InjectionToken definitions
Functional guards and resolvers (CanActivateFn, ResolveFn, etc.)

When you need injection context outside these locations, use runInInjectionContext with an EnvironmentInjector. When writing utility functions that depend on context, call assertInInjectionContext at the top to produce a clear error on misuse. In tests, use TestBed.runInInjectionContext to test any function that calls inject() directly.

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

Your Next npm install Could Already Be Running Malware

Rajat — Wed, 20 May 2026 13:30:00 +0000

Why installing packages the moment they drop is now a security incident waiting to happen

Here is a scenario that is no longer hypothetical.

A legitimate, widely trusted npm package publishes a new version. You run npm install — or your CI pipeline does automatically — and within seconds, before a single line of your application code executes, a postinstall script fires. It scans your filesystem for AWS credentials, GitHub tokens, npm publish tokens, and Kubernetes secrets. It ships them to a command-and-control server. Then it quietly finds every package you have publish access to on npm and injects the same payload into new versions, releasing them under your name.

You did not get phished. No one stole your password. Your two-factor authentication is still on. And you are now both a victim and, unknowingly, a propagation vector.

This is not a thought experiment. This is precisely what happened on May 11, 2026, when a threat group called TeamPCP compromised 42 packages in the @tanstack/* namespace, publishing 84 malicious versions in a six-minute window. @tanstack/react-router alone sees over 12.7 million weekly downloads. The malicious tarballs carried valid SLSA provenance — the cryptographic attestation that security tooling uses to verify packages came from a trusted source. The certificates were legitimate. They signed the attack.

By the end of that day, over 170 packages across npm and PyPI had been hit, including Mistral AI, UiPath, and the Bitwarden CLI.

If you have been thinking of dependency management as an engineering convenience problem, it is time to reframe it. It is a security problem. And one of the most effective mitigations is almost embarrassingly simple: stop installing packages the moment they are published.

Have you ever had a dependency update break something unexpected in production? Drop a comment below — I want to hear where this hit you.

Why the npm Ecosystem Became a Target

The numbers tell part of the story. The npm registry now hosts over 2.5 million packages. The average enterprise JavaScript application pulls in hundreds of transitive dependencies — packages your application does not import directly, but which exist somewhere in the resolved dependency tree. Each one is a potential entry point.

The attack surface expanded gradually, driven by several forces working together.

Maintainer burnout and abandoned packages. Many popular packages are maintained by one or two people in their spare time. When maintainers lose interest, they often hand off the package — or simply disappear. Attackers have learned to identify unmaintained high-download packages and either request maintainer access (as happened with event-stream in 2018) or simply purchase the maintainer's account credentials from data breach marketplaces. The package's download count remains, but the code is now under hostile control.

Transitive dependency explosion. When you install a framework, you are not installing one package. You are pulling in an entire dependency graph. Some of those are two or three hops away from the package you actually intended to use. Auditing what you install directly is tractable. Auditing the entire resolved tree — which can run into the hundreds of packages for a moderately sized project — is almost impossible to do manually.

Semver ranges as a silent update mechanism. Most package.json files specify dependencies with caret or tilde ranges: ^1.14.0 or ~1.14.0. This is intentional — it means patch and minor updates arrive automatically on your next install. It is also what allowed the Axios attack to propagate so effectively. Projects pinned to axios@^1.14.0 automatically resolved to the malicious 1.14.1 on their next npm install or CI run. No developer action required.

AI-generated low-quality packages. Since late 2024, the registry has seen a surge of packages generated by or with AI assistance, many of which have thin audit trails, no meaningful version history, and no active community watching for anomalies. Some are benign but poorly maintained. Others are typosquats designed to look like real packages.

Blind trust in the install-time convention. The npm ecosystem normalized a convention — postinstall scripts — that was designed for legitimate use cases like compiling native binaries, but which creates an execution surface that runs with full developer privileges the instant installation completes. This runs before your application, before your tests, and before most security tooling can inspect what actually ran.

What Actually Happens When You Run `npm install`

Most developers think of npm install as a file-copy operation. It is not. It is a code execution event.

When you run npm install, the package manager resolves your full dependency tree, downloads tarballs, unpacks them, and — critically — runs any lifecycle scripts defined in each package's package.json. The relevant hooks are:

{
  "scripts": {
    "preinstall": "runs before the package is installed",
    "install": "runs during installation",
    "postinstall": "runs after the package is installed",
    "prepare": "runs after install and before pack/publish"
  }
}

These scripts run with the same permissions as the user or process that invoked npm install. On a developer machine, that is typically your user account — with access to ~/.ssh, ~/.aws, ~/.npmrc (which contains your npm publish token), your shell history, and any environment variables you have set. On a CI runner, that means the runner's cloud credentials, OIDC tokens, and secrets injected by your pipeline.

The Axios attack exploited this directly. The malicious versions introduced a new dependency, plain-crypto-js@4.2.1, that had no presence in Axios's actual runtime code. It existed solely to execute a postinstall script that downloaded a second-stage remote access trojan. Normal application behavior was unchanged — your HTTP requests kept working. The malware ran silently at install time, then persisted.

The TanStack attack pushed this further. The worm installed a persistence daemon (com.user.gh-token-monitor.plist on macOS, a systemd user service on Linux) that polled your GitHub token every 60 seconds. If you followed the security playbook and revoked your token in response to a suspected compromise, the daemon detected the revocation and executed rm -rf ~/ — wiping your entire home directory as a retaliatory action. The correct response was the trigger.

Transitive execution is the hidden danger. When a deep dependency runs a postinstall script, you typically have no visibility into it. Your npm install output will mention it if logging is verbose, but most CI pipelines and developer workflows do not watch those logs carefully. The script runs and finishes before you see the result.

Lockfiles help, but not unconditionally. A lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) pins exact resolved versions, which prevents automatic version drift. If your lockfile pins axios@1.14.0, a new malicious 1.14.1 will not be pulled in automatically. But lockfiles require discipline. Any operation that resolves or updates the tree — npm update, npm install <new-package>, or a Renovate/Dependabot PR — can introduce new versions. And the Axios attack is a reminder that even a version explicitly installed based on a semver range can resolve to something you did not intend.

The Incident Record: What Has Already Happened

These are not hypothetical scenarios. They are documented incidents with real damage.

event-stream (2018). The event-stream package had over 1.5 million weekly downloads when a bad actor convinced the original maintainer to hand over publish access, claiming they wanted to help maintain it. The new maintainer injected a dependency targeting the copay Bitcoin wallet application. The attack went undetected for two months. The lesson: maintainer handoff is a trust event, not a routine admin action.

eslint-scope (2018). The eslint-scope package — part of the ESLint toolchain — was compromised when an attacker gained access to a maintainer's npm account via credentials stolen in a separate data breach. A malicious version was published that attempted to steal npm tokens from ~/.npmrc files and send them to a remote server. The package had millions of weekly downloads. Detection came from community monitoring, not from npm itself.

eslint-config-prettier (July 2025). A maintainer was phished via a convincing email sent from a lookalike domain. The attacker published unauthorized versions containing a postinstall script that executed a trojan DLL on Windows machines. The package had over 31 million weekly downloads at the time of compromise. The attack used a deceptive domain designed to resemble npmjs.com to steal credentials.

ua-parser-js (multiple incidents). The user agent parsing library was compromised more than once, with attackers injecting cryptocurrency miners and credential stealers. Given its reach across thousands of projects that passively depend on it through transitives, each incident resulted in broad exposure before detection.

Shai-Hulud (September 2025). In one of the largest npm supply chain attacks on record, a trusted maintainer was phished via a spoofed npm support email. Eighteen widely used packages with a combined weekly download count exceeding 2.6 billion were compromised. The malicious code targeted cryptocurrency transactions. CISA issued a public advisory. The attack was contained through community detection and not npm's own systems.

Axios (March 31, 2026). Microsoft Threat Intelligence attributed this attack to Sapphire Sleet, a North Korean state actor. Malicious versions 1.14.1 and 0.30.4 were published. They added a fake dependency that ran a postinstall script downloading a remote access trojan targeting macOS, Windows, and Linux. Projects using axios@^1.14.0 or axios@^0.30.0 resolved to the malicious versions on their next install. The trojan connected to a Sapphire Sleet command-and-control server with no visible change to Axios's behavior.

TanStack / Mini Shai-Hulud (May 11, 2026). The most technically sophisticated attack documented to date. No credentials were stolen. The attackers chained three GitHub Actions vulnerabilities — a pull_request_target Pwn Request, cache poisoning across the fork/base trust boundary, and runtime OIDC token extraction from the runner process — to publish 84 malicious packages in six minutes, all carrying valid SLSA provenance. The worm self-propagated using the victim's own publish credentials. OpenAI confirmed two employee devices were compromised. The campaign extended to over 170 packages across npm and PyPI by end of day.

The pattern across these incidents is consistent. A trusted package, a brief window of malicious publication, automatic adoption via semver ranges or CI pipelines, and detection by the community — not by the registry.

Have you audited your team's dependency update workflow recently? What does your process look like when a new version drops? Tell me in the comments.

Why "Wait Before Installing" Is Not Paranoia

The community security researchers who discovered the TanStack attack detected it approximately 20 minutes after the first malicious publish. The Axios malicious versions were identified within hours. In most recent incidents, the window between publish and public disclosure has been measured in hours, not days.

This is the core insight: attackers benefit from immediate adoption. Defenders benefit from delay.

If an organization had a policy of not installing packages released within the last seven days — enforced at the package manager or registry level — the Axios attack would not have reached their developers or CI pipelines. The TanStack attack would not have reached them either. The malicious versions were live for roughly four hours before deprecation began. A seven-day gate would have caught them with room to spare.

OpenAI's post-incident statement made this explicit. They noted that the two impacted employee devices "did not have the updated configurations that would have prevented the download of the newly observed package containing malware" — specifically referencing minimumReleaseAge configurations that they had begun deploying after the Axios incident but had not yet fully rolled out.

The waiting strategy works because:

Most compromised packages are detected within 24–72 hours by security researchers, community monitoring tools like Socket.dev, or registry scanning
Automated adoption (Renovate/Dependabot PRs merging, CI pipelines running npm install) is the primary propagation mechanism — any gate on version freshness interrupts that propagation
Malicious versions are typically removed or deprecated quickly once discovered, but only help organizations that have not already installed them
A brief delay has minimal practical cost for most dependency updates, which are not time-critical

The argument against waiting — that you need the latest security patches immediately — is real but addressable. The solution is an exclusion list for packages where you have an active vulnerability and are installing a confirmed-clean remediation version. That is a deliberate, audited decision, not an automatic update.

How Every Major Package Manager Now Supports This

All four major JavaScript package managers shipped native support for minimum release age gates. They arrived within months of each other, which suggests the ecosystem recognized the same threat simultaneously.

| Manager | Config File            | Unit    | Default  |
|---------|------------------------|---------|----------|
| pnpm    | pnpm-workspace.yaml    | minutes | 1 day    |
| Yarn    | .yarnrc.yml            | string  | none     |
| Bun     | bunfig.toml            | seconds | none     |
| npm     | .npmrc                 | days    | none     |

pnpm was the first to ship, introducing minimumReleaseAge in v10.16 (September 2025). As of pnpm 11, it defaults to one day — the only manager that enables this out of the box.

# pnpm-workspace.yaml
minimumReleaseAge: 10080   # 7 days in minutes

minimumReleaseAgeExclude:
  - "@yourorg/*"
  - "some-critical-patch-package"

Yarn shipped npmMinimalAgeGate in v4.10.0, supporting both raw minutes and human-readable duration strings.

# .yarnrc.yml
npmMinimalAgeGate: "7d"

npmPreapprovedPackages:
  - "@yourorg/*"
  - "typescript"

Bun added minimumReleaseAge in v1.3. The value is in seconds. Bun's own repository uses a three-day gate.

# bunfig.toml
[install]
minimumReleaseAge = 604800   # 7 days in seconds

minimumReleaseAgeExcludes = ["@types/bun", "typescript"]

npm shipped min-release-age in v11.10.0 (February 2026). The value is in days and has no exclusion mechanism yet.

# .npmrc
min-release-age=7

Setting one of these takes under a minute. The protection is real and meaningful.

npm vs Yarn vs pnpm: How Lifecycle Scripts Behave Differently

The three managers handle install-time script execution differently, and those differences matter for security posture.

npm runs lifecycle scripts by default for all packages. You can disable them globally with --ignore-scripts, but this is a blunt instrument — it also prevents legitimate native build steps from running. npm has no per-package script opt-in mechanism at the lockfile level.

# Disable all scripts globally (blunt, often breaks native packages)
npm install --ignore-scripts

# Check for postinstall hooks before installing
npm pack <package> --dry-run

pnpm gives you finer control. You can opt into scripts per package and audit which packages are requesting execution rights:

# pnpm-workspace.yaml
onlyBuiltDependencies:
  - esbuild
  - sharp
  - node-gyp
  - "@parcel/watcher"

With this configuration, only the named packages are allowed to run lifecycle scripts. Everything else installs silently. This is arguably the most important security configuration in pnpm and worth adopting regardless of your minimum age policy.

Yarn supports enableScripts: false in .yarnrc.yml, disabling all install-time scripts globally. It also supports unsafeHttpWhitelist and other registry controls that give enterprises granular policy control.

pnpm's content-addressable store is worth understanding. pnpm stores packages in a central content-addressed store (typically ~/.pnpm-store) and creates hard links into node_modules. This means a given package version is physically stored once per machine, regardless of how many projects use it. It also means that if a malicious version is installed anywhere on the machine, its content is present in the global store — a nuance worth considering in shared CI environments.

Lockfile determinism. All three managers support frozen lockfile installs in CI, which is non-negotiable for security:

# npm
npm ci

# Yarn
yarn install --immutable

# pnpm
pnpm install --frozen-lockfile

npm ci (or its equivalents) deletes node_modules and installs exactly the versions in the lockfile, failing if there is any discrepancy. This prevents resolution drift on CI even when developers update packages locally. If your CI uses npm install instead of npm ci, fix that first — it is a simpler and more immediate win than almost anything else in this article.

Practical Defensive Workflows

The following are concrete steps, not theoretical recommendations.

Pin exact versions for high-risk packages. For packages with broad filesystem access or network capabilities — package managers themselves, CLI tools, build tooling — prefer exact version pins over semver ranges:

{
  "dependencies": {
    "axios": "1.14.0",
    "lodash": "4.17.21"
  },
  "devDependencies": {
    "eslint": "9.26.0",
    "typescript": "5.8.3"
  }
}

Exact pinning means updates require a deliberate change to package.json, not just a fresh install. It is friction by design.

Use npm ci in every CI pipeline — no exceptions:

# GitHub Actions example
- name: Install dependencies
  run: npm ci
  env:
    NODE_ENV: production

Audit scripts before installing unfamiliar packages:

# Inspect the package tarball before installation
npm pack <package-name> --dry-run

# View lifecycle scripts defined in a package
npm info <package-name> scripts

# Check for postinstall specifically
cat node_modules/<package-name>/package.json | jq '.scripts'

Set up minimum release age in your package manager config. The commands above give you the syntax. Set a seven-day gate for all projects not subject to emergency patching workflows. For monorepos with internal packages published to your own registry, use the exclusion list to bypass the gate.

Use Socket.dev for dependency scanning. Socket monitors npm packages in real time and alerts on suspicious patterns — new maintainers, unusual postinstall scripts, network calls in install hooks, and high-entropy strings that suggest obfuscation. It integrates with GitHub and has a free tier. The TanStack attack was detected in part through this kind of monitoring.

Configure Renovate with approval gates. If you use Renovate for automated dependency updates, require a human review step before merging dependency PRs for production packages:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "matchPackagePatterns": ["*"],
      "automerge": false,
      "reviewersFromCodeOwners": true,
      "minimumReleaseAge": "7 days"
    },
    {
      "matchPackagePatterns": ["@yourorg/*"],
      "automerge": true,
      "minimumReleaseAge": "0 days"
    }
  ]
}

Run dependencies in isolated environments. The TanStack attack postmortem recommended that developers not run npm install directly on their host OS but instead use Docker dev containers or VMs. If a postinstall script executes malware, the blast radius is the container — not your ~/.ssh directory.

# devcontainer.json (VSCode Dev Containers)
{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "postCreateCommand": "npm ci",
  "remoteUser": "node"
}

Do not store secrets in .env files reachable by npm scripts. Use a proper secrets manager. The postinstall attack surface exists because secrets live in plaintext files that any process running as your user can read. If you use Doppler, Infisical, AWS SSO, or similar, secrets are not sitting on disk for a lifecycle script to find.

Enterprise Governance: Going Beyond the Developer Laptop

Individual practices matter, but organizations managing multiple teams and hundreds of repositories need structural approaches.

Private registries with quarantine policies. Tools like Artifactory, Verdaccio, and Cloudsmith allow you to mirror the npm registry through an internal proxy. You can configure this proxy to hold newly published versions in quarantine for a defined period before making them available to internal consumers. This enforces the minimum age policy at the infrastructure level, not just at the developer config level — meaning it applies to all teams uniformly, even those who have not updated their local configuration.

Developer -> Artifactory proxy -> [7-day quarantine buffer] -> npm registry

SBOM generation and tracking. A Software Bill of Materials gives you an auditable record of every dependency in your application, including transitive dependencies, at the time of each build. SBOM generation tools like cyclonedx-npm or syft produce machine-readable inventories that can be diffed between builds to identify new packages entering the tree:

# Generate an SBOM for your npm project
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Or using Syft
syft packages dir:. -o cyclonedx-json > sbom.json

If a malicious package enters your dependency tree, an SBOM diff will surface it. Without SBOM tracking, you have no systematic way to answer "what changed in our dependencies between deploy A and deploy B?"

Dependency review boards. For large engineering organizations, consider a lightweight governance process for first-time package additions. Not for every update — that would create unsustainable overhead — but for net-new packages being added to a project. A brief async review asking "do we need this, is it maintained, what does its install script do" catches a meaningful portion of risk without slowing teams down.

Monitor your CI/CD environment as aggressively as your application runtime. The Axios and TanStack attacks both targeted CI runners, not production servers. If your security monitoring does not cover GitHub Actions runner behavior, npm lifecycle script execution in CI, and outbound network traffic from build pipelines, you have a significant blind spot.

The Mindset Shift That Matters

There is a comfortable assumption embedded in how most teams think about dependencies: that the packages we install are inert artifacts. Files. That npm install is like dragging a ZIP file into a folder.

That assumption is no longer safe.

Package installation is code execution. It happens with your credentials. It happens with access to your secrets. It happens in your CI environment, which has access to your production infrastructure. And it happens automatically, at scale, across every developer machine and pipeline run in your organization.

The good news is that most of the mitigations are not hard. npm ci instead of npm install in CI. A seven-line config change to enable minimum release age. A onlyBuiltDependencies list in pnpm. Socket.dev on your repositories. These are not expensive enterprise initiatives — they are configuration decisions that take an afternoon to roll out across a team.

The teams that got hit by the Axios attack in March 2026, and by TanStack in May 2026, were not careless. They used OIDC trusted publishing. They had two-factor authentication enabled. They ran SLSA provenance checks. Those controls protected against the attack classes they were designed for. They were not sufficient for the attack classes that arrived.

Waiting seven days before installing a newly published version costs almost nothing. It would have prevented both.

What is one change you are going to make to your dependency workflow after reading this? Tell me in the comments — I read every one.

Recap: What You Should Take Away

npm install executes code — via lifecycle hooks — with your permissions, before your application runs
Malicious versions are typically detected within hours of publication, not days. A seven-day install gate means you install after the detection window, not inside it
All four major package managers (npm, pnpm, Yarn, Bun) now support minimum release age configuration natively. It takes minutes to enable
Use npm ci (or equivalent frozen lockfile installs) in all CI pipelines. If you are not doing this, fix it today before everything else
pnpm's onlyBuiltDependencies is one of the most underused security controls in the ecosystem
Private registries with quarantine buffers enforce minimum-age policies organization-wide, not just per-developer
SBOM generation gives you a dependency audit trail — you cannot detect what changed if you never tracked what existed
The threat is not hypothetical. Axios, TanStack, Bitwarden CLI, Trivy, and over 170 packages hit in a single day in May 2026 are documented incidents with real organizational impact

Bonus Tips

Tip 1: Add audit=true to your .npmrc and npm audit --audit-level=high as a CI step. It will not catch zero-day malicious packages, but it catches known CVEs that have not been applied.

Tip 2: Review which packages in your tree are requesting install-time script execution. Run npm install --ignore-scripts once, then look at what breaks. Whatever breaks legitimately is your real onlyBuiltDependencies list.

Tip 3: If you use Renovate, set minimumReleaseAge in your Renovate config as well as your package manager config. Belt and suspenders — a version that has not passed the age gate should not even generate an update PR.

Tip 4: Check your CI runners for unexpected outbound connections. Most legitimate build steps do not need to reach arbitrary external endpoints. A network egress policy on your build environment is one of the few controls that would have limited the damage from the Axios attack even if the malicious version was already installed.

What Did You Think?

I want to hear from you directly. Have you already added a minimum release age gate to your projects? Are you using pnpm with onlyBuiltDependencies? Did this change how you think about npm install?

Drop a comment below — even a quick "already doing this" or "had no idea" helps me understand what the community is actually experiencing.

Found this useful? Share it with a teammate who still runs npm install without thinking twice. That is the audience that needs it most.

Want more articles like this on JavaScript security, platform engineering, and frontend architecture? Follow me here on Medium, or subscribe to my newsletter where I publish one practical insight every week.

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

Stop Using JavaScript for Styles: CSS if() Function Brings Native Conditional Logic to Stylesheets

Rajat — Wed, 06 May 2026 13:30:00 +0000

CSS Finally Gets Inline Conditional Logic With New if() Function

After 25+ Years, CSS Just Got Logic: The Game-Changing if() Function That's Rewriting Styling Rules

Have you ever felt like CSS was holding you back? You know that moment when you're writing yet another media query at the bottom of your stylesheet, or creating multiple CSS classes just to handle a simple conditional style, and you think, "There has to be a better way"?

Well, that frustration just became history. CSS now has genuine conditional logic with the new if() function, and it's changing everything we thought we knew about styling web applications.

For 25+ years, developers have been asking the same question on Stack Overflow: "Does CSS have if/else statements?" The answer was always no—until now. The W3C has finally added the if() function to the CSS 2025 snapshot, and Chrome 137+ already supports it. This isn't just another CSS trick; it's a fundamental shift in how we write styles.

By the end of this article, you'll understand how the if() function works, when to use it over traditional approaches, and how to implement it in real-world scenarios with working code examples. You'll also learn about browser support strategies and future-proofing your styles.

Let's dive into the feature that's making CSS feel like a true programming language.

What Is the CSS if() Function?

Think about how you write conditional logic in JavaScript:

const color = isDarkMode ? '#ffffff' : '#000000';

The if() function brings that same inline conditional thinking to CSS. Instead of scattering your conditional logic across multiple media queries, classes, or JavaScript functions, you can now write it directly in your property values.

Here's the basic syntax:

.element {
  property: if(
    condition-1: value-1;
    condition-2: value-2;
    else: fallback-value;
  );
}

Notice the semicolons separating each condition-value pair, and the colon separating conditions from values. This syntax feels familiar if you've worked with ternary operators, but it's uniquely CSS.

The Three Types of Conditions

The if() function works with three powerful condition types:

1. Style Queries: Check Custom Property Values

Style queries let you check the value of CSS custom properties (variables) and apply different styles accordingly:

.card {
  --theme: dark;

  background-color: if(
    style(--theme: dark): #1a1a1a;
    style(--theme: light): #ffffff;
    else: #f0f0f0;
  );

  color: if(
    style(--theme: dark): #e0e0e0;
    else: #333333;
  );
}

This is incredibly powerful. You can set a single custom property and let the entire component's styling cascade from that decision. No more class-based theme switching with dozens of overrides.

2. Media Queries: Inline Responsive Design

Instead of writing separate media query blocks, bring your responsive logic inline:

.hero-title {
  font-size: if(
    media(width > 1200px): calc(3rem + 2vw);
    media(width > 768px): 2.5rem;
    else: 2rem;
  );

  padding: if(
    media(width > 768px): 4rem 2rem;
    else: 2rem 1rem;
  );
}

See what happened there? Your responsive behavior lives right next to the properties they affect. No more scrolling to the bottom of your file to find that one media query that's breaking your layout.

3. Feature Queries: Progressive Enhancement Built-In

Test for browser feature support and provide fallbacks automatically:

.gradient-box {
  background: if(
    supports(color: oklch(0.7 0.185 232)): oklch(0.7 0.185 232);
    supports(color: lab(70% 30 -45)): lab(70% 30 -45);
    else: #00adf3;
  );
}

This eliminates the need for separate @supports rules while keeping your code organized and maintainable.

Real-World Example: A Dynamic Theme System

Let's build something practical—a component that adapts to user preferences without JavaScript. Here's a complete card component with dynamic theming:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Dynamic Theme Card</title>
  <style>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    body {
      font-family: system-ui, -apple-system, sans-serif;
      padding: 2rem;
      background: #f5f5f5;
    }

    .theme-controls {
      margin-bottom: 2rem;
      display: flex;
      gap: 1rem;
    }

    .theme-btn {
      padding: 0.75rem 1.5rem;
      border: none;
      border-radius: 8px;
      cursor: pointer;
      font-weight: 600;
      transition: transform 0.2s;
    }

    .theme-btn:hover {
      transform: translateY(-2px);
    }

    .card {
      --theme: ocean;
      max-width: 600px;
      padding: 2rem;
      border-radius: 12px;
      transition: all 0.3s ease;

      background: if(
        style(--theme: ocean): linear-gradient(135deg, #667eea 0%, #764ba2 100%);
        style(--theme: sunset): linear-gradient(135deg, #f093fb 0%, #f5576c 100%);
        style(--theme: forest): linear-gradient(135deg, #4facfe 0%, #00f2fe 100%);
        else: linear-gradient(135deg, #a8edea 0%, #fed6e3 100%);
      );

      color: if(
        style(--theme: ocean): #ffffff;
        style(--theme: sunset): #ffffff;
        style(--theme: forest): #003d3d;
        else: #333333;
      );

      box-shadow: if(
        style(--theme: ocean): 0 20px 60px rgba(102, 126, 234, 0.4);
        style(--theme: sunset): 0 20px 60px rgba(245, 87, 108, 0.4);
        style(--theme: forest): 0 20px 60px rgba(79, 172, 254, 0.4);
        else: 0 10px 30px rgba(0, 0, 0, 0.1);
      );
    }

    .card-header {
      margin-bottom: 1rem;
    }

    .card-title {
      font-size: if(
        media(width > 768px): 2.5rem;
        else: 2rem;
      );

      font-weight: 700;
      margin-bottom: 0.5rem;
    }

    .card-subtitle {
      opacity: if(
        style(--theme: forest): 0.7;
        else: 0.85;
      );

      font-size: 1.125rem;
    }

    .card-content {
      line-height: 1.6;
      margin-bottom: 1.5rem;
    }

    .card-footer {
      display: flex;
      gap: 1rem;
    }

    .btn {
      padding: 0.75rem 1.5rem;
      border: none;
      border-radius: 8px;
      font-weight: 600;
      cursor: pointer;
      transition: all 0.2s;

      background: if(
        style(--theme: ocean): rgba(255, 255, 255, 0.2);
        style(--theme: sunset): rgba(255, 255, 255, 0.2);
        style(--theme: forest): rgba(0, 61, 61, 0.1);
        else: rgba(0, 0, 0, 0.1);
      );

      color: inherit;

      border: if(
        style(--theme: ocean): 2px solid rgba(255, 255, 255, 0.5);
        style(--theme: sunset): 2px solid rgba(255, 255, 255, 0.5);
        style(--theme: forest): 2px solid rgba(0, 61, 61, 0.3);
        else: 2px solid rgba(0, 0, 0, 0.2);
      );
    }

    .btn:hover {
      transform: translateY(-2px);

      background: if(
        style(--theme: ocean): rgba(255, 255, 255, 0.3);
        style(--theme: sunset): rgba(255, 255, 255, 0.3);
        style(--theme: forest): rgba(0, 61, 61, 0.2);
        else: rgba(0, 0, 0, 0.15);
      );
    }
  </style>
</head>
<body>
  <div class="theme-controls">
    <button class="theme-btn" onclick="setTheme('ocean')" style="background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); color: white;">Ocean Theme</button>
    <button class="theme-btn" onclick="setTheme('sunset')" style="background: linear-gradient(135deg, #f093fb 0%, #f5576c 100%); color: white;">Sunset Theme</button>
    <button class="theme-btn" onclick="setTheme('forest')" style="background: linear-gradient(135deg, #4facfe 0%, #00f2fe 100%); color: #003d3d;">Forest Theme</button>
  </div>

  <div class="card" id="themeCard">
    <div class="card-header">
      <h2 class="card-title">Welcome to CSS if() Functions</h2>
      <p class="card-subtitle">Dynamic theming without JavaScript overhead</p>
    </div>

    <div class="card-content">
      <p>This card demonstrates the power of CSS if() functions with inline conditional logic. Click the theme buttons above to see the entire component transform—colors, shadows, borders, and opacity all update based on a single custom property.</p>
      <p style="margin-top: 1rem;">Notice how responsive the design is: the title size adjusts based on viewport width, and all theme variations remain perfectly readable across different screen sizes.</p>
    </div>

    <div class="card-footer">
      <button class="btn">Learn More</button>
      <button class="btn">Get Started</button>
    </div>
  </div>

  <script>
    function setTheme(theme) {
      document.getElementById('themeCard').style.setProperty('--theme', theme);
    }
  </script>
</body>
</html>

Open this in Chrome 137+ and watch how clicking theme buttons transforms the entire card. One custom property controls everything: gradient backgrounds, text colors, shadows, button styles, and even opacity values.

The magic here is that all the conditional logic lives in CSS, not JavaScript. The JS only sets a single custom property value. Everything else is declarative, performant, and maintainable.

When to Use if() Over Traditional Approaches

You might be thinking, "I can already do this with media queries and classes." You're right, but here's when if() shines:

Use if() when:

You need property-level conditions rather than entire rule blocks
Your conditions are based on custom property values that change dynamically
You want inline responsive tweaks without separate media queries
You're building component-level themes that need tight coupling with their properties

Stick with traditional approaches when:

You're applying many different properties based on a single condition (media queries are cleaner)
You need broad layout changes affecting multiple elements (container queries excel here)
You're working with older browser support requirements

Think of it this way: media queries are great for layout orchestration, while if() excels at granular property decisions.

Browser Support Reality Check

Here's the situation as of December 2025: if() is supported in Chrome 137+, Edge 137+, and Chrome for Android. Firefox and Safari are still in development.

This means you need a progressive enhancement strategy:

.element {
  /* Baseline style that works everywhere */
  background: #00adf3;
  color: #ffffff;
  padding: 1rem;

  /* Enhanced styles for supporting browsers */
  background: if(
    style(--theme: dark): #1a1a1a;
    style(--theme: light): #ffffff;
    else: #00adf3;
  );

  color: if(
    style(--theme: dark): #e0e0e0;
    style(--theme: light): #333333;
    else: #ffffff;
  );
}

Browsers that don't support if() will ignore those declarations and stick with your baseline styles. Browsers with support get the enhanced experience. This is CSS's built-in progressive enhancement at work.

What's your current strategy for handling browser compatibility? Drop a comment and let's discuss different approaches.

Advanced Pattern: Nesting if() Functions

Here's where things get really interesting. You can nest if() functions for complex conditional logic:

.notification {
  --status: warning;
  --size: large;

  background: if(
    style(--status: error): if(
      style(--size: large): #dc2626;
      else: #ef4444;
    );
    style(--status: warning): if(
      style(--size: large): #d97706;
      else: #f59e0b;
    );
    style(--status: success): if(
      style(--size: large): #16a34a;
      else: #22c55e;
    );
    else: #6b7280;
  );

  padding: if(
    style(--size: large): 2rem;
    style(--size: medium): 1.5rem;
    else: 1rem;
  );

  font-size: if(
    style(--size: large): 1.25rem;
    style(--size: medium): 1rem;
    else: 0.875rem;
  );
}

This creates a notification system where both status and size affect the styling. The nested if() for background color checks status first, then size, providing four different shades of each status color.

Combining if() with calc() for Dynamic Sizing

Here's a pattern that's incredibly useful for fluid typography and spacing:

.responsive-section {
  --viewport-size: large;

  padding: if(
    media(width > 1200px): calc(4rem + 2vw);
    media(width > 768px): calc(3rem + 1.5vw);
    else: calc(2rem + 1vw);
  );

  font-size: if(
    style(--viewport-size: large): clamp(1.25rem, 2vw, 2rem);
    style(--viewport-size: medium): clamp(1rem, 1.5vw, 1.5rem);
    else: clamp(0.875rem, 1vw, 1.125rem);
  );
}

By combining if() with calc() and clamp(), you create sophisticated responsive sizing that adapts smoothly across breakpoints while maintaining readable constraints.

Common Pitfalls and How to Avoid Them

After working with if() extensively, here are the gotchas I've encountered:

1. Forgetting the semicolons between conditions

/* Wrong */
color: if(
  style(--theme: dark): #ffffff
  else: #000000
);

/* Correct */
color: if(
  style(--theme: dark): #ffffff;
  else: #000000;
);

2. Using commas instead of semicolons

CSS developers are used to comma-separated values. With if(), semicolons separate condition-value pairs. This trips people up constantly.

3. Not providing an else fallback

Without an else, if no conditions match, the property becomes invalid in supporting browsers. Always include that else clause for predictable behavior.

4. Over-nesting

While nesting is powerful, more than two levels becomes hard to read. Consider refactoring deeply nested if() functions into separate custom properties.

Have you hit any other issues? Share your experience in the comments so others can learn from it.

Performance Considerations

One question I get frequently: "Does if() impact performance?"

The answer is nuanced. The if() function evaluates at style computation time, just like any other CSS function. For most use cases, the performance impact is negligible—likely faster than JavaScript-based conditional styling.

However, be mindful when:

Using if() with expensive calculations inside calc() or complex gradients
Creating deeply nested if() functions with many conditions
Applying if() to animated properties that update frequently

In these scenarios, test performance with your browser's developer tools. Profile your styles and measure frame rates during animations.

The Future: Where if() Is Heading

The CSS Working Group isn't done yet. Here's what's on the horizon:

CSS @function: Custom functions that can use if() internally, creating reusable conditional logic

Enhanced style queries: Range checking within if() for more sophisticated conditions

Better integration with View Transitions: Conditional styles during page transitions

Expanded media query support: New media features specifically designed for if() usage

This is just the beginning. The if() function opens architectural possibilities we haven't fully explored yet.

Practical Tips for Adoption

Ready to start using if() in your projects? Here's my recommended approach:

Start small: Begin with a single component that has simple theming needs

Build a token system: Use CSS custom properties as your design tokens, then let if() orchestrate them

Document your conditions: Add comments explaining what each if() is checking—future you will appreciate it

Test progressively: Verify your baseline styles work, then enhance with if() for supporting browsers

Share learnings: The community is still discovering best practices—document what works for you

What would you build with if() if it had full browser support tomorrow? I'm genuinely curious about the creative applications developers will dream up.

Bonus Tips for Mastering if()

Tip 1: Use CSS Custom Properties as Feature Flags

:root {
  --enable-advanced-effects: true;
}

.component {
  backdrop-filter: if(
    style(--enable-advanced-effects: true): blur(10px);
    else: none;
  );
}

This pattern lets you toggle expensive effects across your entire app with one variable change.

Tip 2: Create Semantic Status Systems

Instead of hardcoding colors everywhere, use if() with semantic status properties:

.status-indicator {
  --status: idle;

  --status-color: if(
    style(--status: active): #22c55e;
    style(--status: pending): #f59e0b;
    style(--status: error): #ef4444;
    else: #6b7280;
  );

  background: var(--status-color);
  border-left: 4px solid var(--status-color);
}

Now your status colors are centralized and consistent.

Tip 3: Responsive Component Variants

.button {
  --variant: primary;

  padding: if(
    media(width > 768px): 1rem 2rem;
    else: 0.75rem 1.5rem;
  );

  background: if(
    style(--variant: primary): #3b82f6;
    style(--variant: secondary): #6b7280;
    style(--variant: danger): #ef4444;
    else: transparent;
  );

  color: if(
    style(--variant: primary): white;
    style(--variant: secondary): white;
    style(--variant: danger): white;
    else: currentColor;
  );
}

This creates a button system with variants that adapt responsively without writing separate component classes.

Recap: What We've Learned

The CSS if() function is a game-changer that brings real conditional logic to stylesheets for the first time:

Three condition types: style queries, media queries, and feature queries give you flexible conditional options
Inline logic: Keep your conditional styling right next to the properties they affect for better maintainability
Progressive enhancement: Build baseline styles first, then enhance with if() for supporting browsers
Performance-friendly: Evaluates at style computation time with minimal overhead
Semantic power: Combine with custom properties to create expressive, theme-aware components
Future-ready: Opens new architectural patterns as browser support grows

The syntax takes a bit of getting used to (remember those semicolons!), but once it clicks, you'll find yourself reaching for if() in situations where you previously needed JavaScript or complex CSS workarounds.

Whether you're building design systems, component libraries, or one-off projects, if() gives you a more elegant way to express conditional styling logic. Start experimenting with it in Chrome today, and you'll be ready when broader browser support arrives.

Found This Helpful?

If this article saved you from writing a hundred extra CSS classes or helped you understand how if() actually works, hit that clap button. The more claps this gets, the more developers discover this game-changing feature.

And seriously, don't be shy with those claps—you can clap up to 50 times. Every clap helps other developers find this content and learn about CSS's evolution.

Action Points:

Try the if() function in Chrome 137+ today with the code examples above
Build a small component using conditional styling to get comfortable with the syntax
Share this article with your team to discuss adoption strategies
Check the MDN documentation for the latest browser support updates
Experiment with nested if() functions to unlock advanced patterns

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

Temporal vs Date vs Intl: Which JavaScript API Should You Use? (Real Examples)

Rajat — Tue, 28 Apr 2026 13:30:00 +0000

Finally, a modern solution to JavaScript's 25-year-old date nightmare that actually makes sense

Picture this: You're debugging a production issue at 2 AM. The bug? JavaScript's Date object thinks February 30th is a valid date and happily rolls it over to March. Sound familiar?

Quick question for you: How many times have you pulled your hair out trying to handle timezones in JavaScript? Drop a number in the comments — I'm betting it's more than 10!

If you've ever written new Date() and immediately regretted it, you're not alone. JavaScript's Date API has been the bane of developers' existence since 1995. But here's the good news — the new Temporal API is here to save us all.

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

Why Date API fails us (with shocking examples)
How Temporal API fixes every major date problem
When to use Intl for formatting vs actual date logic
Real-world edge cases and which API handles them best
A decision framework for choosing the right tool

Let's dive in!

The Problem: Why Date API Makes Developers Cry

The Classic Timezone Disaster

Here's a fun one. Try this in your console right now:

// Creating a date in New York timezone
const nyDate = new Date('2024-03-10 02:30:00');
console.log(nyDate.toString());
// Result varies based on YOUR timezone! 

// Even worse - DST transitions
const beforeDST = new Date('2024-03-10 01:30:00');
const afterDST = new Date('2024-03-10 03:30:00');
console.log(afterDST - beforeDST);
// Should be 2 hours, but... surprise!

Tell me in the comments: Have you ever had a bug caused by DST transitions? I once had a scheduling system book meetings in the past because of this!

The Month Indexing Madness

// Pop quiz: What date is this?
const date = new Date(2024, 11, 25);
console.log(date.toDateString());
// "Wed Dec 25 2024" - because months are 0-indexed 

// But wait, days aren't!
const weirdDate = new Date(2024, 1, 30); // Feb 30?
console.log(weirdDate.toDateString());
// "Fri Mar 01 2024" - It just... rolls over?!

If this saved you from a future bug, hit that button! Your future self will thank you.

Enter Temporal API: The Hero We Deserve

The Temporal API isn't just an improvement — it's a complete reimagining of how dates should work. Let's see it in action:

Crystal Clear Date Creation

// With Temporal - what you see is what you get
const date = Temporal.PlainDate.from('2024-12-25');
console.log(date.toString()); // "2024-12-25"

// Months are FINALLY 1-indexed!
const christmas = Temporal.PlainDate.from({
  year: 2024,
  month: 12, // December is 12!
  day: 25
});

// Invalid dates throw errors instead of rolling over
try {
  const invalid = Temporal.PlainDate.from({
    year: 2024,
    month: 2,
    day: 30
  });
} catch (e) {
  console.log("Error: Invalid date!"); // This actually happens!
}

Timezone Handling That Actually Works

// Temporal separates dates, times, and timezones
const nyTime = Temporal.ZonedDateTime.from({
  timeZone: 'America/New_York',
  year: 2024,
  month: 3,
  day: 10,
  hour: 2,
  minute: 30
});

// Convert to LA time
const laTime = nyTime.withTimeZone('America/Los_Angeles');
console.log(laTime.hour); // Correctly adjusted!

// Duration calculations that make sense
const meeting = Temporal.PlainDateTime.from('2024-01-15T14:00');
const deadline = Temporal.PlainDateTime.from('2024-01-20T18:00');
const timeLeft = deadline.since(meeting);
console.log(`${timeLeft.days} days, ${timeLeft.hours} hours`);
// "5 days, 4 hours" - No manual math needed!

Quick check: Are you already thinking about refactoring your date code? Let me know what feature excites you most!

Intl API: The Formatting Specialist

While Temporal handles date logic, Intl shines at formatting. Here's when to use each:

Intl for Localization

const date = new Date('2024-12-25');

// Format for different locales
const usFormat = new Intl.DateTimeFormat('en-US').format(date);
console.log(usFormat); // "12/25/2024"

const ukFormat = new Intl.DateTimeFormat('en-GB').format(date);
console.log(ukFormat); // "25/12/2024"

const jpFormat = new Intl.DateTimeFormat('ja-JP').format(date);
console.log(jpFormat); // "2024/12/25"

// Relative time formatting (perfect for "3 days ago")
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
console.log(rtf.format(-3, 'day')); // "3 days ago"
console.log(rtf.format(2, 'hour')); // "in 2 hours"

Advanced Formatting Options

const options = {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short'
};

const formatter = new Intl.DateTimeFormat('en-US', options);
console.log(formatter.format(new Date()));
// "Monday, December 25, 2024 at 10:30 AM EST"

The Ultimate Comparison: Real-World Scenarios

Let's solve actual problems with each API:

Scenario 1: Calculate Business Days Between Dates

// Date API (painful)
function businessDaysDiff_Date(start, end) {
  let count = 0;
  let current = new Date(start);

  while (current <= end) {
    const day = current.getDay();
    if (day !== 0 && day !== 6) count++;
    current.setDate(current.getDate() + 1); // Mutates! 
  }
  return count;
}

// Temporal API (elegant)
function businessDaysDiff_Temporal(start, end) {
  let count = 0;
  let current = start;

  while (Temporal.PlainDate.compare(current, end) <= 0) {
    if (current.dayOfWeek <= 5) count++;
    current = current.add({ days: 1 }); // Immutable! 
  }
  return count;
}

Scenario 2: Schedule Recurring Meetings

//  Temporal shines here
function scheduleWeeklyMeeting(startDate, weeks) {
  const meetings = [];
  let current = Temporal.PlainDateTime.from(startDate);

  for (let i = 0; i < weeks; i++) {
    meetings.push(current);
    current = current.add({ weeks: 1 });
  }

  return meetings;
}

// With timezone awareness
function scheduleMeetingAcrossTimezones(dateTime, timezones) {
  const base = Temporal.ZonedDateTime.from({
    ...dateTime,
    timeZone: timezones[0]
  });

  return timezones.map(tz => ({
    timezone: tz,
    localTime: base.withTimeZone(tz).toPlainDateTime()
  }));
}

Try this yourself: Which timezone handling nightmare have you faced? Share your horror story below!

Unit Testing Your Date Logic

Since you're using Angular, here's how to test date functionality properly:

Testing with Jasmine/Karma

// date-utility.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { DateUtilityService } from './date-utility.service';

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

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

    // Mock current date for consistent tests
    jasmine.clock().install();
    jasmine.clock().mockDate(new Date('2024-01-15T12:00:00'));
  });

  afterEach(() => {
    jasmine.clock().uninstall();
  });

  it('should calculate business days correctly', () => {
    const start = Temporal.PlainDate.from('2024-01-15'); // Monday
    const end = Temporal.PlainDate.from('2024-01-19'); // Friday

    const result = service.calculateBusinessDays(start, end);
    expect(result).toBe(5);
  });

  it('should handle timezone conversions', () => {
    const nyMeeting = service.scheduleMeeting(
      '2024-01-15T15:00:00',
      'America/New_York'
    );

    const laTime = service.convertToTimezone(nyMeeting, 'America/Los_Angeles');
    expect(laTime.hour).toBe(12); // 3 PM NY = 12 PM LA
  });

  it('should format dates for different locales', () => {
    const date = new Date('2024-12-25');

    const usFormat = service.formatDate(date, 'en-US');
    expect(usFormat).toBe('12/25/2024');

    const ukFormat = service.formatDate(date, 'en-GB');
    expect(ukFormat).toBe('25/12/2024');
  });
});

Testing Edge Cases

it('should handle DST transitions', () => {
  // Test spring forward (lose an hour)
  const beforeDST = Temporal.ZonedDateTime.from({
    timeZone: 'America/New_York',
    year: 2024,
    month: 3,
    day: 10,
    hour: 1,
    minute: 30
  });

  const afterDST = beforeDST.add({ hours: 2 });
  expect(afterDST.hour).toBe(4); // 1:30 + 2 hours = 4:30 (not 3:30!)
});

it('should reject invalid dates', () => {
  expect(() => {
    Temporal.PlainDate.from({ year: 2024, month: 2, day: 30 });
  }).toThrow();
});

Bonus Tips: When to Use Which API

Here's your cheat sheet for making the right choice:

Use Native Date When:

You need basic timestamps (created_at, updated_at)
Working with legacy codebases
Quick prototypes (but plan to refactor!)
Third-party libraries require it

Use Temporal When:

Building new applications
Complex date arithmetic
Timezone-critical applications
Recurring events/scheduling
Need immutable date operations
Working with different calendar systems

Use Intl When:

Formatting dates for display
Localizing for multiple regions
Creating relative time displays ("2 hours ago")
Currency and number formatting (bonus use!)

Pro tip: You can combine them! Use Temporal for logic, Intl for display:

// Best of both worlds
const meeting = Temporal.ZonedDateTime.from({
  timeZone: 'America/New_York',
  year: 2024,
  month: 12,
  day: 25,
  hour: 14,
  minute: 30
});

// Use Temporal for logic
const reminder = meeting.subtract({ hours: 1 });

// Use Intl for display
const formatter = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'full',
  timeStyle: 'short'
});
console.log(formatter.format(reminder.toInstant().epochMilliseconds));

Quick Recap

Let's wrap up what we've learned:

Date API = 25 years of technical debt. Use only when you must.
Temporal API = The future of JavaScript dates. Immutable, timezone-aware, and actually makes sense.
Intl API = Your formatting Swiss Army knife. Perfect for localization.
Edge cases matter = DST, leap years, and invalid dates will haunt you. Temporal handles them all.
Test everything = Mock dates, test timezones, and validate edge cases.

The migration path is clear: start using Temporal for new features, keep Intl for formatting, and gradually phase out Date API.

Your Turn!

Alright, I've shared my date API battle scars — now it's your turn!

Drop a comment and tell me:

What's the weirdest date bug you've ever encountered?
Are you planning to use Temporal in your next project?
What date-related topic should I cover next?

Found this helpful? Give it a clap (or 50 — I won't judge!). Every clap helps other developers discover these tips!

Want more JavaScript deep dives? Follow me for weekly articles where I break down complex topics into digestible, practical guides. I promise to keep saving you from 2 AM debugging sessions!

Action Items for You:

[ ] Try the Temporal API in your browser console today
[ ] Refactor one Date function to use Temporal
[ ] Share this with a teammate who's struggling with dates
[ ] Follow me for next week's article on [Performance Optimization Secrets]

Let's build a community of developers who never have to suffer through date bugs again! See you in the comments!

Follow Me for More Angular & Frontend Goodness:

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

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

The Silent Killer, Angular Memory Leaks: How Dynamic Components Are Slowly Destroying Your Angular App's Performance

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

Why your perfectly working Angular app suddenly starts crawling—and how to fix it before users notice

Have you ever deployed an Angular app that worked flawlessly in development, only to have users complain about it getting slower and slower over time? You're not alone. There's a sneaky culprit that many Angular developers overlook: memory leaks from dynamic components.

Before we dive into the examples, a quick note: the code snippets provided here use syntax from earlier Angular versions.

Here's the thing that'll make you check your code right now: every time you create a dynamic component without properly cleaning it up, you're essentially creating a digital zombie that consumes memory forever. And unlike other bugs that crash your app immediately, memory leaks are silent assassins—they slowly drain performance until your users start abandoning your app.

What you'll learn by the end of this article:

Why dynamic components cause memory leaks (with real examples)
The exact cleanup pattern that prevents these leaks
How to write bulletproof unit tests for your cleanup logic
A bonus tip that most Angular devs miss

Quick question before we dive in: Have you ever noticed your Angular app getting sluggish after users interact with it for a while? Drop a comment—I'm genuinely curious about your experience!

The Problem: Dynamic Components That Never Die

Let's start with a real-world scenario. You're building a modal service that dynamically creates components:

@Injectable()
export class ModalService {
  private componentRef: ComponentRef<any>;

  openModal(component: any, data?: any) {
    // This creates a new component instance
    this.componentRef = this.viewContainerRef.createComponent(component);

    // Set up the component
    if (data) {
      this.componentRef.instance.data = data;
    }

    // Listen for close events
    this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });
  }

  closeModal() {
    // The WRONG way - this is where the leak happens!
    this.componentRef.destroy();
  }
}

Can you spot the problem?

Here's what's happening behind the scenes:

You create a component dynamically
You set up subscriptions and event listeners
You call destroy() on the component
BUT - the component reference itself is never cleared!

This means even though the component is "destroyed," JavaScript's garbage collector can't free up the memory because there's still a reference to it.

The Solution: Proper Cleanup Pattern

Here's the correct way to handle dynamic component cleanup:

@Injectable()
export class ModalService {
  private componentRef: ComponentRef<any> | null = null;

  openModal(component: any, data?: any) {
    // Clean up any existing modal first
    if (this.componentRef) {
      this.closeModal();
    }

    this.componentRef = this.viewContainerRef.createComponent(component);

    if (data) {
      this.componentRef.instance.data = data;
    }

    // Store subscription for cleanup
    const subscription = this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });

    // Store the subscription reference for cleanup
    this.componentRef.instance._subscription = subscription;
  }

  closeModal() {
    if (this.componentRef) {
      // Clean up subscription first
      if (this.componentRef.instance._subscription) {
        this.componentRef.instance._subscription.unsubscribe();
      }

      // Destroy the component
      this.componentRef.destroy();

      // Clear the reference - THIS IS THE KEY!
      this.componentRef = null;
    }
  }
}

The magic happens in these two lines:

this.componentRef.destroy();
this.componentRef = null; //  This prevents the memory leak!

Let's See It in Action: Complete Example

Here's a complete working example that shows both the problem and the solution:

// Dynamic component we'll create
@Component({
  selector: 'app-dynamic-modal',
  template: `
    <div class="modal-overlay" (click)="close()">
      <div class="modal-content" (click)="$event.stopPropagation()">
        <h3>{{title}}</h3>
        <p>{{message}}</p>
        <button (click)="close()">Close</button>
      </div>
    </div>
  `
})
export class DynamicModalComponent {
  @Input() title: string = '';
  @Input() message: string = '';
  @Output() onClose = new EventEmitter<void>();

  close() {
    this.onClose.emit();
  }
}

// Service that manages dynamic components
@Injectable()
export class DynamicModalService {
  private componentRef: ComponentRef<DynamicModalComponent> | null = null;

  constructor(
    private viewContainerRef: ViewContainerRef,
    private componentFactoryResolver: ComponentFactoryResolver
  ) {}

  openModal(title: string, message: string) {
    // Clean up existing modal
    this.closeModal();

    // Create new component
    const factory = this.componentFactoryResolver.resolveComponentFactory(DynamicModalComponent);
    this.componentRef = this.viewContainerRef.createComponent(factory);

    // Set up data
    this.componentRef.instance.title = title;
    this.componentRef.instance.message = message;

    // Listen for close event
    this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });
  }

  closeModal() {
    if (this.componentRef) {
      this.componentRef.destroy();
      this.componentRef = null; // Prevent memory leak
    }
  }
}

Writing Unit Tests for Memory Leak Prevention

Here's how to write unit tests that ensure your cleanup logic works correctly:

describe('DynamicModalService', () => {
  let service: DynamicModalService;
  let viewContainerRef: ViewContainerRef;
  let fixture: ComponentFixture<TestComponent>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [TestComponent, DynamicModalComponent],
      providers: [DynamicModalService]
    });

    fixture = TestBed.createComponent(TestComponent);
    viewContainerRef = fixture.componentInstance.viewContainerRef;
    service = TestBed.inject(DynamicModalService);
    service['viewContainerRef'] = viewContainerRef;
  });

  it('should clear component reference after closing modal', () => {
    // Arrange
    service.openModal('Test Title', 'Test Message');
    expect(service['componentRef']).toBeTruthy();

    // Act
    service.closeModal();

    // Assert - This is the key test!
    expect(service['componentRef']).toBeNull();
  });

  it('should not throw error when closing non-existent modal', () => {
    // This tests defensive programming
    expect(() => service.closeModal()).not.toThrow();
  });

  it('should clean up previous modal when opening new one', () => {
    // Arrange
    service.openModal('First Modal', 'First Message');
    const firstComponentRef = service['componentRef'];
    spyOn(firstComponentRef!, 'destroy');

    // Act
    service.openModal('Second Modal', 'Second Message');

    // Assert
    expect(firstComponentRef!.destroy).toHaveBeenCalled();
  });
});

// Test component for testing
@Component({
  template: '<div></div>'
})
class TestComponent {
  constructor(public viewContainerRef: ViewContainerRef) {}
}

If this testing approach just saved you hours of debugging, hit that clap button!

The Advanced Pattern: Using OnDestroy Hook

For more complex scenarios, implement the OnDestroy hook in your dynamically created components:

@Component({
  selector: 'app-advanced-dynamic',
  template: `<!-- your template -->`
})
export class AdvancedDynamicComponent implements OnDestroy {
  private subscriptions = new SubSink(); // Using SubSink library

  ngOnInit() {
    // Add all your subscriptions to SubSink
    this.subscriptions.add(
      this.someService.getData().subscribe(data => {
        // Handle data
      })
    );
  }

  ngOnDestroy() {
    // This automatically unsubscribes from all subscriptions
    this.subscriptions.unsubscribe();
  }
}

Bonus Tip: Memory Leak Detection

Want to catch memory leaks during development? Here's a trick most Angular devs don't know:

// Add this to your service for development
private debugComponentCount = 0;

openModal(component: any, data?: any) {
  this.debugComponentCount++;
  console.log(` Active components: ${this.debugComponentCount}`);

  // ... rest of your code
}

closeModal() {
  if (this.componentRef) {
    this.componentRef.destroy();
    this.componentRef = null;
    this.debugComponentCount--;
    console.log(`🧹 Cleaned up. Active components: ${this.debugComponentCount}`);
  }
}

If your debugComponentCount keeps growing, you've got a memory leak!

Recap: Your Action Plan

Here's what you need to do right now:

Audit your dynamic components - Search your codebase for .createComponent() calls
Check your cleanup logic - Make sure you're setting component references to null
Add unit tests - Test that your cleanup logic actually works
Use the debug tip - Add component counting during development
Implement OnDestroy - For complex components with multiple subscriptions

The bottom line: Memory leaks from dynamic components are silent killers, but they're incredibly easy to prevent once you know the pattern. The key is always setting your component reference to null after destroying it.

I want to hear from you!

What did you think? Have you encountered memory leaks in your Angular apps? Share your war stories in the comments—I love hearing about real-world debugging adventures!

Want more Angular tips like this? I share practical insights every week that can save you hours of debugging. Follow me to get notified when I publish new articles!

Found this helpful? If this article helped you catch a potential memory leak (or just taught you something new), smash that clap button so other developers can discover it too. Every clap helps!

Action point for you: Go check your codebase right now. Search for .createComponent() and see if you're properly cleaning up. Then come back and tell me what you found!

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

How to Configure a Proxy in Angular for API Calls (The Right Way)

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

Stop hardcoding API URLs and wrestling with CORS errors—here's the developer-friendly guide to Angular proxy configuration

Ever spent hours debugging CORS errors only to realize your API calls were hitting the wrong URL? Or worse, accidentally pushed production code with localhost:3000 hardcoded everywhere?

Here's a question for you: How many times have you opened the browser console to see that dreaded red text: "Access to XMLHttpRequest has been blocked by CORS policy"?

If you're nodding your head right now, you're in the right place. By the end of this article, you'll master Angular's proxy configuration and never have to worry about development API routing again. Plus, I'll show you some tricks that took me way too long to figure out.

Before we dive into the examples, a quick note: the code snippets provided here use syntax from earlier Angular versions.

Quick poll: Drop a comment below—what's your biggest API configuration headache? Let's commiserate together!

What You'll Learn Today

Why proxy configuration is a game-changer for local development
Step-by-step setup that actually works (with real examples)
How to handle multiple APIs like a pro
Unit testing strategies for proxied endpoints
Common pitfalls that will make you pull your hair out (and how to avoid them)

Ready? Let's dive in!

Why Do We Even Need a Proxy?

Picture this: You're building an Angular app that talks to a backend API. In production, everything lives on the same domain. But locally? Your Angular dev server runs on http://localhost:4200 while your API is on http://localhost:3000.

Enter the CORS monster.

Without a proxy, you're stuck with:

CORS errors everywhere
Hardcoded API URLs scattered across your codebase
Different configurations for dev, staging, and production
That one teammate who always forgets to change the URL back (we all know one)

The proxy is your superhero here. It intercepts API calls from your Angular app and forwards them to the right backend—no CORS drama, no URL juggling.

Setting Up Your First Proxy (The 5-Minute Version)

Let's get our hands dirty with some code. Here's the simplest proxy setup that'll solve 80% of your problems:

Step 1: Create the Proxy Configuration

Create a file called proxy.conf.json in your project root:

{
  "/api": {
    "target": "http://localhost:3000",
    "secure": false,
    "changeOrigin": true,
    "logLevel": "debug"
  }
}

What's happening here?

/api: Any request starting with /api gets proxied
target: Where to forward the requests
secure: Set to false for local development (true for HTTPS)
changeOrigin: Changes the origin header to match the target
logLevel: Shows proxy activity in your console (super helpful for debugging!)

Step 2: Update Your Angular Configuration

Modify your angular.json file:

{
  "serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": {
      "browserTarget": "your-app:build",
      "proxyConfig": "proxy.conf.json"
    }
  }
}

Step 3: Update Your Service Calls

Here's where the magic happens. In your Angular service:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class UserService {
  // Notice: No hardcoded domain! Just the path
  private apiUrl = '/api/users';

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>(this.apiUrl);
  }

  getUserById(id: number): Observable<User> {
    return this.http.get<User>(`${this.apiUrl}/${id}`);
  }
}

That's it! Run ng serve and your API calls will magically work without CORS issues.

Pro tip: Having issues? Check the console for proxy logs. The logLevel: "debug" setting is your best friend here.

Level Up: Handling Multiple APIs

Real-world apps rarely talk to just one API. Here's how to proxy multiple backends like a boss:

Advanced Proxy Configuration

Create a more sophisticated proxy.conf.js (yes, .js this time):

const PROXY_CONFIG = [
  {
    context: ['/api/v1'],
    target: 'http://localhost:3000',
    secure: false,
    changeOrigin: true,
    logLevel: 'debug'
  },
  {
    context: ['/api/v2'],
    target: 'http://localhost:3001',
    secure: false,
    changeOrigin: true,
    pathRewrite: {
      '^/api/v2': '/api'  // Rewrites /api/v2/users to /api/users
    }
  },
  {
    context: ['/auth'],
    target: 'https://auth.mycompany.com',
    secure: true,
    changeOrigin: true,
    headers: {
      'X-Custom-Header': 'MyApp'
    }
  }
];

module.exports = PROXY_CONFIG;

What's new here?

context: Array of paths to proxy (more flexible than single path)
pathRewrite: Modify the URL before forwarding
headers: Add custom headers to proxied requests

Update your angular.json to use the .js file:

"proxyConfig": "proxy.conf.js"

Question for you: How many different APIs does your current project talk to? Share in the comments—I'm curious about your architecture!

Writing Unit Tests for Proxied Services

Here's something most tutorials skip—how do you test services that use proxied endpoints? Let me show you:

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService } 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);
  });

  afterEach(() => {
    httpMock.verify(); // Ensure no outstanding requests
  });

  it('should fetch users from the proxied endpoint', () => {
    const mockUsers = [
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' }
    ];

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

    // Note: We're testing against the relative URL, not the proxied target
    const req = httpMock.expectOne('/api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);
  });

  it('should handle errors gracefully', () => {
    const errorMessage = 'Server error';

    service.getUsers().subscribe(
      () => fail('Should have failed'),
      error => {
        expect(error.status).toBe(500);
      }
    );

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

Key testing insights:

Test against the relative URLs (/api/users), not the proxied target
Use HttpClientTestingModule to mock HTTP calls
Always verify no outstanding requests with httpMock.verify()

Common Pitfalls and How to Dodge Them

After helping dozens of developers debug proxy issues, here are the gotchas that trip everyone up:

1. The "It Works on My Machine" Problem

Issue: Proxy works locally but fails in Docker/CI.

Solution:

// proxy.conf.js
const target = process.env.API_URL || 'http://localhost:3000';

const PROXY_CONFIG = [
  {
    context: ['/api'],
    target: target,
    // ... rest of config
  }
];

2. WebSocket Connections Failing

Issue: Real-time features break with proxy.

Solution:

{
  "/socket.io": {
    "target": "http://localhost:3000",
    "ws": true,  // Enable WebSocket proxy
    "secure": false,
    "changeOrigin": true
  }
}

3. The Cookie Monster

Issue: Authentication cookies not being sent.

Solution:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  secure: false,
  changeOrigin: true,
  cookieDomainRewrite: "localhost",  // Rewrite cookie domain
  withCredentials: true
}

4. POST Requests Hanging Forever

Issue: Large POST requests timeout.

Solution:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  secure: false,
  changeOrigin: true,
  onProxyReq: (proxyReq, req, res) => {
    // Fix body-parser issues
    if (req.body) {
      const bodyData = JSON.stringify(req.body);
      proxyReq.setHeader('Content-Length', Buffer.byteLength(bodyData));
      proxyReq.write(bodyData);
    }
  }
}

If any of these saved you from a debugging nightmare, hit that clap button! Others need to see this too.

Bonus Tips for Power Users

1. Environment-Specific Proxy Configurations

Create multiple proxy configs for different environments:

├── proxy/
│   ├── proxy.local.conf.js
│   ├── proxy.staging.conf.js
│   └── proxy.docker.conf.js

Then in package.json:

{
  "scripts": {
    "start:local": "ng serve --proxy-config proxy/proxy.local.conf.js",
    "start:staging": "ng serve --proxy-config proxy/proxy.staging.conf.js",
    "start:docker": "ng serve --proxy-config proxy/proxy.docker.conf.js"
  }
}

2. Dynamic Proxy Bypass

Sometimes you need to skip the proxy for certain requests:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  bypass: function(req, res, proxyOptions) {
    // Skip proxy for health checks
    if (req.url === '/api/health') {
      return '/health.json';  // Serve local file instead
    }
    // Skip proxy for specific headers
    if (req.headers.accept?.includes('html')) {
      return '/index.html';
    }
  }
}

3. Request/Response Interceptors

Debug or modify requests on the fly:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  onProxyReq: (proxyReq, req, res) => {
    // Add authentication header
    proxyReq.setHeader('X-Special-Proxy-Header', 'foobar');
    console.log('Proxying:', req.method, req.url);
  },
  onProxyRes: (proxyRes, req, res) => {
    // Log response status
    console.log('Response:', proxyRes.statusCode);
    // Add custom header to response
    proxyRes.headers['X-Proxy-Time'] = new Date().toISOString();
  }
}

Quick Recap

Let's wrap up what we've covered:

asic proxy setup takes just 5 minutes and solves CORS issues instantly

Multiple API handling with advanced proxy configurations

Unit testing strategies that work with proxied endpoints

Common pitfalls and their battle-tested solutions

Power user tips for production-ready proxy setups

The proxy configuration might seem like a small detail, but it's one of those things that, once set up properly, makes your entire development experience smoother. No more CORS errors, no more hardcoded URLs, just clean, maintainable code.

Your Turn!

Alright, I've shown you my proxy tricks—now I want to hear from you!

What's your biggest API integration challenge? Drop a comment below. I read every single one and often write follow-up articles based on your questions.

Did this save you from CORS hell? Smash that clap button (you can clap up to 50 times—I won't judge if you go wild!)

Want more Angular deep-dives? I publish practical Angular guides every week. Follow me to get notified when the next one drops.

Challenge: Try setting up a proxy for your current project and share your before/after experience in the comments. Best story gets a shoutout in my next article!

Keep Learning

If you enjoyed this, you'll love these related articles:

"Angular Performance: 5 OnPush Change Detection Tricks"
"RxJS Patterns That Will Change How You Handle API Calls"
"The Complete Guide to Angular Environments (Dev, Staging, Production)"

P.S. Still stuck with a proxy issue? Drop your specific problem in the comments with the hashtag #ProxyHelp and I'll personally help you debug it. We're all in this 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
✍️ Reddit — Developer blog posts & tech discussions

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

DEV Community: Rajat

Angular's Injection Context: The Hidden Runtime Environment Every Developer Should Master

Understanding When and Where Angular's Dependency Injection Actually Works

What Is Dependency Injection Context?

Where Injection Context Exists

1. Class Constructors

2. Field Initializers

3. Factory Functions in Providers

4. Functional Guards and Resolvers

Running Code in Injection Context: runInInjectionContext

The Problem

The Solution

Real-World Use: Service Method with Dynamic Injection

Writing Defensive Code: assertInInjectionContext

Debugging Injection Context

Signals and Injection Context

Reactive Service with a Signal

Computed Signal from Multiple Injected Services

Unit Testing Code That Uses Injection Context

Testing a Component with inject()

Testing a Utility That Calls inject()

Testing a Functional Guard

Best Practices

Summary

Follow Me for More Angular & Frontend Goodness:

Your Next npm install Could Already Be Running Malware

Why installing packages the moment they drop is now a security incident waiting to happen

Why the npm Ecosystem Became a Target

What Actually Happens When You Run npm install

The Incident Record: What Has Already Happened

Why "Wait Before Installing" Is Not Paranoia

How Every Major Package Manager Now Supports This

npm vs Yarn vs pnpm: How Lifecycle Scripts Behave Differently

Practical Defensive Workflows

Enterprise Governance: Going Beyond the Developer Laptop

The Mindset Shift That Matters

Recap: What You Should Take Away

Suggested Further Reading

Bonus Tips

What Did You Think?

Follow Me for More Angular & Frontend Goodness:

Stop Using JavaScript for Styles: CSS if() Function Brings Native Conditional Logic to Stylesheets

CSS Finally Gets Inline Conditional Logic With New if() Function

After 25+ Years, CSS Just Got Logic: The Game-Changing if() Function That's Rewriting Styling Rules

What Is the CSS if() Function?

The Three Types of Conditions

1. Style Queries: Check Custom Property Values

2. Media Queries: Inline Responsive Design

3. Feature Queries: Progressive Enhancement Built-In

Real-World Example: A Dynamic Theme System

When to Use if() Over Traditional Approaches

Browser Support Reality Check

Advanced Pattern: Nesting if() Functions

Combining if() with calc() for Dynamic Sizing

Common Pitfalls and How to Avoid Them

Performance Considerations

The Future: Where if() Is Heading

Practical Tips for Adoption

Bonus Tips for Mastering if()

Recap: What We've Learned

Found This Helpful?

And seriously, don't be shy with those claps—you can clap up to 50 times. Every clap helps other developers find this content and learn about CSS's evolution.

Follow Me for More Angular & Frontend Goodness:

Temporal vs Date vs Intl: Which JavaScript API Should You Use? (Real Examples)

Finally, a modern solution to JavaScript's 25-year-old date nightmare that actually makes sense

The Problem: Why Date API Makes Developers Cry

The Classic Timezone Disaster

The Month Indexing Madness

Enter Temporal API: The Hero We Deserve

Crystal Clear Date Creation

Timezone Handling That Actually Works

Intl API: The Formatting Specialist

Intl for Localization

Advanced Formatting Options

The Ultimate Comparison: Real-World Scenarios

Scenario 1: Calculate Business Days Between Dates

Scenario 2: Schedule Recurring Meetings

Unit Testing Your Date Logic

Testing with Jasmine/Karma

Testing Edge Cases

Running Code in Injection Context: `runInInjectionContext`

Writing Defensive Code: `assertInInjectionContext`

Testing a Component with `inject()`

Testing a Utility That Calls `inject()`

What Actually Happens When You Run `npm install`