DEV Community: Anastasios Theodosiou

The Missing Piece in Angular i18n

Anastasios Theodosiou — Sun, 01 Feb 2026 00:42:04 +0000

How to stop breaking translations every time your app changes

Angular’s i18n story looks complete at first glance.
You mark strings, run ng extract-i18n, and you get a messages.xlf file that accurately represents your templates.

That part works.

What Angular never really addresses is what happens after that first extraction — when the application keeps evolving and translations need to keep up without losing work.

This is the gap that causes most Angular i18n pain in real projects.

Where things actually go wrong

In production apps, translation files are not disposable build artifacts.
They are long-lived documents edited by humans and external tools.

A typical locale file contains far more than translated text:
translator notes, context groups, approval flags, vendor-specific metadata — information that gives meaning and history to each string.

Yet every time messages.xlf changes, teams are forced into risky workflows:
manual XML edits, copy–paste merges, regeneration of locale files, or fragile scripts that assume XLIFF is just key-value data.

The result is almost always the same: silent data loss.

Notes disappear.
Approved translations reset.
Context is lost.
And nobody notices until translators complain or builds fail.

Angular does not solve this problem.
Most third-party tools don’t either.

What xlf-sync is designed to do

xlf-sync exists for a very specific purpose:

Keep messages.<locale>.xlf files structurally in sync with messages.xlf without destroying anything that already exists.

It does not generate translations.
It does not “clean up” XML.
It does not assume locale files can be recreated safely.

Instead, it treats them as valuable state that must be preserved.

The source file remains the authority for what keys exist.
Locale files remain the authority for everything else.

Metadata is the real differentiator

Most sync tools rebuild translation units from scratch.
That inevitably strips information the tool doesn’t understand.

xlf-sync takes the opposite approach.

Existing translation units are never reconstructed.
They are read, preserved byte-for-byte, and only extended when the source introduces something new.

If a translator added a note two years ago, it stays.
If a CAT tool added metadata, it survives.
If an entry was marked as approved, it remains approved.

This is not a convenience feature.
It is the core guarantee of the tool.

Handling change without deleting history

Applications change constantly.
Strings are added, removed, and reorganized.

xlf-sync makes one important assumption: removal does not imply deletion.

When a key disappears from the source file, you decide how to handle it.
You can mark it obsolete, move it to a dedicated graveyard file, or delete it explicitly if that’s truly what you want.

Nothing happens implicitly.
Nothing disappears accidentally.

This makes refactoring safer and preserves translation work even when features are temporarily removed.

Designed for real Angular codebases

Many Angular repositories are not clean, greenfield projects.
They contain legacy modules, migrations, and mixed formats.

xlf-sync supports both XLIFF 1.2 and 2.0 and detects the version per file.
It works even when both formats exist in the same project.

That makes it usable not just for new apps, but for mature systems with history.

Visibility and automation matter

Angular’s CLI gives you no clear picture of translation health.

xlf-sync fills that gap by providing both quick console reports and a standalone HTML dashboard that visualizes translation coverage across locales. The dashboard is especially useful outside the engineering team — it makes translation progress visible without opening XML files.

For automation, the check command turns i18n into a real CI concern.
You can fail builds when translations are missing, out of sync, or drifting from the source.

This shifts i18n from an afterthought to a quality gate.

A missing piece Angular never shipped: a translation dashboard

Angular’s i18n tooling gives you files, but it gives you zero visibility.

You don’t know:

which locales are behind
how much is translated
where the gaps actually are

xlf-sync addresses this with a standalone HTML dashboard.

With a single command:

npx xlf-sync dashboard

you get a self-contained report that visualizes translation coverage across all locales. It shows how many keys exist, how many are translated, and which ones are missing — without requiring anyone to open an XLIFF file.

This turns translation status from something hidden in XML into something observable and shareable. Product managers, translators, and developers can all look at the same artifact and understand the state of i18n instantly.

Because the dashboard is static HTML, it also fits naturally into CI pipelines. Teams often attach it as a build artifact, making translation progress visible alongside test reports and coverage metrics.

This is not about eye candy.
It’s about making i18n measurable.

How this differs from other tools

Most tools treat locale files as derived output.
xlf-sync treats them as assets.

That single distinction explains its behavior:
no destructive syncs, no metadata loss, no silent rewrites.

It prioritizes safety over cleverness — which is exactly what long-lived multilingual projects need.

Learn more

GitHub repository: https://github.com/atheodosiou/xlf-sync
Official documentation & landing page: https://atheodosiou.github.io/xlf-sync/
npm package: https://www.npmjs.com/package/xlf-sync

Closing thought

Angular i18n handles extraction well.
Everything after that is left to the developer.

xlf-sync doesn’t replace Angular’s tooling — it completes it.

If your application has real translations, real translators, and real change,
this problem will surface sooner or later.

xlf-sync simply removes the risk from that moment onward.

How I Built a Plugin-Based Architecture in Angular 19+ 💉

Anastasios Theodosiou — Wed, 05 Nov 2025 12:40:09 +0000

A simple pattern that keeps your Angular app modular, scalable, and sane.

Why I Needed It

A few months ago, I was working on a large Angular 20 project.
It had everything: analytics, error monitoring, A/B testing, feature flags, and more integrations than I could count.

Every new service wanted to “initialize” itself at startup.
Soon, my main.ts looked like a spaghetti monster of async calls and environment checks.
I knew there had to be a cleaner way.

That’s when I revisited something most Angular devs overlook: multi-providers.

⚙️ The Hidden Power of Multi-Providers

Angular’s DI system can do more than inject single services.
With a multi provider, you can register multiple implementations under one InjectionToken.
When you inject that token, you get an array of all registered items, perfect for a plugin system.

This pattern lets you add or remove features without touching the core codebase.
Each plugin is just a class with an init() method and a unique ID.

Step 1 – Define the Plugin Contract

Minimum Angular version: 19+ (uses provideAppInitializer)

// core/plugins/plugin.token.ts
import { InjectionToken } from '@angular/core';

export interface AppPlugin {
  readonly id: string;
  readonly order?: number;
  isEnabled?(): boolean;
  init(): void | Promise<void>;
}

export const APP_PLUGINS = new InjectionToken<AppPlugin[]>('app.plugins');

That’s it. A minimal interface.
Each plugin knows how to initialize itself, and Angular will collect them all through this token.

Step 2 – A Registry to Run Them All

We need one lightweight service to coordinate everything at startup.

// core/plugins/plugin-registry.service.ts
import { Injectable, inject, PLATFORM_ID } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import { APP_PLUGINS, AppPlugin } from './plugin.token';

@Injectable({ providedIn: 'root' })
export class PluginRegistry {
  private readonly plugins = inject(APP_PLUGINS, { optional: true }) ?? [];
  private readonly platformId = inject(PLATFORM_ID);

  async initAll(): Promise<void> {
    if (!isPlatformBrowser(this.platformId)) return; // skip SSR

    const eligible = this.plugins
      .filter(p => p.isEnabled?.() ?? true)
      .sort((a, b) => (a.order ?? 0) - (b.order ?? 0));

    for (const p of eligible) {
      try {
        await Promise.resolve(p.init());
        console.info(`[Plugin] ${p.id} initialized`);
      } catch (err) {
        console.error(`[Plugin] ${p.id} failed`, err);
      }
    }
  }
}

In one of my apps, this registry replaced nearly 200 lines of manual startup logic.
Now, every integration just registers itself and runs automatically.

Step 3 – Bootstrap Cleanly with `provideAppInitializer`

Angular 19 introduced provideAppInitializer(), a small but powerful helper that replaces boilerplate APP_INITIALIZER factories.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideAppInitializer, inject } from '@angular/core';
import { AppComponent } from './app/app.component';
import { PluginRegistry } from './core/plugins/plugin-registry.service';
import { APP_PLUGINS } from './core/plugins/plugin.token';
import { SentryPlugin } from './core/plugins/sentry.plugin';
import { GoogleAnalyticsPlugin } from './core/plugins/ga.plugin';

bootstrapApplication(AppComponent, {
  providers: [
    { provide: APP_PLUGINS, useClass: SentryPlugin, multi: true },
    { provide: APP_PLUGINS, useClass: GoogleAnalyticsPlugin, multi: true },
    provideAppInitializer(() => inject(PluginRegistry).initAll()),
  ]
});

Compatibility (Angular 15–18):

These versions don’t have provideAppInitializer(). Use the deprecated APP_INITIALIZER token instead; everything else stays the same.

// Angular 15–18
import { APP_INITIALIZER, inject } from '@angular/core';
import { PluginRegistry } from './core/plugins/plugin-registry.service';

providers: [
  {
    provide: APP_INITIALIZER,
    multi: true,
    useFactory: () => {
      const registry = inject(PluginRegistry);
      return () => registry.initAll();
    }
  }
];

One line replaces all the “init this, then that” chaos, and it runs safely before your root component renders.

Step 4 – Real Plugins in Action

Here’s how the plugins look in practice.
Each one is self-contained and only loads if it’s actually enabled.

// core/plugins/ga.plugin.ts
import { Injectable } from '@angular/core';
import { AppPlugin } from './plugin.token';

@Injectable({ providedIn: 'root' })
export class GoogleAnalyticsPlugin implements AppPlugin {
  readonly id = 'ga4';
  readonly order = 10;

  isEnabled() {
    return !!(window as any).ENV?.GA_MEASUREMENT_ID;
  }

  async init() {
    const id = (window as any).ENV.GA_MEASUREMENT_ID;
    if (!id) return;

    await this.loadScript(`https://www.googletagmanager.com/gtag/js?id=${id}`);
    (window as any).dataLayer = (window as any).dataLayer || [];
    function gtag(...args: any[]) { (window as any).dataLayer.push(args); }
    (window as any).gtag = gtag;

    gtag('js', new Date());
    gtag('config', id, { anonymize_ip: true });
  }

  private loadScript(src: string) {
    return new Promise<void>((resolve, reject) => {
      const s = document.createElement('script');
      s.async = true;
      s.src = src;
      s.onload = () => resolve();
      s.onerror = reject;
      document.head.appendChild(s);
    });
  }
}

// core/plugins/sentry.plugin.ts
import { Injectable } from '@angular/core';
import { AppPlugin } from './plugin.token';

@Injectable({ providedIn: 'root' })
export class SentryPlugin implements AppPlugin {
  readonly id = 'sentry';
  readonly order = 5;

  isEnabled() {
    return !!(window as any).ENV?.SENTRY_DSN;
  }

  async init() {
    const dsn = (window as any).ENV.SENTRY_DSN;
    if (!dsn) return;
    const Sentry = await import('@sentry/browser');
    Sentry.init({ dsn, tracesSampleRate: 0.1 });
  }
}

In production, both run automatically, no imports, no conditionals, no spaghetti.

Step 5 – Feature-Scoped Plugins

This pattern scales nicely across domains.
A payments library, for example, can register its own plugin without touching the core app:

// libs/payments/payment.plugin.ts
import { APP_PLUGINS, AppPlugin } from '@app/core/plugins/plugin.token';
import { Provider } from '@angular/core';

class PaymentsAuditPlugin implements AppPlugin {
  readonly id = 'payments-audit';
  init() { /* custom logic */ }
}

export const providePaymentsPlugins: Provider[] = [
  { provide: APP_PLUGINS, useClass: PaymentsAuditPlugin, multi: true }
];

Attach it right in the route config:

{
  path: 'payments',
  providers: [providePaymentsPlugins],
  loadComponent: () => import('./payments.component').then(m => m.PaymentsComponent)
}

Now every feature can extend global behavior independently. No central bottlenecks.

⚡ What This Gives You

From experience, this small pattern delivers huge wins:

Extensibility: add or remove integrations safely
Stability: a broken plugin can’t crash the app
SSR friendly: browser-only code stays browser-side
Testable: mock any plugin easily in unit tests
Maintainable: cross-cutting logic lives in one place

Why It Matters

In one of our enterprise apps, we had six different analytics SDKs, all fighting for control of window.dataLayer.
After moving to this plugin registry, we bootstrapped them cleanly, logged failures, and never touched them again.

Multi-providers are the unsung hero of Angular’s DI system.
They turn a monolith into a composable frontend, with zero external libraries and full type safety.

Looking Ahead

Angular’s DI has been rock-solid for years, and it keeps improving around developer experience and performance.
The good news is: the multi-provider pattern isn’t going anywhere.
It’s stable, fast, and perfectly aligned with Angular’s standalone architecture.

💬 Final Thoughts

If you’ve ever scaled an Angular app across multiple teams, you know how startup logic can spiral out of control.
This pattern won’t just clean it up, it’ll future-proof it.

Give it a try in your next project.
You’ll never go back to manual “init” scripts again.

Looking back, this pattern didn’t just clean up our code, it changed how we think about scalability in Angular.

Sometimes, true architecture isn’t about adding more frameworks, but about using what Angular already gives us, properly.

Author: Anastasios Theodosiou
Senior Software Engineer | Angular Certified Developer | Building Scalable Frontend Systems

If you found this useful, follow for more deep dives into real-world Angular architecture.

Async in JavaScript, Served Hot: The Chef’s guide to the Event Loop

Anastasios Theodosiou — Thu, 24 Jul 2025 23:08:20 +0000

What is the JavaScript Event Loop?
The event loop is a mechanism provided by the JavaScript environment (like your browser or Node.js) that enables asynchronous programming. It manages how and when different tasks—such as timers, promises, and event callbacks—get executed, making sure that everything happens in the right order, even though JavaScript itself can only do one thing at a time.

Imagine you walk into a kitchen. There’s a chef, focused and busy. He’s great at his job, but here’s his one weird rule: he can only do one thing at a time. If he’s stirring a pot, he can’t chop onions. If he’s answering the phone, he can’t check the oven. This chef is JavaScript (single-threaded), running step by step.

But, of course, a kitchen isn’t just a chef. There are timers on the oven, deliveries to track, and maybe a robot that watches for when the fridge is left open. All these “background jobs” are the Web APIs, not part of the chef’s mind, but part of the kitchen he works in.

Now, here’s the crucial part:

The event loop, the trays where jobs wait, and the Web APIs are all provided by the kitchen itself—the environment.
They’re not part of the chef’s brain (the JavaScript engine, like V8 or SpiderMonkey). This means that when you write JavaScript, the chef can only follow instructions; he needs the kitchen (the browser, Node.js, etc.) to do all the real-world, slow, or event-based jobs.

How do the Chef and Kitchen communicate? (The Real Story)

Let’s make this concrete. When the chef encounters a task he can’t do himself—like setting a timer or making an HTTP request—he turns to his helpers. Here’s how the whole process actually unfolds:

Chef hits an async task:
Suppose your code says setTimeout. The chef (JS engine) can’t actually wait or time things. So, he asks the kitchen’s timer (Web API): “Please handle this, and let me know when time’s up.”
The helper (Web API) takes over:
The kitchen’s timer starts counting, completely independently from the chef, who just moves on. The chef doesn’t care about the timer anymore—he has other work to do.
When the timer is done:
The kitchen’s timer writes a note: “This task is ready!” But the kitchen can’t just barge in and interrupt the chef; that would mess up the recipe! So the kitchen puts the note on the callback queue (the tray).
The event loop keeps watch:
There’s an invisible manager (the event loop) who keeps checking:

“Is the chef busy with the main recipe (call stack)?”
“If not, is there a note on any tray (macrotask or microtask queue)?” If yes, the manager gives the next task from the tray to the chef.

The chef never talks directly to the helpers again: The communication always goes through the trays and the event loop. The chef (JavaScript engine) and the kitchen (environment) are separate; they only “talk” via these shared trays.

The same thing happens for things like HTTP requests, file reading, DOM events, or geolocation—the chef delegates to the kitchen’s specialized helper (Web API), and when they’re done, the callback goes on the tray, waiting its turn.

Code Analogy: The communication in action

Let’s see it step by step:

console.log('Step 1: Start Cooking');

// Chef asks the kitchen to start a timer
setTimeout(() => {
  console.log('Step 5: Cake is ready!');
}, 1000);

// Chef asks the kitchen to fetch groceries
fetch('https://some.api/ingredients')
  .then(() => console.log('Step 6: Groceries arrived!'));

console.log('Step 2: Chopping veggies');

// Chef queues a promise microtask
Promise.resolve().then(() => {
  console.log('Step 4: Finished a quick microtask!');
});

console.log('Step 3: Making sauce');

What really happens?

The chef prints Step 1.
He asks the kitchen to start a timer (setTimeout). The timer runs in the kitchen (Web API land).
He asks the kitchen to fetch groceries. The fetch starts in the kitchen, out of sight for the chef.
He sees a Promise. That goes on a special “microtask” tray.
He prints Step 2 and Step 3, continuing his work.
Now, he’s done with the immediate recipe. The event loop checks the microtask tray first. The Promise callback is there, so he handles it: prints Step 4.
Then, the chef looks to the regular tray. Maybe the timer is done (after 1s), so Step 5 gets printed.
When the groceries arrive, their callback (from fetch) is also placed on the regular tray (macrotask queue), so Step 6 prints after everything else that’s already waiting.

Order of output:

Step 1: Start Cooking
Step 2: Chopping veggies
Step 3: Making sauce
Step 4: Finished a quick microtask!
Step 5: Cake is ready!         // after 1 second
Step 6: Groceries arrived!     // when the fetch completes

Notice how the chef (JS engine) and the kitchen helpers (Web APIs) coordinate everything without ever stepping on each other’s toes, thanks to the trays and the event loop.

A Peek behind the kitchen door: Microtasks vs Macrotasks

You might wonder: Why are there two trays?
Well, in JavaScript, microtasks (promises, mutation observers, queueMicrotask) have higher priority. After every batch of main recipe steps, the chef always clears the microtask tray before he looks at the macrotask tray (timers, fetch, events). This guarantees that microtasks like resolved promises happen as soon as possible, before any new timers or events.

Common Gotchas: Where most developers get surprised

setTimeout(..., 0) doesn’t run immediately!
Even with a zero delay, setTimeout callbacks are always placed in the macrotask queue, so all microtasks (like Promise callbacks) will run first.
Promise callbacks (“microtasks”) always run before timers (“macrotasks”).
If you have both in your code, the promise’s .then() will execute before setTimeout, every time.
Long chains of microtasks can block everything else.
If you keep queuing microtasks inside other microtasks, the event loop can get “stuck” processing them, delaying other tasks like timers or UI updates.
Async code doesn’t mean “in parallel.”
JavaScript is single-threaded. “Async” just means “wait your turn”—not “run at the same time.”
Event callbacks (like click or keydown) also wait their turn!
UI events are queued just like any other macrotask—they don’t interrupt code that’s already running.

What about events like clicks or keyboard input?

That’s the kitchen’s job too!
When you click a button, the kitchen sees it and, when the chef is free, puts a note on the macrotask tray. The event loop delivers it to the chef, who then runs your click handler code.

And If Things Get Crazy? (Infinite Microtasks, Starvation, etc)

Here’s a secret:
If you keep adding microtasks inside other microtasks, the chef could get stuck on the VIP tray forever, and never move on to macrotasks!
That’s called starvation. JavaScript tries to avoid it, but it’s up to you as a developer to be careful—don’t flood the microtask queue with endless callbacks.

Advanced Extras: Animation Frames, Node.js, and more complex examples

What about requestAnimationFrame?

Besides microtasks and macrotasks, browsers have a special queue for animation callbacks: the animation frame queue.

When you call requestAnimationFrame(callback), the callback runs before the next browser repaint—after all microtasks and regular tasks for the frame are finished.

This is perfect for smooth animations, because the browser chooses the best moment for your code to update the UI.

Analogy:
The chef (JS engine) has finished his trays, but before starting new work, the kitchen manager (event loop) checks, "Anything for the animation?" If so, it gets handled right before serving the next meal.

console.log('A');
requestAnimationFrame(() => console.log('B'));
Promise.resolve().then(() => console.log('C'));
console.log('D');

Output order:
A
D
C
B

What about Node.js? (Event Loop Phases)

Node.js runs JavaScript outside the browser, and its event loop is split into phases:

Timers: Executes setTimeout and setInterval callbacks.
Pending Callbacks: I/O callbacks deferred to the next loop.
Poll: Retrieves new I/O events and executes their callbacks.
Check: Executes setImmediate callbacks.
Close Callbacks: For closed connections or resources.

Promise microtasks always run between these phases, just like in the browser.

If you’re digging into Node, check the official Node.js guide.

Complex Code Execution: Step-by-step Examples

Example 1: Chained Promises vs setTimeout

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => {
  console.log('3');
  Promise.resolve().then(() => console.log('4'));
});
console.log('5');

Order:
1
5
3
4
2

Example 2: setTimeout inside a Promise

console.log('a');
Promise.resolve().then(() => {
  console.log('b');
  setTimeout(() => console.log('c'), 0);
});
setTimeout(() => console.log('d'), 0);
console.log('e');

Order:
a
e
b
d
c

Example 3: Starvation with Endless Microtasks

let count = 0;
function recur() {
  if (count < 5) { // Try count < 1_000_000 for real starvation!
    count++;
    Promise.resolve().then(recur);
  }
}
recur();
setTimeout(() => console.log('Timer fired!'), 0);

If you remove the limit, the timer may never fire—the microtask queue "starves" the timer!

Example 4: Animation, Microtasks, and Timers Together

console.log('start');
requestAnimationFrame(() => console.log('anim'));
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');

Order:
start
end
promise
timeout
anim

Tip:

When in doubt, remember the order:

Synchronous code (call stack)
Microtasks (promises)
Animation frame queue (in browser)
Macrotasks (timers, events)
Repeat!

Conclusion: What should you take away?

The JavaScript event loop is what makes single-threaded JavaScript feel so much more powerful—like a chef that always keeps the kitchen running smoothly, no matter how many jobs are waiting.

So next time you see async code, timers, or promises, remember:

The chef (JavaScript) never gets overwhelmed, because the kitchen (the environment) and the event loop keep things organized.
If something doesn’t run when you expect, check which tray it’s waiting on!

Want to see this in action? Try out your own code examples in the browser console, or grab one of the above and play with the order. The best way to master the event loop is to experiment.

If you have questions, favorite “gotchas,” or other analogies that helped you, share them in the comments below!
Let’s help more developers see that behind every callback and promise, there’s just a chef and a kitchen doing their best work—one task at a time.

Optimizing Angular Change Detection with OnPush: Skipping Subtrees for Performance

Anastasios Theodosiou — Tue, 01 Apr 2025 21:40:21 +0000

Master Angular’s OnPush strategy to build faster, more efficient apps. Learn how to skip unnecessary checks, use Signals for reactivity, and apply real-world best practices with minimal boilerplate.

Originally published on: anastasios.theodosiou.me

TL;DR

Angular's default change detection checks every component on each cycle, which can be inefficient in large apps.
The OnPush strategy improves performance by skipping subtrees unless certain triggers (like new inputs or events) occur.
Signals (introduced in Angular 16 and improved in Angular 17+) are reactive primitives that work seamlessly with OnPush.
Using signal(), input(), and the async pipe enables highly performant and reactive components with minimal boilerplate.
This article explores practical code examples, common pitfalls, and best practices for combining OnPush and Signals effectively.

Introduction

For Angular developers aiming to boost performance and reduce unnecessary UI checks, mastering the OnPush change detection strategy is essential. This article guides you through how it works, why it matters, and how to leverage it effectively.

Angular’s change detection is the mechanism that keeps the UI in sync with data. By default, Angular uses the Default (or “CheckAlways”) change detection strategy, which means every time a change detection cycle runs (e.g. after a user event, timer, HTTP response, etc.), Angular will traverse the entire component tree from the root, checking each component’s template bindings for changes. This default strategy is simple and ensures all changes are caught, but it can become inefficient in large applications because every component is checked on every cycle, even if most of them haven’t changed (The Last Guide For Angular Change Detection You'll Ever Need - Michael Hoffmann | Michael Hoffmann).

To improve performance, Angular provides the OnPush change detection strategy. The OnPush strategy allows Angular to skip entire subtrees of the component tree during change detection if it knows those components didn’t change. In other words, with OnPush, Angular will not always check a component and its children – it will “opt-out” of checking that subtree unless certain conditions are met. This can greatly reduce the work done in each change detection cycle, making your application more efficient.

How does OnPush work? A component set to ChangeDetectionStrategy.OnPush tells Angular: “Only check me for changes if you have a specific reason.” Those reasons include:

New Input Reference: The component receives new @Input() values (Angular compares the new value with the old value using === equality) (Skipping component subtrees • Angular). If an input’s reference has changed (or primitive value changed), Angular will mark that OnPush component as needing check.
An Event in the Component or Its Children: Any user event or output emitted within that component (or any of its child components) will mark the component for check (Skipping component subtrees • Angular). For example, a click event on one of its buttons will cause that OnPush component to run change detection for itself and its subtree.
Manual Trigger: A call to the component’s ChangeDetectorRef methods, such as markForCheck() or detectChanges(), can explicitly mark the component for checking or trigger a check.
Async Pipe Emissions: If the template uses the async pipe to subscribe to an Observable/Promise, a new value emission will mark the component for check automatically (the async pipe internally calls markForCheck when a new value arrives (Angular: Test Reactiveness with OnPush strategy | lacolaco's marginalia)).

If none of these conditions occur, an OnPush component (and its children) will simply be skipped during change detection. In contrast, the Default strategy (used unless specified otherwise) will check the component every time regardless. This makes OnPush a powerful tool to optimize performance by skipping unnecessary checks when you know a component’s data updates are limited to specific triggers.

In the following sections, we’ll dive deeper into how change detection works under Default vs OnPush, examine common scenarios with OnPush, and look at code examples, best practices, and pitfalls when using OnPush to skip component subtrees.

Understanding Change Detection Scenarios

To effectively use OnPush, it’s important to understand how Angular’s change detection behaves in different scenarios. Below we detail key scenarios and how the OnPush strategy affects what gets checked or skipped in each case.

1. Events in a Component with Default Change Detection

When an event is handled in a component that uses the Default change detection (the usual behavior), Angular will run change detection for the entire component tree from the root down (Skipping component subtrees • Angular). It doesn’t assume anything about what might have changed, so it checks everything. However, even in this case, Angular is smart about OnPush descendants: any child subtree rooted at an OnPush component will be skipped if that OnPush component has not received new inputs during this cycle (Skipping component subtrees • Angular).

What does this mean? Suppose you have a Default parent component that contains some OnPush child components. If a user clicks a button in the parent (triggering an event in the Default component), Angular will run through all components. The parent and other Default components will update as usual. For each OnPush child, Angular will check whether its inputs changed:

If no new inputs were passed to that OnPush child, Angular will skip checking that child and its subtree to save time (Skipping component subtrees • Angular).
If the parent’s event caused a new input value to flow into the OnPush child, then that child will be checked (since it meets the “new input” condition).

In summary, an event in a Default component triggers a full change detection pass, but OnPush components down the line only update if they got new input. Otherwise, those subtrees remain unchanged (they are essentially “frozen” for that cycle, which is good for performance).

Code Example: Default parent with an OnPush child. In the example below, the parent component uses default change detection and has an OnPush child. The parent’s button click triggers change detection across the app. The OnPush child’s ngDoCheck will not run on click because its input (data) isn’t changing.

// OnPush child component
@Component({
  selector: "child-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>Child Value: {{ data.value }}</p>`,
})
export class ChildComponent {
  @Input() data: { value: number };
  ngDoCheck() {
    console.log("ChildComponent checked");
  }
}

// Default change detection parent
@Component({
  selector: "parent-comp",
  template: `
    <child-comp [data]="staticData"></child-comp>
    <button (click)="onClick()">Parent Click</button>
  `,
})
export class ParentComponent {
  staticData = { value: 42 };
  onClick() {
    console.log("ParentComponent clicked");
    // No change to staticData input; just an event trigger
  }
}

Here, clicking the button logs “ParentComponent clicked”. Angular runs change detection. ParentComponent is checked (because it’s default), but ChildComponent is OnPush and its @Input staticData still references the same object. Angular skips checking ChildComponent’s view since no new input reference was passed (Skipping component subtrees • Angular). The console will not show “ChildComponent checked” on these clicks, indicating the OnPush child was skipped. (If ParentComponent had changed the staticData reference, then ChildComponent would be checked and updated.)

2. Events in a Component with OnPush

Now consider an event (like a click) happening inside a component that itself uses OnPush. In this scenario, Angular will still trigger a change detection cycle for the whole application (Zone.js always initiates change detection for the entire tree on any event). The difference is in which components actually get updated:

The OnPush component that had the event (and its children) will always be checked because the event marks it as “dirty” (an event counts as a change trigger within that component’s subtree) (Skipping component subtrees • Angular).
Other parts of the tree not in that component’s subtree will be skipped if they are OnPush and have no new inputs (Skipping component subtrees • Angular).

In other words, Angular runs through the component tree, but ignores other OnPush subtrees that aren’t affected by this event. Any Default components anywhere will still run (since default always runs), but OnPush components unrelated to the event remain unchanged.

A common example: Suppose your root component contains two separate OnPush components (siblings). If an event happens in one of them, the other OnPush component (which didn’t receive any input and wasn’t part of the event) will be skipped during change detection (Skipping component subtrees • Angular). This way, Angular limits the work to the branch of the tree where the event occurred.

Code Example: Two OnPush siblings, event in one. In the example below, MainComponent and SideComponent are both OnPush and rendered by a parent. A button click inside MainComponent triggers an event.

@Component({
  selector: "main-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<button (click)="onClick()">Do Action</button>`,
})
export class MainComponent {
  onClick() {
    console.log("MainComponent button clicked");
  }
  ngDoCheck() {
    console.log("MainComponent checked");
  }
}

@Component({
  selector: "side-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>Side static content</p>`,
})
export class SideComponent {
  ngDoCheck() {
    console.log("SideComponent checked");
  }
}

// Parent template using both
@Component({
  template: `<main-comp></main-comp> <side-comp></side-comp>`,
})
export class AppComponent {}

If the user clicks the button in MainComponent, we’ll see “MainComponent button clicked” and then “MainComponent checked” in the console. We will not see “SideComponent checked” because SideComponent (OnPush) had no reason to run. Angular runs change detection for the whole tree, but it ignores the SideComponent subtree since it’s OnPush with no new input and the event occurred outside of it (Skipping component subtrees • Angular). Thus, SideComponent is skipped entirely in that cycle. (If SideComponent were Default, it would run on every cycle regardless.)

3. Events in a Descendant of an OnPush Component

This scenario involves nested OnPush components: an OnPush parent with an OnPush (or Default) child, where an event originates in the child. For example, imagine ParentComponent is OnPush and inside it is a ChildComponent (which could also be OnPush). If an event (like a click) happens in the child, how does it affect the parent?

In Angular, events bubble up through the component tree, and Angular will mark the entire chain up to the root as needing change detection. So, if an event is handled in a descendant of an OnPush component, that ancestor OnPush component will be checked as well, even if its inputs didn’t change (Skipping component subtrees • Angular). In our example, the event in the child causes Angular to check the child (obviously) and the OnPush parent, because the child is part of the parent’s view.

Thus, an event in an OnPush subtree ensures that subtree is not skipped – the OnPush boundary is effectively breached by the event. Angular will run change detection for the child, the OnPush parent, and upwards through any other ancestors (default or OnPush). This makes sense: if something happened in the child, the parent might also need to update (for instance, maybe the parent template also binds to some property that could change as a result of the child event).

Code Example: OnPush parent and child, event in child. Below, both parent and child use OnPush:

@Component({
  selector: "child-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<button (click)="onChildClick()">Child Click</button>`,
})
export class ChildComponent {
  onChildClick() {
    console.log("ChildComponent button clicked");
  }
  ngDoCheck() {
    console.log("ChildComponent checked");
  }
}

@Component({
  selector: "parent-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<child-comp></child-comp>`,
})
export class ParentComponent {
  ngDoCheck() {
    console.log("ParentComponent checked");
  }
}

If the user clicks the button in ChildComponent, Angular will process that event. Even though ParentComponent is OnPush with no direct input change, the act of handling an event in its descendant marks it for checking. In the console, you’ll see both “ChildComponent checked” and “ParentComponent checked”. The parent was not skipped – Angular checked it because the event happened in its view hierarchy (Skipping component subtrees • Angular). This confirms that an OnPush component is always checked when an event occurs anywhere in its subtree.

4. Receiving New Inputs in an OnPush Component

The final common scenario is when an OnPush component receives a new value for one of its @Input properties from its parent. This is one of the primary triggers for OnPush change detection. Angular will compare the new input value with the previous value; if it’s different (by reference or value for primitives), Angular will mark that OnPush component as needing to be checked (Skipping component subtrees • Angular).

What happens then is that during the next change detection cycle, Angular will run change detection for that component (and its children). Importantly, this does not force checks of other sibling OnPush components. It only affects the subtree rooted at the component that got the new input.

For example, if ParentComponent (could be Default or OnPush) passes a new object or new primitive value to ChildComponent which is OnPush, Angular will check ChildComponent (update its bindings in the view) on the next cycle. Other OnPush components that didn’t get new inputs remain untouched (Skipping component subtrees • Angular).

Code Example: Parent provides new input to OnPush child. In this example, the child is OnPush and simply displays an input value. The parent (could be default here) updates the input periodically:

@Component({
  selector: "child-comp",
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>Counter: {{ counter }}</p>`,
})
export class ChildComponent {
  @Input() counter!: number;
  ngOnChanges() {
    console.log("ChildComponent input changed to", this.counter);
  }
}

@Component({
  selector: "parent-comp",
  template: `
    <child-comp [counter]="count"></child-comp>
    <button (click)="increment()">Increment</button>
  `,
})
export class ParentComponent {
  count = 0;
  increment() {
    this.count++;
  }
}

Each time the parent’s button is clicked, ParentComponent.increment() runs and changes the value of count. This new value flows into the ChildComponent via the binding [counter]="count". Since ChildComponent is OnPush and it received a new input value, Angular will run change detection for ChildComponent on that cycle (Skipping component subtrees • Angular). You’ll see ngOnChanges log the new counter value each time. Only the ChildComponent subtree is checked in response to this input change; if there were other OnPush components elsewhere that didn’t get new inputs or events, they would not run. If ChildComponent had its own OnPush children, they would likewise update only if their inputs changed or they had their own events.

One thing to note: the check is triggered by changing the reference or primitive value. If count were an object and we mutated one of its properties without assigning a new object, Angular’s input comparison might not catch it. We’ll cover this pitfall later.

With these scenarios in mind, you can see that using OnPush strategically “cuts off” parts of the component tree from needless checks. Next, we’ll look at how to leverage this for performance and what practices to follow when using OnPush in your Angular apps.

Performance Optimizations and Best Practices

Using ChangeDetectionStrategy.OnPush can significantly improve performance by reducing the amount of work Angular does in each change detection cycle. Here are some best practices and tips to use OnPush effectively:

Adopt Immutability for Inputs: When using OnPush, it’s highly recommended to treat input data as immutable. That means instead of mutating objects/arrays, create new instances when data changes. This way, when you pass new data to an OnPush component, the input’s reference changes and Angular knows to update the component. For example, if you have an @Input() items: Item[] and you want to update it, prefer this.items = [...this.items, newItem] over this.items.push(newItem). The former changes the reference, triggering OnPush detection, whereas the latter mutates in place (same reference) and would not trigger an update.
Use OnPush for Pure/Presentational Components: Components that act as presentational (dumb) components or primarily display data based on @Inputs are great candidates for OnPush. They don’t manage their own internal state much; they just render inputs and maybe emit outputs. Marking them OnPush ensures they only re-render when input data actually changes or in response to user interaction within them. This can greatly cut down unnecessary checks for large lists of components (like a list of item rows, etc.).
Leverage the Async Pipe: When dealing with Observables in Angular, using the async pipe in the template is a best practice – especially so with OnPush. The async pipe will subscribe to an Observable and push values into the template, and crucially, it will call markForCheck() on the component when a new value is emitted (Angular: Test Reactiveness with OnPush strategy | lacolaco's marginalia). This means your OnPush component will update correctly when the Observable emits, without any manual intervention. This is cleaner than subscribing in the component class and then having to call changeDetectorRef.markForCheck() yourself. In short, async pipe + OnPush is a potent combination for automatic, efficient UI updates.
Know When to Manually Trigger Change Detection: Even with OnPush, there are times you might need to manually tell Angular to check a component. The two main methods are:
- ChangeDetectorRef.markForCheck(): This will mark the component (and its ancestors) as dirty, so that on the next change detection cycle, Angular will include them in the check (typescript - Angular markForCheck vs detectChanges - Stack Overflow). Use this when you’ve updated some state that Angular didn’t catch (e.g. you imperatively changed a component’s input or a bound data structure) and you want Angular to pick it up in the next round. Marking for check is asynchronous with respect to the current code execution – it doesn’t immediately run change detection, it just schedules the component for checking soon.
- ChangeDetectorRef.detectChanges(): This method immediately triggers change detection for this component and its children, synchronously, at the moment you call it (typescript - Angular markForCheck vs detectChanges - Stack Overflow). It’s like telling Angular “check this view right now.” This can be useful if you need to ensure the UI reflects some changes instantaneously (for example, after an event callback outside of Angular’s zone, or in some complex timing scenarios). However, you should use this sparingly – calling detectChanges() frequently or in a loop can hurt performance, since it bypasses Angular’s usual batching. Also, if used inside an ongoing change detection cycle, it can lead to the infamous "expression has changed after it was checked" error if not careful (because you might be triggering nested checks).
Which one to use? In general, prefer markForCheck() for most cases when dealing with OnPush components. It works with Angular’s natural change detection schedule and ensures minimal checks (it will only re-check the needed branch on the next cycle, coalescing multiple changes if they happen). Use detectChanges() if you have a specific need to force an immediate check or to isolate change detection to a small part of the component tree manually. For example, after an external callback (like a setTimeout outside Angular’s NgZone), you might call detectChanges() to update the view right away. If you find yourself calling detectChanges() very often, consider if you can restructure your code to rely on Angular’s normal mechanism or the async pipe instead – too many manual calls can be a code smell indicating you’re fighting the framework.
Avoid ChangeDetectorRef in Most Cases: Ideally, if you design your component inputs and data flow in an Angular-friendly way (using immutable data and async pipes), you will rarely need to inject ChangeDetectorRef and call these methods manually. The framework will handle it. It’s not “wrong” to use them – they exist for valid cases – but if you rely heavily on markForCheck() or detectChanges(), double-check if there’s a more idiomatic approach. For instance, if you find you have to call markForCheck() after an @Input property mutation, that’s a hint you should be changing the @Input by reference instead of mutating.
Measure Performance Gains: OnPush can reduce the amount of work on each tick, but it also adds some complexity to your code (you have to manage change detection triggers consciously). Use tools like Angular DevTools or the performance timeline to measure if using OnPush in certain parts of your app yields visible performance improvements. Focus OnPush where the gains are significant (large lists, frequent updates, etc.). There’s no need to use OnPush everywhere by default – many apps perform just fine with the default strategy, but OnPush is there when you need that extra boost.

By following these practices – using immutable data patterns, the async pipe, and judicious manual change detection – you can harness OnPush to make your Angular application more performant. Next, we’ll discuss some tricky edge cases and pitfalls to be aware of when using OnPush.

Edge Cases and Common Pitfalls

While OnPush can speed up your app, it may surprise you if you’re not aware of certain gotchas. Here are some common pitfalls and how to handle them:

Mutating Object Inputs Without Changing Reference: If an OnPush component gets an object (or array) as an @Input and you mutate a property of that object without assigning a new object, Angular will not detect any change. This is because the reference of the object remains the same (=== comparison sees no difference) (Skipping component subtrees • Angular).
Manually Updating @Input Properties: Sometimes you might grab a child component instance via @ViewChild and set an @Input property on it directly in code, or otherwise set an input property outside of the normal template binding. If that child is OnPush, Angular won’t automatically know to run change detection for it, since it wasn’t updated through the usual binding mechanism. The OnPush child remains in its previous state (Skipping component subtrees • Angular). For example: @ViewChild(ChildComp) child: ChildComp; ... this.child.someInput = newVal; this.childCdr.markForCheck();. Alternatively, redesign to pass data via Input binding or service so Angular is aware of the change.
Using Observables with OnPush (without async pipe): If you subscribe to an Observable inside an OnPush component (in the component class) and update some state when it emits, that won’t automatically trigger change detection. For instance, you inject a service, subscribe to a stream in ngOnInit, and set a component field. In OnPush, unless that subscription callback calls markForCheck() or the value is passed in via Input, the view might not update. Solution: Again, the async pipe is your friend – it handles subscription and marking for check for you. But if you must subscribe in code (maybe to combine streams or use a single subscription for multiple values), then ensure you call this.cdr.markForCheck() inside the subscription handler to notify Angular of new data. This way the OnPush component will check its template on the next cycle when the Observable fires a value. (Alternatively, consider using detectChanges() if you need the update immediately during that subscription callback, though usually markForCheck is sufficient.)
Async Pipe Multiple Emissions: A related note – the async pipe will mark OnPush for check on each new emission. If an Observable emits frequently (e.g., many times a second), each emission schedules a change detection. This is usually fine (Angular can handle a lot of checks quickly), but be mindful of extremely high-frequency streams, as they could still cause performance issues if the UI work is heavy each time. In such cases, consider throttling/debouncing the stream or using strategies to drop frames (if applicable).
Calling detectChanges() at the Wrong Time: If you call changeDetectorRef.detectChanges() while Angular is already in the middle of a change detection cycle (for example, from within ngOnInit of a child while the parent is still being checked), you can run into the ExpressionChangedAfterItHasBeenChecked error. This is because you’re forcing an additional check in the middle of Angular’s normal check, confusing its before/after comparison. To avoid this, only call detectChanges() in places Angular isn’t actively checking (such as in a setTimeout callback, or in response to an event that Angular doesn’t know about). A safer approach if you need to trigger an extra check during initialization is to use setTimeout(() => cdr.detectChanges()) or Promise.resolve().then(() => cdr.detectChanges()) to postpone it to the next macrotask, after Angular’s cycle is done. Or simply design the component not to require this.
Default Change Detection inside OnPush subtree: If you have a mixture of strategies (some child components default, some OnPush), remember that a Default-strategy child inside an OnPush parent will still not run if the OnPush parent was skipped. The whole subtree is skipped if the parent OnPush doesn’t have a reason to run. This can be a pitfall: you might expect a Default child to always check, but if its OnPush ancestor isn’t running, it won’t check either. Essentially, OnPush “trickles down” – if a parent is skipped, all its descendants are skipped regardless of their own strategy. Solution: Ensure that if you rely on a Default child to update, the OnPush parent is being marked dirty appropriately (perhaps via markForCheck() when the child needs to update). Alternatively, consider making that child also OnPush for consistency, and manage its updates via inputs or events.

Being aware of these edge cases will help you avoid frustrating bugs where the UI doesn’t update. Most of these boil down to a simple rule: with OnPush, always change object references when you want updates, or explicitly tell Angular when something changes. If you follow that rule, you’ll rarely run into issues.

Diagrams and Visual Aids

Let’s visualize how OnPush can skip subtrees in a component tree. Consider the following component tree structure (OnPush components marked with "(OnPush)"):

AppComponent
├── HeaderComponent
├── MainComponent (OnPush)
│   ├── SearchComponent
│   └── ButtonComponent
└── LoginComponent (OnPush)
    └── DetailsComponent

In a normal change detection cycle (Default strategy everywhere), if an event happens anywhere, Angular would check every component from AppComponent down to DetailsComponent. Now, let’s illustrate how OnPush alters this:

Event in a Default component (e.g. HeaderComponent): Angular starts at AppComponent and goes down. It will check HeaderComponent (where the event occurred) and continue. When it gets to MainComponent (OnPush), since MainComponent did not receive any new @Input, Angular skips the entire MainComponent subtree (Skipping component subtrees • Angular). The result is better performance by avoiding needless checks in MainComponent and its children.
Event in an OnPush component (e.g. MainComponent): Angular runs the cycle for the whole tree, but now the event happened in MainComponent. So MainComponent will be checked (it’s marked dirty due to the event). Its children SearchComponent and ButtonComponent will also be checked (since the subtree is active). Meanwhile, LoginComponent (the other OnPush branch) is not part of this event’s subtree and got no new input, so Angular skips LoginComponent and its child (Skipping component subtrees • Angular). In effect, the MainComponent branch runs, the LoginComponent branch is ignored this time.
Event in a descendant of an OnPush (e.g. a button inside LoginComponent): Suppose the event is deep in LoginComponent’s template (LoginComponent is OnPush). Angular will mark LoginComponent as well as its ancestors for check. So LoginComponent runs, and since its parent (AppComponent) is also part of the view hierarchy, it will be checked too. However, other OnPush siblings, such as MainComponent, will be skipped unless they received new inputs or had their own events — this is the core idea behind skipping component subtrees. In this cycle, only the LoginComponent branch and its ancestors are re-evaluated — MainComponent remains untouched because it’s an independent OnPush subtree not involved in the event.
New input to OnPush (e.g. AppComponent passes new data to MainComponent): When AppComponent updates an @Input bound to MainComponent, Angular will, on the next cycle, check MainComponent and its children (Skipping component subtrees • Angular). If LoginComponent didn’t get anything new, it will be skipped. Essentially, only the MainComponent subtree refreshes. If LoginComponent also got a new input (say AppComponent also passed something new to it), then it would also refresh. OnPush ensures each subtree refreshes only if its direct inputs tell it to.

These scenarios can be visualized as portions of the tree turning “on” or “off” for change detection based on triggers. By looking at this tree, you can get a sense of how events or input changes cause certain branches to update while others remain untouched. This visual model reinforces the mental model: OnPush = don’t bother checking here unless something specific changed.

(In a live diagram or flowchart, we could highlight which components get checked (e.g., green) and which are skipped (red) for each scenario. You might imagine nodes lighting up when they’re checked. The key point is that OnPush prunes the tree of checks at the OnPush boundaries when appropriate.)

Signals and OnPush (Angular 17+)

Starting with Angular 16, and further enhanced in Angular 17 and above, Angular introduced Signals — a reactive state management primitive that integrates tightly with the OnPush change detection strategy.

What are Signals?

Signals are reactive variables that notify Angular when their value changes. When a signal is used in the template of an OnPush component, Angular automatically tracks its dependency and marks the component for check when the signal changes.

Why Signals Work Well with OnPush

With OnPush, Angular skips checking a component unless it has new inputs, an event, or manual detection. Signals add a fourth path: reactive values embedded in the component itself.

This allows components to be reactive without @Input bindings or manual markForCheck().

Example: OnPush Component with a Signal

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

@Component({
  selector: "counter-button",
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <p>Counter: {{ counter() }}</p>
    <button (click)="increment()">Increment</button>
  `,
})
export class CounterButtonComponent {
  counter = signal(0);

  increment() {
    this.counter.update((v) => v + 1);
  }
}

🔍 Note: Even though CounterButtonComponent is OnPush and has no inputs, Angular tracks usage of counter() in the template and triggers a check when it updates. This avoids the need for ChangeDetectorRef.markForCheck() entirely.

Signals as Inputs (Angular 17+)

Angular 17 introduced input() to define reactive @Input() properties as signals:

import { Component, input } from "@angular/core";

@Component({
  selector: "child",
  standalone: true,
  template: `<p>Received: {{ value() }}</p>`,
})
export class ChildComponent {
  value = input<string>();
}

Now, when the parent updates the input, Angular updates the signal — and OnPush change detection picks it up automatically without needing manual triggers.

When to Use Signals with OnPush

When you manage local reactive state inside OnPush components.
When building presentational components with reactive @Inputs.
When combining Observables and Signals for fine-grained UI updates.

Best Practices

Prefer signal() over BehaviorSubject or manual markForCheck() for local UI state.
Combine input() + effect() to build responsive components with clean data flow.
Use computed() to derive state based on multiple signals.

By combining Signals with OnPush, you get the best of both performance and reactivity.

Conclusion

Optimizing Angular’s change detection with the OnPush strategy is a powerful technique for improving application performance. By telling Angular to skip checking component subtrees unless necessary, you reduce the work done during each change detection cycle.

Key takeaways:

Default vs OnPush: Default change detection checks everything each time (simple but potentially heavy), whereas OnPush allows you to cut off branches of the component tree from being checked when nothing relevant changed in them.
OnPush Triggers: Remember the conditions that reenable checking for an OnPush component – new input references, events in its template or children, manual marks, or async pipe emissions. If none of these happen, the component can sit out the change detection dance.
Signals (Angular 16+): Signals offer a reactive, template-safe way to update UI in OnPush components without needing ChangeDetectorRef. They provide a clean, ergonomic alternative to BehaviorSubject for local state and input management.
Best Practices: Use OnPush on components that benefit from it (often presentational components, large lists, etc.), keep your inputs immutable, and prefer using the async pipe and output events to communicate changes. Reach for ChangeDetectorRef.markForCheck() when you need to nudge Angular that something changed, and use detectChanges() only when you absolutely need an immediate check.
Common Pitfalls: Be mindful of mutated objects not causing updates – always change references or explicitly mark for check in those cases. And ensure that any manual input setting or external data injection is accompanied by the necessary change detection trigger.

With the introduction of Signals, Angular now enables a more reactive and declarative style of building components—especially powerful when combined with OnPush. Together, they give developers fine-grained control and high performance without excessive boilerplate.

By following these techniques, you'll write more scalable, efficient, and maintainable Angular applications.

Happy coding!

Types vs Interfaces in TypeScript: Making the Right Choice

Anastasios Theodosiou — Sat, 14 Oct 2023 17:05:41 +0000

Types vs Interfaces in TypeScript: Making the Right Choice

Introduction

The TypeScript community has long debated the use of types and interfaces. Developers often wrestle with the decision of when to use one over the other. In this blog post, we'll explore the advantages and drawbacks of both, helping you make an informed choice that aligns with your coding style and project needs.

Phase One: Interfaces Are the Bomb

In the early days, interfaces were the favored option. The TypeScript Performance Wiki even claimed that interfaces were faster than types. It was believed that interfaces could boost the speed of the TypeScript type checker, making them ideal for performance-critical projects. However, interfaces had their limitations, primarily being designed for objects and functions.

Performance Considerations

It's important to clarify that when we talk about "speed," we're referring to the efficiency of the TypeScript type checker, not the runtime performance of your code. For large projects, a slow type checker can be a significant issue, pushing developers towards interfaces for potential performance improvements.

Benchmarking

To test this belief, a benchmark was conducted, comparing a thousand types to a thousand interfaces. The results were inconclusive and led to discussions with the TypeScript team, revealing new insights.

// Using an interface
interface Point {
  x: number;
  y: number;
}

// Using a type
type Coordinates = {
  x: number;
  y: number;
};

Phase Two: Consistency Is Key

Phase Two introduced a different perspective: the choice between types and interfaces doesn't matter as long as you maintain coding consistency. This viewpoint encouraged using interfaces for objects and types for other constructs, sparking debates in the TypeScript community.

Interface Inheritance

One key advantage of interfaces is their ability to inherit from other interfaces, a feature not easily achieved with types.

interface Shape {
  color: string;
}

interface Circle extends Shape {
  radius: number;
}

Phase Three: The Need for Specific Features

A turning point occurred when the inventor of AngularJS encountered issues with interfaces, especially regarding appending properties, which led to unpredictable behavior.

Declaration Merging

Interfaces introduced "declaration merging," a valuable feature in some scenarios but one that could add complexity when different interfaces shared the same name and scope.

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

interface Product {
  description: string;
}

Conclusion: Making the Right Choice

In Phase Three, the ultimate recommendation is to use types unless you specifically need features provided by interfaces. Types offer predictability and are less likely to exhibit unexpected behavior. Importantly, there is no discernible performance difference between types and interfaces.

Consider Your Needs

Your choice between types and interfaces should align with your project's unique requirements and your personal coding style. If you need inheritance, want to extend another type, or come from an object-oriented programming background, interfaces may be your preferred choice. However, if predictability and control are your priorities, types are the more suitable option.

In summary, there is no one-size-fits-all solution. Your choice should be guided by your project's demands and your familiarity with TypeScript's intricacies.

So, the next time you face the decision of types vs. interfaces in TypeScript, remember this post. Let it guide you in making an informed choice that best fits your coding style.

Happy coding! Like, subscribe, and stay tuned for more enlightening content.

Exploring Dynamic Component Creation in Angular 16

Anastasios Theodosiou — Fri, 06 Oct 2023 12:57:31 +0000

In the wake of Angular's version 13 release, a fresh approach to dynamic component usage was unveiled, aiming to streamline the process. The question on everyone's mind: Did this update genuinely simplify dynamic component creation? To find out, we'll dive into the world of Angular version 16 and explore its newfound capabilities.

This article was originally published on Anastasios Theodosiou Blog.

Before we delve into the details, it's worth noting that in 2023, there are some intriguing Angular development tools you might want to explore alongside this dynamic component journey.

The core idea here is to harness Dynamic Parameters to determine which Angular Component should be dynamically generated. To achieve this, let's take a look at how our route configuration should be structured:

// Root Routes with lazy loaded Services Component
const routes: Routes = [
  // Other routes...
  {
    path: 'services/:id',
    loadChildren: () => import('./services/services.module').then((m) => m.ServicesModule),
  },
];

In the route configuration above, the focus lies on line 6, where the dynamic parameter, ":id," is declared. This parameter will become accessible using the ActivatedRoute class, which is injected into the constructor via dependency injection. Here's an example of how you can access these dynamic parameters:

// Initial ServicesComponent implementation
import { ActivatedRoute } from '@angular/router';

// ...


constructor(private route: ActivatedRoute) {
  this.route.params.subscribe((params) => {
    // Access dynamic parameter here using params['id']
  });
}

To avoid memory leaks, always remember to unsubscribe when your component is being destroyed, as not doing so can lead to issues. Now, let's move on to the core of our topic.

The Angular Team recommends creating a separate directive containing an injected ViewContainerRef class. This directive can then be reused across different components without the need for additional dependency injection in each component where dynamic components might be required. Here's an example implementation of such a directive:

// Example usage of ComponentHostDirective
<app-component-host></app-component-host>

Angular 16 introduces a self-closing tag syntax similar to React's, which enhances code readability. Now that the directive is in place, you can use the @ViewChild decorator to access the publicly available viewContainerRef within your services.component class:

// Accessing viewContainerRef in services.component.ts
import { ComponentHostDirective } from '../directives/component-host.directive';
import { ViewChild } from '@angular/core';

export class ServicesComponent {
  @ViewChild(ComponentHostDirective) componentHost: ComponentHostDirective;

  // ...
}

With the viewContainerRef in hand, you can proceed to create dynamic components. The method for handling component creation involves clearing any previously created component instances and then instantiating a new component based on the service id obtained from the servicesComponentFactory definition:

// Method to handle dynamic component creation
createDynamicComponent(serviceId: number) {
  this.componentHost.viewContainerRef.clear();
  const componentFactory = this.servicesComponentFactory.getServiceComponentFactory(serviceId);
  const componentRef = componentFactory.create(this.injector);
  this.componentHost.viewContainerRef.insert(componentRef.hostView);
}

It's important to note that this implementation serves as an example and may not cover all use cases. You can customize it further to ensure proper mapping between parameters and component types.

The servicesComponentFactory definition might look something like this:

// Definition of servicesComponentFactory
import { Injectable } from '@angular/core';
import { ServiceTypes } from '../models/service-types.enum';

@Injectable({
  providedIn: 'root',
})
export class ServicesComponentFactory {
  getServiceComponentFactory(serviceId: number) {
    // Implement logic to return the appropriate component factory based on serviceId
  }
}

In summary, your services.component.ts class should look similar to the one depicted above. With this setup, you can dynamically create child components based on the provided service id. As you can see, Angular 16 has made dynamic component creation appear quite straightforward, thanks to its latest features.

And there you have it! Dynamic component creation in Angular 16, with a fresh perspective and a cleaner approach. Kudos to the Angular Team for this update!

Find more in my personal blog here.

Angular Reactive Typed Forms - Not just a dream

Anastasios Theodosiou — Thu, 14 Jul 2022 18:01:12 +0000

It's been a while since I last wrote an article. When the new Angular version 14 was released I was quite satisfied with two new features and I wanted to share it with you. The first is Typed Reactive Forms and the second is Standalone Components.

Original Source: Anastasios Theodosiou Blog

After 6 years of the first release, and after months of discussion and feedback, the most needed feature and up-voted issue in the Angular repository is now solved in Angular v14!

Angular 14 was released 2nd of June with the most significant update since Ivy. It includes two long-awaited features, Typed Reactive Forms and Standalone Components, as well as several minor improvements.

On this article we will focus on Typed Reactive Forms. As before Angular v14, Reactive Forms did not include type definitions in many of its classes, and TypeScript would not catch bugs like in the following example during compilation.

  const loginForm = new FormGroup({
    email: new FormControl(''),
    password: new FormControl(''),
  });

  console.log(login.value.username);

With Angular 14, the FormGroup, formControl, and related classes include type definitions enabling TypeScript to catch many common errors.

Migration to the new Typed Reactive Forms is not automatic.

The already existing code containing FormControls, FormGroups, etc.. will be prefixed as Untyped during the upgrade. It is important to mention that if developers would like to take advantage of the new Typed Reactive Forms, must manually remove the Untyped prefix and fix any errors that may arise.

More details about this migration can be found at the official Typed Reactive Forms documentation.

A step by step migration example of an untyped reactive form

Let's say that we have the following register form.

  export class RegisterComponent {
    registerForm: FormGroup;

    constructor() {
      this.registerForm = new FormGroup({
        login: new FormControl(null, Validators.required),
        passwordGroup: new FormGroup({
          password: new FormControl('', Validators.required),
          confirm: new FormControl('', Validators.required)
        }),
        rememberMe: new FormControl(false, Validators.required)
      });
    }
  }

Angular also provided an automated migration to speed up the process. This migration will run when we as developers, run the following command.

ng update @angular/core or on demand, if we already manually updated your project by running the next command. ng update @angular/core --migrate-only=migration-v14-typed-forms .

In our example, if we use the automated migration, we end up with the above changed code.

export class RegisterComponent {
  registerForm: UntypedFormGroup;

  constructor() {
    this.registerForm = new UntypedFormGroup({
      login: new UntypedFormControl(null, Validators.required),
      passwordGroup: new UntypedFormGroup({
        password: new UntypedFormControl('', Validators.required),
        confirm: new UntypedFormControl('', Validators.required)
      }),
      rememberMe: new UntypedFormControl(false, Validators.required)
    });
  }
}

The next step now is to remove all the Untyped* usage and adjust properly our form.

Each UntypedFormControl must be converted to FormControl, with T the type of the value of the form control. Most of the time, TypeScript can infer this information based on the initial value given to the FormControl.

For example, passwordGroup can be converted easily:

passwordGroup: new FormGroup({
  password: new FormControl('', Validators.required), // inferred as `FormControl<string | null>`
  confirm: new FormControl('', Validators.required) // inferred as `FormControl<string | null>`
})

Note that the inferred type is string | null and not string. This is because calling .reset() on a control without specifying a reset value, resets the value to null. This behavior is here since the beginning of Angular, so the inferred type reflects it. We’ll come back to this possibly null value, in an example bellow, as it can be annoying (but there is always a way).

Now let’s take the field registerForm. Unlike FormControl, the generic type expected by FormGroup is not the type of its value, but a description of its structure, in terms of form controls:

registerForm: FormGroup<{
  login: FormControl<string | null>;
  passwordGroup: FormGroup<{
    password: FormControl<string | null>;
    confirm: FormControl<string | null>;
  }>;
  rememberMe: FormControl<boolean | null>;
}>;

constructor() {
  this.registerForm = new FormGroup({
    login: new FormControl<string | null>(null, Validators.required),
    passwordGroup: new FormGroup({
      password: new FormControl('', Validators.required),
      confirm: new FormControl('', Validators.required)
    }),
    rememberMe: new FormControl<boolean | null>(false, Validators.required)
  });
}

Nullability in forms

As we can see above, the types of the controls are string | null and boolean | null, and not string and boolean like we could expect. This is happening because if we call the .reset() method on a field, resets its value to null. Except if we give a value to reset, for example .reset(''), but as TypeScript doesn’t know if and how you are going to call .reset(), the inferred type is nullable.

We can tweek behavior by passing the nonNullable options (which replaces the new option introduced in Angular v13.2 initialValueIsDefault). With this option, we can get rid of the null value if we want to!

On one hand, this is very handy if your application uses strictNullChecks, but on the other hand, this is quite verbose, as we currently have to set this option on every field (hope this change in the future).

registerForm = new FormGroup({
  login: new FormControl<string>('', { validators: Validators.required, nonNullable: true }),
  passwordGroup: new FormGroup({
    password: new FormControl('', { validators: Validators.required, nonNullable: true }),
    confirm: new FormControl('', { validators: Validators.required, nonNullable: true })
  }),
  rememberMe: new FormControl<boolean>(false, { validators: Validators.required, nonNullable: true })
}); // incredibly verbose version, that yields non-nullable types

One other way to achieve the same result, is to use the NonNullableFormBuilder. A new property introduced by Angular v14 called nonNullable, that returns a NonNullableFormBuilder which contains the usual as known control, group, array, etc. methods to build non-nullable controls.

Example of creating a non-nullable form grop:

constructor(private fb: NonNullableFormBuilder) {}

registerForm = this.fb.group({
  login: ['', Validators.required]
});

So, does this migration wort it? What do we gain with Typed Reactive Forms?

Before Angular v14, the existing forms API does note performing very well with TypeScript because every form control value is typed as any. So, we could easily write something like this.registerForm.value.something and the application would compile successfully.

This is no longer the case: the new forms API properly types value according to the types of the form controls. In my example above (with nonNullable), the type of this.registerForm.value is:

// this.registerForm.value
{
  login?: string;
  passwordGroup?: {
    password?: string;
    confirm?: string;
  };
  rememberMe?: boolean;
}

We can spot some ? in the type of the form value. What does it mean?

It is widely known that in Angular, we can disable any part of our form we wan to and if so, Angular will automatically remove the value of a disabled control from the value of the form.

this.registerForm.get('passwordGroup').disable();
console.log(this.registerForm.value); // logs '{ login: null, rememberMe: false }'

The above result is a bit strange but it explains sufficiently why the fields are marked as optional if they have been disabled. So, they are not part of the this.registerForm.value any more. TypeScript calls this feature Partial value.

There is also a way to get the hole object even with the disabled fields, by running the .getRawValue() function on the form.

{
  login: string;
  passwordGroup: {
    password: string;
    confirm: string;
  };
  rememberMe: boolean;
} // this.registerForm.getRawValue()

Even more strictly typed .get() function

The get(key) method is also more strictly typed. This is great news, as we could previously call it with a key that did not exist, and the compiler would not see the issue.

Thanks to some hardcore TypeScript magic, the key is now checked and the returned control is properly typed! It is also works with array syntax for the key as bellow.

his.registerForm.get('login') // AbstractControl<string> | null
this.registerForm.get('passwordGroup.password') // AbstractControl<string> | null

//Array Syntax
this.registerForm.get(['passwordGroup', '.password'] as const) // AbstractControl<string> | null

Also works with nested form arrays and groups and if we use a key that does not exist we can finally get an error:

this.registerForm.get('hobbies.0.name') // AbstractControl<string> | null 

//Non existing key
this.registerForm.get('logon' /* typo */)!.setValue('cedric'); // does not compile

As you can see, get() returns a potentially null value: this is because you have no guarantee that the control exists at runtime, so you have to check its existence or use ! like above.

Note that the keys you use in your templates for formControlName, formGroupName, and formArrayName aren’t checked, so you can still have undetected issues in your templates.

Something fresh: FormRecord

FormRecord is a new form entity that has been added to the API. A FormRecord is similar to a FormGroup but the controls must all be of the same type. This can help if you use a FormGroup as a map, to which you add and remove controls dynamically. In that case, properly typing the FormGroup is not really easy, and that’s where FormRecord can help.

It can be handy when you want to represent a list of checkboxes for example, where your user can add or remove options. For example, our users can add and remove the language they understand (or don’t understand) when they register:

languages: new FormRecord({
  english: new FormControl(true, { nonNullable: true }),
  french: new FormControl(false, { nonNullable: true })
});

// later 
this.registerForm.get('languages').addControl('spanish', new FormControl(false, { nonNullable: true }));

If we try to add a control of a different type, TS throws a compilation error!

But as the keys can be any string, there is no type-checking on the key in removeControl(key) or setControl(key). Whereas if you use a FormGroup, with well-defined keys, you do have type checking on these methods: setControl only allows a known key, and removeControl only allows a key marked as optional (with a ? in its type definition).

If we have a FormGroup on which we want to add and remove control dynamically, we’re probably looking for the new FormRecord type.

Conclusion

I’m very excited to see this new forms API in Angular! This is, by far, one of the biggest changes in recent years for developers. Ivy was big but didn’t need us to make a lot of changes in our applications. Typed forms are another story: the migration is likely to impact dozens, hundreds, or thousands of files in our applications!

The TypeScript support in Angular has always been outstanding, but had a major blind spot with forms: this is no longer the case!

So, yes. It is totally worth it!!

Till next time,
Happy coding.

DEV Community: Anastasios Theodosiou

The Missing Piece in Angular i18n

How to stop breaking translations every time your app changes

Where things actually go wrong

What xlf-sync is designed to do

Metadata is the real differentiator

Handling change without deleting history

Designed for real Angular codebases

Visibility and automation matter

A missing piece Angular never shipped: a translation dashboard

How this differs from other tools

Learn more

Closing thought

How I Built a Plugin-Based Architecture in Angular 19+ 💉

Why I Needed It

⚙️ The Hidden Power of Multi-Providers

Step 1 – Define the Plugin Contract

Minimum Angular version: 19+ (uses provideAppInitializer)

Step 2 – A Registry to Run Them All

Step 3 – Bootstrap Cleanly with provideAppInitializer

Compatibility (Angular 15–18):

Step 4 – Real Plugins in Action

Step 5 – Feature-Scoped Plugins

⚡ What This Gives You

Why It Matters

Looking Ahead

💬 Final Thoughts

Async in JavaScript, Served Hot: The Chef’s guide to the Event Loop

How do the Chef and Kitchen communicate? (The Real Story)

Code Analogy: The communication in action

What really happens?

A Peek behind the kitchen door: Microtasks vs Macrotasks

Common Gotchas: Where most developers get surprised

What about events like clicks or keyboard input?

And If Things Get Crazy? (Infinite Microtasks, Starvation, etc)

Advanced Extras: Animation Frames, Node.js, and more complex examples

What about requestAnimationFrame?

What about Node.js? (Event Loop Phases)

Complex Code Execution: Step-by-step Examples

Example 1: Chained Promises vs setTimeout

Example 2: setTimeout inside a Promise

Example 3: Starvation with Endless Microtasks

Example 4: Animation, Microtasks, and Timers Together

Tip:

Conclusion: What should you take away?

Optimizing Angular Change Detection with OnPush: Skipping Subtrees for Performance

TL;DR

Introduction

Understanding Change Detection Scenarios

1. Events in a Component with Default Change Detection

2. Events in a Component with OnPush

3. Events in a Descendant of an OnPush Component

4. Receiving New Inputs in an OnPush Component

Performance Optimizations and Best Practices

Edge Cases and Common Pitfalls

Diagrams and Visual Aids

Signals and OnPush (Angular 17+)

What are Signals?

Why Signals Work Well with OnPush

Example: OnPush Component with a Signal

Signals as Inputs (Angular 17+)

When to Use Signals with OnPush

Best Practices

Conclusion

Happy coding!

Types vs Interfaces in TypeScript: Making the Right Choice

Types vs Interfaces in TypeScript: Making the Right Choice

Introduction

Phase One: Interfaces Are the Bomb

Performance Considerations

Benchmarking

Phase Two: Consistency Is Key

Interface Inheritance

Phase Three: The Need for Specific Features

Declaration Merging

Conclusion: Making the Right Choice

Consider Your Needs

Exploring Dynamic Component Creation in Angular 16

Angular Reactive Typed Forms - Not just a dream

Migration to the new Typed Reactive Forms is not automatic.

Step 3 – Bootstrap Cleanly with `provideAppInitializer`