DEV Community: Rajat

The OnPush Default Has Arrived: A Practical Guide to Angular 22's Biggest Shift - Here's What Changes (Part 1)

Rajat — Wed, 17 Jun 2026 13:30:00 +0000

A practical, code-first tour of Angular 22's biggest change-detection shift — what breaks, what doesn't, and how to migrate without surprises*

Quick question before we get into it: when was the last time you added ChangeDetectionStrategy.OnPush to a component, ran the app, and then spent the next ten minutes wondering why a value on screen just... stopped updating?

If you've written Angular for more than a few months, that probably rings a bell. OnPush has always been the "fast lane" — fewer wasted checks, better performance — but it came with a tax. You had to opt in, understand exactly what triggers a re-render, and occasionally sprinkle markForCheck() around like seasoning when something didn't refresh the way you expected.

Angular 22 just changed that deal. As of this release, every component that doesn't explicitly set a change detection strategy now runs under OnPush automatically. The fast lane is now just... the lane.

This is part 1 of a series where we're going through Angular 22 feature by feature. This one is all about the change-detection shift specifically — what changed, why now, what can quietly break, and how to migrate without losing a weekend to it.

By the end, you'll know:

What actually changes when OnPush becomes the default — and what doesn't
Why ChangeDetectionStrategy.Default got renamed to Eager, and why that name makes more sense
The one scenario that can silently break your app after upgrading, with zero console errors
Why signals and OnPush are basically built for each other
Where this fits into Angular's bigger move toward zoneless apps
A step-by-step ng update walkthrough so you're not migrating blind

That's a lot of ground, but I promise it's more "oh, that makes sense" than "oh no." Let's get into it.

If you want the rest of this series as it drops — eleven more parts covering everything else in this release — following me here on Medium is the easiest way to not miss one.

Before we dive into the examples, a quick note: these snippets are meant purely for understanding the concepts in this release. Angular 22 only shipped on June 3, 2026, so a couple of the APIs we'll touch — especially the experimental debounced() helper — may still see small signature tweaks in patch releases. Always check the official Angular documentation for the exact, current syntax before shipping any of this to production.

OnPush Becomes the Default Change Detection Strategy

Let's start with the headline change.

Through Angular 21, if you wrote a component and didn't specify a changeDetection property, Angular used what was then called the Default strategy: on every change-detection cycle, it walked the entire component subtree and checked every binding — whether or not anything inside had actually changed. It worked, but in large component trees, it meant a lot of checks that found nothing to update.

As of Angular 22, that's flipped. Any @Component without an explicit changeDetection property now uses ChangeDetectionStrategy.OnPush automatically. No decorator property, no extra import, nothing to opt into.

Here's what that looks like in practice:

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

@Component({
  selector: 'app-counter',
  // No changeDetection property here -- this component is OnPush
  // automatically in Angular 22.
  template: `
    <button (click)="increment()">Count: {{ count() }}</button>
  `,
})
export class CounterComponent {
  readonly count = signal(0);

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

Nothing in that file mentions OnPush — and yet it behaves exactly like an OnPush component always has: Angular skips this subtree unless something inside explicitly says "something changed." Here, the signal read inside {{ count() }} and the (click) event binding both qualify, so the button updates correctly with zero extra ceremony.

If you've got a component that genuinely needs the old "check everything, every time" behavior — say, it wraps a third-party widget that mutates the DOM behind Angular's back — you can still opt into that explicitly:

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

@Component({
  selector: 'app-legacy-widget',
  changeDetection: ChangeDetectionStrategy.Eager, // restores pre-v22 default behavior
  template: `...`,
})
export class LegacyWidgetComponent {}

Which brings us to that name — Eager. Where did Default go?

ChangeDetectionStrategy.Default Is Now ChangeDetectionStrategy.Eager

This is a small change with a satisfying reason behind it.

ChangeDetectionStrategy.Default was deprecated in Angular 21.2 and replaced by ChangeDetectionStrategy.Eager in Angular 22. Both values represent exactly the behavior they always did — check the whole subtree, every time — but the new name describes what the strategy does, instead of describing its position in a list.

Think about it from the framework's point of view: once OnPush became the default, calling the other option "Default" stopped making sense. Default... compared to what? The Angular team's own discussion on this rename put it nicely: Default used to mean "run change detection on me by default," not "I am the default strategy" — and that mismatch was confusing enough to be worth fixing.

So now you have two clearly named strategies:

OnPush — skip this subtree unless something explicitly marks it dirty (the new default)
Eager — check this subtree on every CD run, no matter what (the old default, now opt-in)

If your codebase had components explicitly setting ChangeDetectionStrategy.Default, ng update rewrites them for you:

// Before Angular 22
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Default,
  template: `...`,
})
export class OldComponent {}

// After ng update to Angular 22 -- same runtime behavior, new name
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `...`,
})
export class OldComponent {}

Here's the side-by-side that I think makes this click fastest:

	`Eager` (formerly `Default`)	`OnPush` (now the default)
Default through...	Angular 21	Angular 22 onward
Subtree checked when	Every CD run, unconditionally	Only when something marks it dirty
What marks it dirty	Nothing needed — always checked	Signal reads in the template, `async` pipe emissions, event bindings, input changes, `markForCheck()`
Best fit	Legacy code mutating plain fields directly	Signal-based, zoneless-ready components

Once you see it laid out this way, the rename stops feeling cosmetic — it's Angular finally calling things what they actually are.

Now, here's the part I really want you to slow down for, because it's the one that can bite you with zero warning.

Quick gut check before we move on: have you ever upgraded a dependency and had some piece of UI just... stop updating, with nothing in the console to explain why? Hold that thought — the next section is exactly that scenario, and I'd genuinely like to know in the comments afterward whether it matches what you ran into.

Impact on Existing Apps: The Good News and the One Catch

Let's get the good news out of the way first.

When you run ng update to Angular 22, the migration:

Adds changeDetection: ChangeDetectionStrategy.Eager to every component decorator that doesn't already specify a strategy — preserving your exact pre-upgrade behavior.
Renames any existing ChangeDetectionStrategy.Default to ChangeDetectionStrategy.Eager.
Leaves any existing ChangeDetectionStrategy.OnPush alone.

In other words: your own application code keeps working exactly as it did the moment before you upgraded. Angular doesn't silently flip your components to OnPush behind your back — it explicitly tags them as Eager so nothing changes at runtime. That's the whole point of the migration.

So where's the catch?

ng update can only rewrite the source files inside your project. It has no way to touch code that's already compiled and sitting inside node_modules.

Picture a third-party library — say, a price-ticker widget — that ships a component with no explicit changeDetection, and updates its template by writing to a plain class property inside an RxJS subscription:

// A library component published before Angular 22.
// No explicit changeDetection -- pre-v22 this ran "check everything"
// and worked fine.
@Component({
  selector: 'price-ticker',
  // No changeDetection set here.
  template: `<span>Latest price: {{ price }}</span>`,
})
export class PriceTickerComponent implements OnInit {
  price = 0;

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p; // plain field write -- Angular is never told to re-check
    });
  }
}

Before Angular 22, this worked because the component ran under Eager (then called Default) — Angular checked it on every cycle regardless. After you upgrade your app to Angular 22, that compiled library code still has no changeDetection property... which now means OnPush.

The result: the price stops updating on screen. No error. No console warning. No exception. The data is still arriving — prices$ is still emitting — but Angular was never told this component needs re-checking, so the template binding just freezes. If that same library does something imperative, like drawing onto a <canvas>, that keeps working fine. It's specifically Angular's template bindings — {{ }}, property bindings — that stop refreshing.

This is the single most important thing to test after upgrading: any third-party components that display live, push-based data.

If you hit this, you've got two options. The quick one, if you're still on zone.js:

export class PriceTickerComponent implements OnInit {
  price = 0;
  private cdr = inject(ChangeDetectorRef);

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p;
      this.cdr.markForCheck(); // works with zone.js; does not help in zoneless apps
    });
  }
}

And the one that actually fixes it for good — bridge the observable into a signal:

import { Component, DestroyRef, inject } from '@angular/core';
import { takeUntilDestroyed, toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'price-ticker',
  template: `<span>Latest price: {{ price() }}</span>`,
})
export class PriceTickerComponent {
  private feed = inject(PriceFeedService);
  private destroyRef = inject(DestroyRef);

  readonly price = toSignal(
    this.feed.prices$.pipe(takeUntilDestroyed(this.destroyRef)),
    { initialValue: 0 },
  );
}

toSignal() turns the observable into a signal, and writing to a signal that's read in the template automatically marks the component dirty. This works correctly under Eager or OnPush, with zone.js or without it — which is really the whole theme of this release.

A handful of other breaking changes landed in the same v22 release, most of them auto-migrated:

strictTemplates is now true by default in tsconfig.json — the migration adds strictTemplates: false if you weren't using it, so your build doesn't suddenly fail on new type errors.
Optional chaining in templates now matches TypeScript semantics: project?.author returns undefined (not null) when the chain breaks. The migration wraps affected expressions in $safeNavigationMigration(...) so you can review them on your own schedule. On the upside, the compiler can now correctly narrow project?.author inside an @if (project?.author) guard, so a lot of those defensive ?. usages can eventually come out entirely.
HttpClient now defaults to the Fetch-based backend. withFetch() is deprecated and removed by the migration — or replaced with withXhr() if you relied on upload-progress events, which Fetch doesn't support.
provideClientHydration() now enables incremental hydration by default; the migration adds withNoIncrementalHydration() if you weren't previously opted in.
The canMatch guard signature gains a mandatory third parameter, currentSnapshot — auto-migrated. paramsInheritanceStrategy now defaults to 'always' — this one is not auto-migrated, so check your router config if your app relies on the old 'emptyOnly' behavior.
The toolchain floor moved up: TypeScript 6 is required (5.9 and below are unsupported), and Node 20 support is dropped (Node 22+ required, Node 26 officially supported).

None of these are scary individually, but they're exactly the kind of thing that's easy to skim past in a changelog and then debug three weeks later. Worth a slow read through your ng update diff.

Signals and OnPush: Why They Were Basically Built for Each Other

Here's the conceptual thread that ties this whole release together.

Signals tell Angular what changed. OnPush tells Angular what to skip. Put those together and you get a complete fine-grained reactivity model — and that's really why making OnPush the default "completes" the signals story rather than being some unrelated cleanup item.

Under the old Eager strategy, this distinction was invisible, because everything got checked regardless of whether a signal changed. Under OnPush, it's the entire mechanism: when a signal that's read in a template updates, Angular marks that component dirty and schedules a CD run. If nothing marks it dirty, the subtree is skipped entirely. The signal is the dirty flag.

This is also why the Resource API graduating to stable in Angular 22 matters so much for this topic. resource, rxResource, and httpResource all move from experimental to stable in this release, and httpResource in particular is a genuinely pleasant way to fetch data reactively:

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
import { CurrencyPipe } from '@angular/common';

interface Product {
  id: number;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-list',
  imports: [CurrencyPipe],
  template: `
    @if (productsResource.isLoading()) {
      <p>Loading products...</p>
    }
    @if (productsResource.error()) {
      <p>Something went wrong loading products.</p>
    } @else {
      @for (product of productsResource.value(); track product.id) {
        <div>{{ product.name }} -- {{ product.price | currency }}</div>
      }
    }
  `,
})
export class ProductListComponent {
  readonly category = signal('electronics');

  // Re-fetches automatically whenever category() changes.
  readonly productsResource = httpResource<Product[]>(
    () => `/api/products?category=${this.category()}`,
    { defaultValue: [] },
  );
}

Notice there's no changeDetection here either — it's OnPush by default, and it doesn't need to be anything else. productsResource.value(), .isLoading(), and .error() are all signals, so reading them in the template is exactly the "tell Angular what changed" signal that OnPush needs.

Angular 22 also adds an experimental debounced() helper, which is handy for search-as-you-type without hand-rolling RxJS debounceTime. One thing worth getting right here: debounced() takes a reactive function that reads a signal — not the signal itself — and it returns a Resource, not another signal:

import { Component, signal, debounced } from '@angular/core';
import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-search',
  template: `
    <input (input)="query.set($any($event.target).value)" placeholder="Search products..." />

    @if (debouncedQuery.isLoading()) {
      <p>Waiting for you to stop typing...</p>
    }

    @for (result of results.value(); track result.id) {
      <div>{{ result.name }}</div>
    }
  `,
})
export class SearchComponent {
  readonly query = signal('');

  // Settles 300ms after `query` stops changing.
  // Note: debounced() takes a function that reads the signal, not the signal itself.
  readonly debouncedQuery = debounced(() => this.query(), 300);

  readonly results = httpResource<{ id: number; name: string }[]>(
    () => `/api/search?q=${this.debouncedQuery.value()}`,
    { defaultValue: [] },
  );
}

While the user is typing, debouncedQuery.isLoading() is true, and debouncedQuery.value() still holds the last settled value — so your results don't flicker on every keystroke, and httpResource only re-fires once things have actually stabilized. Since debounced() is still experimental in v22, double-check its exact signature against whatever patch version you've got installed before shipping it.

The Zoneless Future: Where This Fits in the Bigger Picture

If you've been keeping half an eye on Angular over the last couple of years, this release probably doesn't feel like it came out of nowhere — and it shouldn't. Here's the timeline:

Angular 18 introduced zoneless change detection as an experimental preview, behind provideExperimentalZonelessChangeDetection.
Angular 19 refined the zoneless APIs and added SSR support.
Angular 20.2 promoted provideZonelessChangeDetection() to stable.
Angular 21 made zoneless the default for new applications — ng new no longer wires up zone.js or calls provideZonelessChangeDetection() explicitly; it's simply the baseline. Existing apps keep zone.js until they choose to remove it.
Angular 22 makes OnPush the default change detection strategy — the piece that makes zoneless apps performant by default, not just functional.

Put together: "check everything via zone.js" is no longer the starting point for any new Angular app. Signals tell Angular what changed, OnPush skips everything that wasn't touched, and zoneless removes the layer that used to trigger a check on every async operation.

That last part is the one that trips people up, so let's make it concrete. In a zone.js app, this used to "just work":

// Worked in zone.js apps because zone.js patches setTimeout
// and triggers a CD run when the callback fires.
@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count }}</p>`,
})
export class AsyncDemoComponent {
  count = 0;

  ngOnInit() {
    setTimeout(() => {
      this.count++; // in a zoneless/OnPush app, the template silently won't update
    }, 1000);
  }
}

In a zoneless (or just plain OnPush) app, nothing tells Angular that count changed — setTimeout isn't patched, so there's no automatic CD trigger. The fix is the same one we used for the price ticker: make the state a signal.

@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count() }}</p>`,
})
export class AsyncDemoComponent {
  count = signal(0);

  ngOnInit() {
    setTimeout(() => {
      this.count.update(c => c + 1); // marks the view dirty -- re-renders correctly
    }, 1000);
  }
}

And if you want to go fully zoneless explicitly — still entirely valid, just no longer something a brand-new project needs to add by hand:

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideZonelessChangeDetection,
  provideBrowserGlobalErrorListeners,
} from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection(),
    provideBrowserGlobalErrorListeners(),
  ],
});

The rule of thumb going forward: change detection runs when a signal read in a template updates, the async pipe gets a new value, a template event fires, or something explicitly calls markForCheck() / ApplicationRef.tick(). Anything outside those four — a raw timer, a manual subscription writing to a plain field, a third-party library mutating data behind Angular's back — needs to be bridged into a signal to participate in rendering.

Migration Considerations: The ng update Walkthrough

Let's turn all of this into a checklist you can actually run through.

Step 1 — confirm your toolchain meets the new minimums:

node -v    # needs to be >= 22 (26 is supported)
npx tsc -v # needs to be >= 6.0

Step 2 — run the update. This applies every automatic migration we've covered: tagging unspecified components as Eager, renaming Default to Eager, the strictTemplates flag, the $safeNavigationMigration wrapper, the HTTP client changes, and the hydration flag.

ng update @angular/core@22 @angular/cli@22

Step 3 — build and run your full test suite. Most regressions from a change like this surface here, not in manual testing.

ng build
ng test

Step 4 — review what the migration actually touched, one concern at a time, instead of just accepting the diff:

grep -rn "ChangeDetectionStrategy.Eager" src/
grep -rn "\$safeNavigationMigration" src/
grep -rn "withNoIncrementalHydration\|withXhr" src/

That third command finds the optional-chaining wrappers and the HTTP/hydration flags — both things the migration added purely to preserve old behavior, and both good candidates to revisit once you've confirmed everything still works.

What ng update does not do for you:

It won't touch third-party node_modules packages — that's the "silent freeze" scenario from earlier. Your options are waiting for the library to update, wrapping its data source yourself with toSignal(), or pinning the dependency until you're ready to deal with it.
It won't change paramsInheritanceStrategy — if your app depends on the pre-v22 default, set it to 'emptyOnly' explicitly in your router config.
It won't convert your Eagertagged components to OnPush for you. That's a deliberate, per-component decision, and it usually starts with converting the component's state to signals.

That last point is worth walking through, because it's the actual "finish line" for each component. Here's one right after ng update — auto-migrated, behaving exactly as before:

// Right after ng update -- auto-generated, preserves old behavior.
@Component({
  selector: 'app-profile',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `<p>{{ user?.name }}</p>`,
})
export class ProfileComponent implements OnInit {
  user?: User;
  constructor(private userService: UserService) {}
  ngOnInit() {
    this.userService.getUser().subscribe(u => this.user = u);
  }
}

And here's the manual follow-up: convert the state to a signal, then delete the changeDetection line entirely.

import { Component, inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';

// Manual follow-up -- state is now a signal, no changeDetection override needed.
@Component({
  selector: 'app-profile',
  template: `<p>{{ user()?.name }}</p>`,
})
export class ProfileComponent {
  private userService = inject(UserService);
  readonly user = toSignal(this.userService.getUser());
}

No replacement annotation needed — OnPush is the default. That component is done.

Unit Testing OnPush and Signal-Based Components

A question I hear a lot when people first work with OnPush: "does this break my tests?" Mostly, no — but there's one habit worth building.

With TestBed, fixture.detectChanges() works exactly the same under OnPush as it always has when called manually — it forces a check regardless of whether the component thinks it's dirty. The difference only shows up when you're testing that an update happens automatically, without you calling detectChanges() yourself — which is precisely where signals help.

Here's a test for the CounterComponent from earlier:

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

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

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

    fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges();
  });

  it('renders the initial count', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 0');
  });

  it('updates the displayed count when the signal changes', () => {
    fixture.componentInstance.increment();
    fixture.detectChanges();

    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 1');
  });

  it('updates the count via a real click event', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');

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

    expect(button.textContent).toContain('Count: 1');
  });
});

A few things worth calling out:

We call fixture.detectChanges() after each state change — that's the test-environment equivalent of "Angular ran a CD cycle," and it's required regardless of strategy.
The third test fires a real DOM click, exercising the (click) event binding directly. This is the kind of test that used to quietly pass or quietly fail depending on which strategy a component happened to use — and now behaves consistently, because OnPush is the strategy either way.
If you're testing a component built around toSignal() and an observable (like our PriceTickerComponent), the same pattern applies: push a value through your mock service's subject, call fixture.detectChanges(), and assert on the rendered output. The signal write marks the view dirty; detectChanges() flushes it in the test.

If you're migrating your test setup to Vitest as part of this upgrade — Angular 22 continues investing here, including better fakeAsync support for teams making that move gradually — the same testing pattern applies. Only the runner and assertion syntax change, not the OnPush-related behavior itself.

Bonus Tips

A few smaller things that didn't need their own section but are worth keeping in your back pocket:

If a component "stops updating" after upgrading and you're not sure why, check whether it's coming from a third-party package first. The node_modules "silent freeze" is by far the most common surprise from this release.
You don't have to convert everything to signals on day one. Letting ng update mark your existing components as Eager and migrating component-by-component, on your own schedule, is exactly what the migration was designed to support.
Angular DevTools' signal graph is genuinely useful here, even if you're not pairing it with an AI agent — it's one of the fastest ways to see why a component did or didn't update.
When you do start converting components, prioritize the ones that already read from observables via async or manual subscriptions. Those are the most likely to have a "plain field write" hiding inside them, and toSignal() is almost always the cleanest fix.

Have you hit the "silent freeze" scenario yet, either during a test upgrade or in production? I'd genuinely love to know which library it was — drop it in the comments, it might save someone else a debugging session.

Recap

Here's the whole picture in one pass.

Angular 22 makes OnPush the default change detection strategy for any component that doesn't say otherwise. The old "check everything" behavior didn't disappear — it got renamed from Default to Eager, a name that actually describes what it does. ng update automatically tags your existing components as Eager so nothing changes at runtime on upgrade day, but it can't touch compiled code in node_modules — which is where the one real risk lives: third-party components with no explicit strategy and plain-field updates inside subscriptions can silently stop refreshing. The fix is always the same: bridge state into a signal with toSignal(), because a signal read in a template is exactly the "something changed" notification that OnPush — and zoneless apps — are built around. This release is also where the Resource API (resource, rxResource, httpResource) goes stable, and where the experimental debounced() helper shows up for search-as-you-type patterns.

If you take away one thing: go find the components that update via raw subscriptions or setTimeout, and start converting their state to signals. That single habit covers most of what this release changes for you.

What's your plan for rolling this out — run ng update and handle issues as they surface, or do a slower, component-by-component signal migration first? Tell me which one and why — I'm curious whether teams are converging on one approach.

What did you think?
Did this approach match how you're solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too — and if you've got a teammate who's about to upgrade to Angular 22, send this their way before they run into the silent-freeze surprise firsthand.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let's connect — find me on LinkedIn or GitHub and let's keep the conversation going.

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

Mastering Angular Library Entry Points: Build Modular, Tree-Shakeable Packages Like a Pro

Rajat — Wed, 10 Jun 2026 13:30:00 +0000

How to create secondary entry points in Angular libraries for better modularity and smaller bundles

Ever wondered why @angular/common has both @angular/common and @angular/common/http? Or why some Angular libraries let you import specific features without dragging in the entire package? That's the magic of multiple entry points — and today, you're going to master this powerful pattern.

Picture this: You've built an amazing Angular library with utilities, components, and services. But when developers install it, they're forced to import everything, even if they only need one small feature. Their bundle size explodes, and suddenly your "helpful" library becomes a performance bottleneck. Sound familiar?

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

Structure Angular libraries with multiple entry points for optimal tree-shaking
Create secondary entry points that work seamlessly in both standard and Nx workspaces
Reduce bundle sizes by up to 70% through smart library architecture
Avoid the common pitfalls that plague multi-entry-point libraries

Let's dive in and transform your monolithic library into a lean, modular powerhouse.

What Are Entry Points in Angular Libraries?

Think of entry points as different doors into your library. Just like a building might have a main entrance, a side door, and a loading dock — each serving different purposes — your Angular library can expose multiple entry points for different features.

When you create a standard Angular library, you get one default entry point:

// Importing from main entry point
import { MyService } from '@mycompany/awesome-lib';

But with secondary entry points, you can offer more granular imports:

// Importing from secondary entry points
import { UtilityService } from '@mycompany/awesome-lib/utilities';
import { SharedComponent } from '@mycompany/awesome-lib/components';

The Angular team uses this pattern extensively. Take a look at Angular Material — you don't import the entire library; you cherry-pick what you need:

import { MatButtonModule } from '@angular/material/button';
import { MatDialogModule } from '@angular/material/dialog';

Quick question for you: Have you ever hesitated to add a library to your project because you were worried about bundle size? Drop a comment below — I'd love to hear your experience!

Why Multiple Entry Points Matter

Before we jump into implementation, let's talk about why you should care. Here's what multiple entry points bring to the table:

The Good Stuff

Surgical tree-shaking: Only the code that's actually imported makes it into the final bundle
Faster builds: Smaller compilation units mean quicker build times
Better organization: Logical separation of features makes your library more maintainable
Gradual adoption: Developers can use parts of your library without committing to the whole thing

The Trade-offs

More configuration: Each entry point needs its own setup
Versioning complexity: All entry points share the same version number
Publishing overhead: More moving parts means more things that can go wrong

Now that we're on the same page about the why, let's get our hands dirty with the how.

Step-by-Step: Creating Your First Secondary Entry Point

I'm going to walk you through creating a secondary entry point in a real Angular library. We'll build a library with a main entry point for core features and a secondary entry point for utilities.

Step 1: Generate Your Library

First, let's create a new Angular workspace and library:

ng new my-workspace --no-create-application
cd my-workspace
ng generate library @mycompany/awesome-lib

Your initial structure looks like this:

my-workspace/
├── projects/
│   └── mycompany/
│       └── awesome-lib/
│           ├── src/
│           │   ├── lib/
│           │   └── public-api.ts
│           ├── ng-package.json
│           └── package.json

Step 2: Create the Secondary Entry Point Folder

Navigate to your library folder and create a new directory for your secondary entry point:

cd projects/mycompany/awesome-lib
mkdir utilities

Step 3: Configure the Secondary Entry Point

Create a ng-package.json file inside the utilities folder:

// projects/mycompany/awesome-lib/utilities/ng-package.json
{
  "$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
  "lib": {
    "entryFile": "public-api.ts"
  }
}

Step 4: Set Up the Public API

Create the public API file for your utilities:

// projects/mycompany/awesome-lib/utilities/public-api.ts
export * from './src/string-utils';
export * from './src/date-utils';
export * from './src/array-utils';

Step 5: Create Your Utility Services

Let's add some actual utilities. Here's a string utility service:

// projects/mycompany/awesome-lib/utilities/src/string-utils.ts
import { Injectable } from '@angular/core';

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

  capitalize(text: string): string {
    if (!text) return '';
    return text.charAt(0).toUpperCase() + text.slice(1).toLowerCase();
  }

  truncate(text: string, maxLength: number, suffix = '...'): string {
    if (text.length <= maxLength) return text;
    return text.slice(0, maxLength - suffix.length) + suffix;
  }

  slugify(text: string): string {
    return text
      .toLowerCase()
      .trim()
      .replace(/[^\w\s-]/g, '')
      .replace(/[\s_-]+/g, '-')
      .replace(/^-+|-+$/g, '');
  }
}

And a date utility service:

// projects/mycompany/awesome-lib/utilities/src/date-utils.ts
import { Injectable } from '@angular/core';

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

  formatRelativeTime(date: Date): string {
    const now = new Date();
    const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000);

    if (diffInSeconds < 60) return 'just now';
    if (diffInSeconds < 3600) return `${Math.floor(diffInSeconds / 60)} minutes ago`;
    if (diffInSeconds < 86400) return `${Math.floor(diffInSeconds / 3600)} hours ago`;
    return `${Math.floor(diffInSeconds / 86400)} days ago`;
  }

  isWeekend(date: Date): boolean {
    const day = date.getDay();
    return day === 0 || day === 6;
  }

  addBusinessDays(date: Date, days: number): Date {
    const result = new Date(date);
    let daysAdded = 0;

    while (daysAdded < days) {
      result.setDate(result.getDate() + 1);
      if (!this.isWeekend(result)) {
        daysAdded++;
      }
    }

    return result;
  }
}

Step 6: Update Package.json Exports

Modern Angular uses the exports field in package.json to define entry points. Update your library's package.json:

// projects/mycompany/awesome-lib/package.json
{
  "name": "@mycompany/awesome-lib",
  "version": "1.0.0",
  "peerDependencies": {
    "@angular/common": "^18.0.0",
    "@angular/core": "^18.0.0"
  },
  "dependencies": {
    "tslib": "^2.3.0"
  },
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "esm2022": "./esm2022/mycompany-awesome-lib.mjs",
      "esm": "./esm2022/mycompany-awesome-lib.mjs",
      "default": "./fesm2022/mycompany-awesome-lib.mjs"
    },
    "./utilities": {
      "types": "./utilities/index.d.ts",
      "esm2022": "./esm2022/utilities/mycompany-awesome-lib-utilities.mjs",
      "esm": "./esm2022/utilities/mycompany-awesome-lib-utilities.mjs",
      "default": "./fesm2022/mycompany-awesome-lib-utilities.mjs"
    }
  },
  "sideEffects": false
}

Step 7: Build and Verify

Build your library to ensure everything is configured correctly:

ng build @mycompany/awesome-lib

After building, check the dist folder. You should see separate bundles for each entry point:

dist/mycompany/awesome-lib/
├── fesm2022/
│   ├── mycompany-awesome-lib.mjs
│   └── mycompany-awesome-lib-utilities.mjs
├── utilities/
│   ├── index.d.ts
│   └── package.json
└── package.json

Implementing in an Nx Monorepo

Working with Nx? The process is slightly different but even more powerful. Nx provides generators that handle most of the boilerplate for you.

Generate a Library with Secondary Entry Points in Nx

npx nx generate @nx/angular:library my-lib --buildable --publishable --importPath=@mycompany/my-lib

# Add a secondary entry point
npx nx generate @nx/angular:library-secondary-entry-point --library=my-lib --name=utilities

Nx automatically configures the ng-package.json and updates your tsconfig paths. The structure looks like this:

libs/
└── my-lib/
    ├── src/
    │   ├── index.ts
    │   └── lib/
    ├── utilities/
    │   ├── src/
    │   │   ├── index.ts
    │   │   └── lib/
    │   └── ng-package.json
    └── ng-package.json

Here's a question for you: Are you using Nx in your projects? What's your favorite feature? Let me know in the comments!

Consuming Your Multi-Entry Point Library

Now for the fun part — using your shiny new library in an Angular application!

Install Your Library

If you've published to npm:

npm install @mycompany/awesome-lib

Or link locally for development:

npm link @mycompany/awesome-lib

Import from Different Entry Points

In your Angular components, you can now import from specific entry points:

// app.component.ts
import { Component, OnInit } from '@angular/core';
import { StringUtilsService } from '@mycompany/awesome-lib/utilities';
import { DateUtilsService } from '@mycompany/awesome-lib/utilities';

@Component({
  selector: 'app-root',
  template: `
    <div class="container">
      <h1>{{ title }}</h1>
      <p>Slugified: {{ slug }}</p>
      <p>Posted: {{ relativeTime }}</p>
    </div>
  `
})
export class AppComponent implements OnInit {
  title = 'Using Multiple Entry Points';
  slug = '';
  relativeTime = '';

  constructor(
    private stringUtils: StringUtilsService,
    private dateUtils: DateUtilsService
  ) {}

  ngOnInit() {
    this.slug = this.stringUtils.slugify(this.title);
    this.relativeTime = this.dateUtils.formatRelativeTime(
      new Date(Date.now() - 3600000)
    );
  }
}

The beauty here? If you only import from @mycompany/awesome-lib/utilities, the main library code never makes it into your bundle. Tree-shaking at its finest!

Writing Unit Tests for Your Library

Testing is crucial for library development. Let's add comprehensive tests for our utility services:

// string-utils.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { StringUtilsService } from './string-utils';

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

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

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

  describe('capitalize', () => {
    it('should capitalize first letter and lowercase rest', () => {
      expect(service.capitalize('hello WORLD')).toBe('Hello world');
    });

    it('should handle empty strings', () => {
      expect(service.capitalize('')).toBe('');
    });

    it('should handle single character strings', () => {
      expect(service.capitalize('a')).toBe('A');
    });
  });

  describe('truncate', () => {
    it('should truncate long text', () => {
      const text = 'This is a very long text that needs truncation';
      expect(service.truncate(text, 20)).toBe('This is a very lo...');
    });

    it('should not truncate short text', () => {
      expect(service.truncate('Short', 10)).toBe('Short');
    });

    it('should use custom suffix', () => {
      expect(service.truncate('Long text here', 10, '→')).toBe('Long text→');
    });
  });

  describe('slugify', () => {
    it('should create URL-friendly slugs', () => {
      expect(service.slugify('Hello World!')).toBe('hello-world');
      expect(service.slugify('  Angular & TypeScript  ')).toBe('angular-typescript');
      expect(service.slugify('100% Awesome!!!')).toBe('100-awesome');
    });
  });
});

And for the date utilities:

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

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

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

  describe('formatRelativeTime', () => {
    it('should format recent times as "just now"', () => {
      const now = new Date();
      expect(service.formatRelativeTime(now)).toBe('just now');
    });

    it('should format minutes ago correctly', () => {
      const thirtyMinutesAgo = new Date(Date.now() - 30 * 60 * 1000);
      expect(service.formatRelativeTime(thirtyMinutesAgo)).toBe('30 minutes ago');
    });

    it('should format hours ago correctly', () => {
      const twoHoursAgo = new Date(Date.now() - 2 * 60 * 60 * 1000);
      expect(service.formatRelativeTime(twoHoursAgo)).toBe('2 hours ago');
    });
  });

  describe('isWeekend', () => {
    it('should identify weekends correctly', () => {
      const saturday = new Date('2024-01-06'); // Saturday
      const sunday = new Date('2024-01-07'); // Sunday
      const monday = new Date('2024-01-08'); // Monday

      expect(service.isWeekend(saturday)).toBe(true);
      expect(service.isWeekend(sunday)).toBe(true);
      expect(service.isWeekend(monday)).toBe(false);
    });
  });

  describe('addBusinessDays', () => {
    it('should skip weekends when adding business days', () => {
      const friday = new Date('2024-01-05'); // Friday
      const result = service.addBusinessDays(friday, 3);

      // Should be Wednesday (skipping Saturday and Sunday)
      expect(result.getDay()).toBe(3);
      expect(result.getDate()).toBe(10);
    });
  });
});

Run your tests with:

ng test @mycompany/awesome-lib

Troubleshooting Common Issues

Let's address the gotchas that trip up most developers:

Issue 1: "Cannot find module '@mycompany/awesome-lib/utilities'"

Solution: Check your package.json exports field. The path must match exactly:

"exports": {
  "./utilities": { ... }  // Note the "./" prefix
}

Issue 2: Build Fails with "Public API exports not found"

Solution: Ensure your public-api.ts file exists and exports are correct:

// Correct
export * from './src/my-service';

// Incorrect - missing 'src' folder
export * from './my-service';

Issue 3: TypeScript Can't Find Types

Solution: Update your tsconfig.json paths:

{
  "compilerOptions": {
    "paths": {
      "@mycompany/awesome-lib": ["dist/mycompany/awesome-lib"],
      "@mycompany/awesome-lib/*": ["dist/mycompany/awesome-lib/*"]
    }
  }
}

Issue 4: Entry Point Not Tree-Shaken

Solution: Add "sideEffects": false to your package.json. This tells bundlers that your code is side-effect free and safe to tree-shake.

Best Practices and When to Use Multiple Entry Points

Not every library needs multiple entry points. Here's my decision framework:

Use Multiple Entry Points When:

Your library has distinct, independent feature sets
Users typically only need a subset of your functionality
Bundle size is a critical concern for your users
You're building a utility library with many standalone functions

Keep a Single Entry Point When:

Your library is small (< 50KB)
All features are tightly coupled
Users typically need everything you provide
The added complexity isn't worth the marginal gains

Pro Tips from the Trenches

1. Group Related Features: Don't create an entry point for every single service. Group related functionality:

@mycompany/ui-kit/buttons
@mycompany/ui-kit/forms
@mycompany/ui-kit/layout

2. Version Everything Together: All entry points share the same version. Don't try to version them independently — it's a nightmare.

3. Document Import Paths: Make it crystal clear how to import from each entry point. Good documentation beats clever code every time.

4. Test Bundle Output: Use tools like webpack-bundle-analyzer to verify that tree-shaking actually works:

npm install -D webpack-bundle-analyzer
ng build --stats-json
npx webpack-bundle-analyzer dist/stats.json

Bonus Tip: Automating Entry Point Creation

Here's a quick Node.js script to generate new entry points automatically:

// scripts/create-entry-point.js
const fs = require('fs');
const path = require('path');

function createEntryPoint(name) {
  const libPath = 'projects/mycompany/awesome-lib';
  const entryPath = path.join(libPath, name);

  // Create directory
  fs.mkdirSync(entryPath, { recursive: true });
  fs.mkdirSync(path.join(entryPath, 'src'), { recursive: true });

  // Create ng-package.json
  const ngPackageContent = {
    "$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
    "lib": {
      "entryFile": "public-api.ts"
    }
  };

  fs.writeFileSync(
    path.join(entryPath, 'ng-package.json'),
    JSON.stringify(ngPackageContent, null, 2)
  );

  // Create public-api.ts
  fs.writeFileSync(
    path.join(entryPath, 'public-api.ts'),
    `// Public API Surface of ${name}\n`
  );

  console.log(`Entry point '${name}' created successfully!`);
}

// Usage: node scripts/create-entry-point.js my-feature
createEntryPoint(process.argv[2]);

Recap: Your Entry Point Mastery Checklist

Let's recap what you've learned today:

Entry points are doors into your library — each one provides access to specific features
Secondary entry points enable surgical imports — users only bundle what they actually use
Configuration is straightforward — ng-package.json, public-api.ts, and package.json exports
Testing is non-negotiable — comprehensive tests ensure your library works reliably
Not every library needs multiple entry points — use them when they solve real problems

You now have the knowledge to create professional-grade Angular libraries that respect your users' bundle sizes while maintaining clean architecture. The next time you build a library, you'll know exactly when and how to leverage multiple entry points.

What's Your Next Move?

What did you think? Have you struggled with large library bundles before? What approach are you most excited to try? Drop a comment below — I read every single one and often write follow-up articles based on your questions!

Found this helpful? If this article saved you from bundle bloat, hit that clap button! Seriously, every clap helps other developers discover these techniques. Go ahead, you can clap up to 50 times — I dare you to see how fast you can click!

Want more Angular deep dives? I publish practical Angular insights every week. Follow me here on Medium and never miss an article. Better yet, join my newsletter where I share exclusive tips and early access to new content before it goes public.

Your action items:

Audit your existing libraries — do any need splitting into entry points?
Try the techniques in this article on a real project
Share your results in the comments
Challenge a colleague to optimize their library architecture

Remember: great developers don't just write code that works — they write code that scales, performs, and respects their users' constraints. Now go forth and build something awesome!

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

Optimize Angular Bundle Size in 4 Steps: From Bloated to Lightning-Fast

Rajat — Wed, 03 Jun 2026 13:30:00 +0000

Ship faster apps with smaller bundles — your users (and Lighthouse score) will thank you

Ever deployed an Angular app only to watch users bounce because it took forever to load? You're not alone. I've seen Angular apps balloon to 5MB+ bundles, crushing performance and killing user experience. But here's the thing — most of that weight is completely unnecessary.

What if I told you that you could slash your bundle size by 60% or more with just four strategic optimizations?

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.

By the end of this article, you'll know exactly how to analyze, optimize, and maintain lean Angular bundles that load in seconds, not minutes. We'll dive into practical techniques that you can implement today, complete with code examples that actually work in Angular 18+.

Why Bundle Size is Your Silent Performance Killer

Your Angular bundle size directly impacts:

Initial load time: Every 100KB adds roughly 1 second on 3G
SEO rankings: Google penalizes slow sites (Core Web Vitals matter!)
Conversion rates: Amazon found every 100ms delay costs 1% in sales

Angular's build system (now using ESBuild by default) does some optimization out of the box, but it's not magic. Without deliberate optimization, your bundles accumulate cruft faster than a developer's Downloads folder.

When Should You Start Optimizing?

Here's when bundle optimization becomes critical:

Your main bundle exceeds 500KB (gzipped)
Lighthouse Performance score drops below 70
Initial load takes more than 3 seconds on 4G
Users complain about sluggish performance
Your analytics show high bounce rates on first visit

Quick check: Run ng build and look at the output. See those yellow or red warnings about bundle sizes? Time to optimize.

Step 1: Analyze Your Bundle (Know Your Enemy)

You can't fix what you can't measure. Let's expose what's bloating your bundle.

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

# Build with stats output
ng build --stats-json

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

For a more integrated approach, use source-map-explorer:

// package.json scripts
{
  "scripts": {
    "analyze": "ng build --source-map && source-map-explorer dist/**/*.js",
    "analyze:prod": "ng build --configuration production --source-map && source-map-explorer dist/**/*.js"
  }
}

// Install source-map-explorer
// npm install --save-dev source-map-explorer

// Run analysis
// npm run analyze:prod

This generates an interactive treemap showing exactly what's eating your bundle space. I bet you'll find surprises — like that one library you imported for a single function.

Pro tip: Set up bundle analysis in your CI/CD pipeline. Track bundle size over time and catch bloat before it ships.

Step 2: Remove Unused Code and Dependencies

Time to go on a diet. Most Angular apps carry dead weight from unused imports and bloated libraries.

Smart Imports Save Kilobytes

// BAD: Imports entire RxJS library (200KB+)
import * as rxjs from 'rxjs';
import { Observable } from 'rxjs';

// BAD: Imports all operators
import * as operators from 'rxjs/operators';

// GOOD: Tree-shakable imports (only what you need)
import { Observable, Subject, of } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap } from 'rxjs/operators';

// BAD: Importing entire lodash (70KB+)
import _ from 'lodash';
const result = _.debounce(fn, 300);

// GOOD: Import specific functions (2KB)
import debounce from 'lodash-es/debounce';
const result = debounce(fn, 300);

// Even better: Use native alternatives when possible
// Instead of lodash's map, filter, reduce — use native Array methods

// Component example with optimized imports
import { Component, OnInit, signal, computed } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FormControl, ReactiveFormsModule } from '@angular/forms';
import { debounceTime, distinctUntilChanged } from 'rxjs/operators';

@Component({
  selector: 'app-search',
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <input [formControl]="searchControl" placeholder="Search...">
    @if (isSearching()) {
      <div>Searching...</div>
    }
  `
})
export class SearchComponent implements OnInit {
  searchControl = new FormControl('');
  isSearching = signal(false);

  ngOnInit() {
    this.searchControl.valueChanges.pipe(
      debounceTime(300),
      distinctUntilChanged()
    ).subscribe(value => {
      this.performSearch(value);
    });
  }

  private performSearch(query: string | null) {
    this.isSearching.set(true);
    // Search logic here
  }
}

Audit and Remove Unused Dependencies

# Find unused dependencies
npx depcheck

# Check bundle impact of each dependency
npx bundle-phobia-cli moment
# Shows: moment@2.29.4 is 72.8KB minified, 232KB minified+gzipped

# Alternative: use date-fns instead of moment
npm uninstall moment
npm install date-fns
# date-fns is tree-shakable, moment isn't

# Remove unused Angular packages
npm uninstall @angular/animations  # If not using animations
npm uninstall @angular/forms        # If only using reactive forms

Ever checked how much moment.js adds to your bundle? Spoiler: it's huge. Switch to date-fns and save 200KB+ instantly.

Step 3: Implement Lazy Loading and Standalone Components

This is where the magic happens. Lazy loading splits your app into chunks that load on-demand.

Modern Route-Based Lazy Loading

// app.routes.ts - Modern Angular 18+ routing
import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    loadComponent: () => import('./home/home.component').then(m => m.HomeComponent)
  },
  {
    path: 'dashboard',
    // Lazy load entire feature with child routes
    loadChildren: () => import('./dashboard/dashboard.routes').then(m => m.DASHBOARD_ROUTES)
  },
  {
    path: 'admin',
    // Lazy load with guards
    loadComponent: () => import('./admin/admin.component').then(m => m.AdminComponent),
    canActivate: [() => import('./guards/auth.guard').then(m => m.canActivate())]
  },
  {
    path: 'products',
    // Preload this route for better UX
    loadChildren: () => import('./products/products.routes').then(m => m.PRODUCTS_ROUTES),
    data: { preload: true }
  }
];

// dashboard/dashboard.routes.ts
import { Routes } from '@angular/router';

export const DASHBOARD_ROUTES: Routes = [
  {
    path: '',
    loadComponent: () => import('./dashboard-layout.component').then(m => m.DashboardLayoutComponent),
    children: [
      {
        path: 'analytics',
        loadComponent: () => import('./analytics/analytics.component').then(m => m.AnalyticsComponent)
      },
      {
        path: 'reports',
        loadComponent: () => import('./reports/reports.component').then(m => m.ReportsComponent)
      }
    ]
  }
];

// dashboard-layout.component.ts
import { Component } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-dashboard-layout',
  imports: [RouterOutlet, CommonModule],
  template: `
    <div class="dashboard-container">
      <nav class="sidebar">
        <a routerLink="analytics">Analytics</a>
        <a routerLink="reports">Reports</a>
      </nav>
      <main class="content">
        <router-outlet />
      </main>
    </div>
  `
})
export class DashboardLayoutComponent {}

Smart Component Lazy Loading

// chart-container.component.ts
import { Component, ViewContainerRef, signal } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-chart-container',
  imports: [CommonModule],
  template: `
    <button (click)="loadChart()">Show Analytics Chart</button>

    @if (chartLoaded()) {
      <div #chartContainer></div>
    } @else if (isLoading()) {
      <div class="spinner">Loading chart...</div>
    }
  `
})
export class ChartContainerComponent {
  chartLoaded = signal(false);
  isLoading = signal(false);

  constructor(private viewContainerRef: ViewContainerRef) {}

  async loadChart() {
    this.isLoading.set(true);

    // Dynamically import heavy chart component
    const { ChartComponent } = await import('./chart/chart.component');

    // Create component instance
    const componentRef = this.viewContainerRef.createComponent(ChartComponent);

    // Pass data to the component
    componentRef.instance.data = this.getChartData();

    this.chartLoaded.set(true);
    this.isLoading.set(false);
  }

  private getChartData() {
    return {
      labels: ['Jan', 'Feb', 'Mar'],
      values: [100, 200, 150]
    };
  }
}

// Lazy load heavy libraries conditionally
@Component({
  selector: 'app-editor',
  imports: [CommonModule],
  template: `
    <button (click)="initializeEditor()">Open Editor</button>
    @if (editorReady()) {
      <div #editorContainer></div>
    }
  `
})
export class EditorComponent {
  editorReady = signal(false);
  private editor: any;

  async initializeEditor() {
    // Load Monaco Editor only when needed (saves 2MB+!)
    const monaco = await import('monaco-editor');

    this.editor = monaco.editor.create(
      document.getElementById('editorContainer')!,
      {
        value: 'console.log("Hello world");',
        language: 'typescript',
        theme: 'vs-dark'
      }
    );

    this.editorReady.set(true);
  }

  ngOnDestroy() {
    this.editor?.dispose();
  }
}

Not everything needs to be route-based. Heavy components can be lazy-loaded on demand:Think about it — why load a 2MB chart library if 80% of users never click on the analytics tab?

Step 4: Enable Advanced Build Optimizations

Time to squeeze every last byte out of your build with Angular's optimization arsenal.

// angular.json - Production optimization settings
{
  "projects": {
    "your-app": {
      "architect": {
        "build": {
          "configurations": {
            "production": {
              "optimization": {
                "scripts": true,
                "styles": {
                  "minify": true,
                  "inlineCritical": true
                },
                "fonts": {
                  "inline": true
                }
              },
              "outputHashing": "all",
              "sourceMap": false,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kb",
                  "maximumError": "1mb"
                },
                {
                  "type": "anyComponentStyle",
                  "maximumWarning": "2kb",
                  "maximumError": "4kb"
                }
              ],
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            },
            "development": {
              "optimization": false,
              "sourceMap": true,
              "vendorChunk": true,
              "buildOptimizer": false
            }
          }
        },
        "serve": {
          "configurations": {
            "production": {
              "buildTarget": "your-app:build:production",
              "gzip": true,
              "brotli": true
            }
          }
        }
      }
    }
  }
}

Enable Compression and Modern Build Features

// server.ts - Express server with compression
import compression from 'compression';
import express from 'express';

const app = express();

// Enable gzip/brotli compression
app.use(compression({
  level: 9, // Maximum compression
  threshold: 0, // Compress everything
  filter: (req, res) => {
    // Don't compress responses with this request header
    if (req.headers['x-no-compression']) {
      return false;
    }
    // Fallback to standard filter
    return compression.filter(req, res);
  }
}));

// Serve static files with proper cache headers
app.use(express.static('dist', {
  maxAge: '1y',
  etag: false,
  setHeaders: (res, path) => {
    if (path.endsWith('.html')) {
      // Don't cache HTML files
      res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');
    }
  }
}));

// Build script with compression (package.json)
{
  "scripts": {
    "build:prod": "ng build --configuration production && npm run compress",
    "compress": "gzip -k -9 dist/**/*.{js,css,html} && brotli-cli compress dist/**/*.{js,css,html}",
    "analyze:size": "npm run build:prod && ls -lah dist/**/*.{js,css}"
  }
}

// Preload strategy for better performance
// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
import { routes } from './app.routes';

// Custom preload strategy
class CustomPreloadStrategy implements PreloadingStrategy {
  preload(route: Route, load: () => Observable<any>): Observable<any> {
    // Preload routes marked with data: { preload: true }
    return route.data && route.data['preload'] ? load() : of(null);
  }
}

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withPreloading(CustomPreloadStrategy)
    )
  ]
};

Testing Your Optimizations

Let's make sure our optimizations actually work:

// bundle-size.spec.ts - Unit test for bundle size
import { readFileSync, statSync } from 'fs';
import { join } from 'path';

describe('Bundle Size Tests', () => {
  const distPath = join(__dirname, '../../../dist');

  it('should keep main bundle under 500KB', () => {
    const mainBundle = join(distPath, 'main.js');
    const stats = statSync(mainBundle);
    const sizeInKB = stats.size / 1024;

    expect(sizeInKB).toBeLessThan(500);
  });

  it('should have lazy-loaded chunks', () => {
    const files = readdirSync(distPath);
    const lazyChunks = files.filter(f => f.includes('chunk'));

    expect(lazyChunks.length).toBeGreaterThan(0);
  });

  it('should not include unused libraries', () => {
    const mainContent = readFileSync(join(distPath, 'main.js'), 'utf-8');

    // Check that moment.js is not in the bundle
    expect(mainContent).not.toContain('moment');

    // Check that only used RxJS operators are included
    expect(mainContent).toContain('debounceTime');
    expect(mainContent).not.toContain('exhaustMap'); // Unused operator
  });
});

// performance.spec.ts - E2E performance tests
import { test, expect } from '@playwright/test';

test.describe('Performance Metrics', () => {
  test('should load within 3 seconds on slow 3G', async ({ page }) => {
    // Simulate slow 3G
    await page.route('**/*', route => route.continue());
    await page.context().setOffline(false);

    const client = await page.context().newCDPSession(page);
    await client.send('Network.emulateNetworkConditions', {
      offline: false,
      downloadThroughput: (1.6 * 1024 * 1024) / 8, // 1.6 Mbps
      uploadThroughput: (750 * 1024) / 8, // 750 Kbps
      latency: 150
    });

    const startTime = Date.now();
    await page.goto('http://localhost:4200');
    await page.waitForLoadState('networkidle');
    const loadTime = Date.now() - startTime;

    expect(loadTime).toBeLessThan(3000);
  });

  test('should have good Core Web Vitals', async ({ page }) => {
    await page.goto('http://localhost:4200');

    // Measure LCP (Largest Contentful Paint)
    const lcp = await page.evaluate(() => {
      return new Promise(resolve => {
        new PerformanceObserver(list => {
          const entries = list.getEntries();
          const lastEntry = entries[entries.length - 1];
          resolve(lastEntry.renderTime || lastEntry.loadTime);
        }).observe({ entryTypes: ['largest-contentful-paint'] });
      });
    });

    expect(lcp).toBeLessThan(2500); // Good LCP is under 2.5s
  });
});

Pros and Cons of Bundle Optimization

The Good Stuff:

50-70% faster initial load times — Users see content quicker
Better SEO rankings — Google loves fast sites
Lower bounce rates — Users stick around when apps load fast
Reduced hosting costs — Smaller files = less bandwidth
Improved mobile experience — Critical for users on slower connections

The Trade-offs:

More complex build configuration — Takes time to set up properly
Potential lazy-loading delays — Some features load on-demand
Debugging gets harder — Source maps disabled in production
Risk of over-optimization — Too many chunks can hurt performance
Maintenance overhead — Need to monitor bundle size regularly

How to Measure Your Success

Before celebrating, let's verify the improvements:

#!/bin/bash
# performance-check.sh

echo "Building optimized version..."
ng build --configuration production

echo "Bundle Size Analysis:"
echo "========================"

# Check main bundle size
MAIN_SIZE=$(stat -f%z dist/main.*.js 2>/dev/null || stat -c%s dist/main.*.js 2>/dev/null)
MAIN_SIZE_KB=$((MAIN_SIZE / 1024))

if [ $MAIN_SIZE_KB -lt 500 ]; then
  echo "Main bundle: ${MAIN_SIZE_KB}KB (Good!)"
else
  echo "Main bundle: ${MAIN_SIZE_KB}KB (Too large!)"
fi

# Check total size
TOTAL_SIZE=$(du -sh dist | cut -f1)
echo "Total dist size: $TOTAL_SIZE"

# Run Lighthouse
echo "Running Lighthouse..."
npx lighthouse http://localhost:4200 \
  --only-categories=performance \
  --output=json \
  --output-path=./lighthouse-report.json

# Parse and display score
PERF_SCORE=$(cat lighthouse-report.json | grep -o '"performance":{"score":[0-9.]*' | grep -o '[0-9.]*$')
SCORE_PERCENT=$(echo "$PERF_SCORE * 100" | bc)

echo "Lighthouse Performance Score: ${SCORE_PERCENT}%"

if (( $(echo "$PERF_SCORE >= 0.9" | bc -l) )); then
  echo "Excellent performance!"
elif (( $(echo "$PERF_SCORE >= 0.7" | bc -l) )); then
  echo "Good, but room for improvement"
else
  echo "Performance needs work"
fi

Real-world targets you should aim for:

Main bundle: Under 250KB (gzipped)
Lazy chunks: 50-150KB each
Total initial load: Under 500KB
Lighthouse score: 90+ for performance
First Contentful Paint: Under 1.5s
Time to Interactive: Under 3s

Common Mistakes to Avoid

Learn from my pain — here are the gotchas that waste hours:

1. Accidentally disabling tree-shaking:
Setting "sideEffects": false in the wrong package.json can break your app.

2. Forgetting to update budgets:
Your CI/CD should fail if bundles exceed limits. Don't let bloat sneak in.

3. Over-eager lazy loading:
Loading 50 tiny chunks is worse than one slightly larger bundle. Find the balance.

4. Loading unnecessary polyfills:
Angular 18 targets modern browsers by default. Don't ship IE11 polyfills in 2025!

5. Keeping source maps in production:
They're great for debugging but add 3-5x to your bundle size.

Bonus Tips from the Trenches

Here's what I wish someone told me earlier:

Use the Angular DevTools Profiler — It shows exactly which components are slowing down your app. Install the browser extension and look for components taking more than 16ms to render.

Consider Module Federation for micro-frontends — If your app is huge, split it into separate deployable units. Each team can optimize independently.

Preconnect to critical domains:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://api.yourapp.com">

Use a CDN for static assets — Your 500KB vendor bundle loads way faster from a CDN edge server than your origin.

Monitor bundle size in PR checks — Add this to your CI pipeline and reject PRs that increase bundle size without justification.

Quick Recap

You've just learned how to transform your bloated Angular app into a lean, mean, loading machine:

Analyze — Use webpack-bundle-analyzer to see what's eating space
Remove — Eliminate unused code and optimize imports
Split — Implement lazy loading for routes and heavy components
Optimize — Enable production builds with compression and budgets

The best part? These techniques compound. Combine all four and watch your bundle shrink by 60-80%.

Remember: Performance optimization isn't a one-time task. Make it part of your development workflow. Set up monitoring, enforce budgets, and regularly audit your dependencies.

Your users are waiting. Every second counts. Now go optimize that bundle!

What's Your Experience?

Have you tackled a massive Angular bundle before? What was your biggest surprise when you analyzed it? Drop a comment below — I'm curious what monsters you've found lurking in your bundles.

Found this helpful? Hit that button (you can clap up to 50 times, just saying) so other devs can discover these optimization techniques too.

Want more Angular performance tips delivered to your inbox? Follow me here on Medium or subscribe to my weekly newsletter where I share one actionable performance tip every Tuesday.

Action point: Pick ONE optimization from this article and implement it today. Then share your before/after bundle sizes in the comments. Let's see who gets the biggest reduction!

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

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

DEV Community: Rajat

The OnPush Default Has Arrived: A Practical Guide to Angular 22's Biggest Shift - Here's What Changes (Part 1)

A practical, code-first tour of Angular 22's biggest change-detection shift — what breaks, what doesn't, and how to migrate without surprises*

OnPush Becomes the Default Change Detection Strategy

ChangeDetectionStrategy.Default Is Now ChangeDetectionStrategy.Eager

Impact on Existing Apps: The Good News and the One Catch

Signals and OnPush: Why They Were Basically Built for Each Other

The Zoneless Future: Where This Fits in the Bigger Picture

Migration Considerations: The ng update Walkthrough

Unit Testing OnPush and Signal-Based Components

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Mastering Angular Library Entry Points: Build Modular, Tree-Shakeable Packages Like a Pro

How to create secondary entry points in Angular libraries for better modularity and smaller bundles

What Are Entry Points in Angular Libraries?

Why Multiple Entry Points Matter

The Good Stuff

The Trade-offs

Step-by-Step: Creating Your First Secondary Entry Point

Step 1: Generate Your Library

Step 2: Create the Secondary Entry Point Folder

Step 3: Configure the Secondary Entry Point

Step 4: Set Up the Public API

Step 5: Create Your Utility Services

Step 6: Update Package.json Exports

Step 7: Build and Verify

Implementing in an Nx Monorepo

Generate a Library with Secondary Entry Points in Nx

Consuming Your Multi-Entry Point Library

Install Your Library

Import from Different Entry Points

Writing Unit Tests for Your Library

Troubleshooting Common Issues

Issue 1: "Cannot find module '@mycompany/awesome-lib/utilities'"

Issue 2: Build Fails with "Public API exports not found"

Issue 3: TypeScript Can't Find Types

Issue 4: Entry Point Not Tree-Shaken

Best Practices and When to Use Multiple Entry Points

Use Multiple Entry Points When:

Keep a Single Entry Point When:

Pro Tips from the Trenches

Bonus Tip: Automating Entry Point Creation

Recap: Your Entry Point Mastery Checklist

What's Your Next Move?

Follow Me for More Angular & Frontend Goodness:

Optimize Angular Bundle Size in 4 Steps: From Bloated to Lightning-Fast

Ship faster apps with smaller bundles — your users (and Lighthouse score) will thank you

Why Bundle Size is Your Silent Performance Killer

When Should You Start Optimizing?

Step 1: Analyze Your Bundle (Know Your Enemy)

Step 2: Remove Unused Code and Dependencies

Smart Imports Save Kilobytes

Audit and Remove Unused Dependencies

Step 3: Implement Lazy Loading and Standalone Components

Modern Route-Based Lazy Loading

Smart Component Lazy Loading

Step 4: Enable Advanced Build Optimizations

Enable Compression and Modern Build Features

Testing Your Optimizations

Pros and Cons of Bundle Optimization

The Good Stuff:

The Trade-offs:

How to Measure Your Success

Common Mistakes to Avoid

Bonus Tips from the Trenches

Quick Recap

What's Your Experience?

Follow Me for More Angular & Frontend Goodness:

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

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`