Mastering Advanced Angular: A Deep Dive into Reactive, Performant, and Maintainable Applications

Welcome to this comprehensive guide on mastering advanced Angular development! In the ever-evolving landscape of web development, Angular continues to innovate, offering powerful tools and patterns for building scalable, high-performance applications. This document is crafted for developers who have a foundational understanding of Angular and are ready to dive deep into its most sophisticated features and underlying mechanisms.

Angular 20 marks a significant leap forward, introducing features like stable Signals, production-ready Zoneless Change Detection, a new built-in control flow syntax, and enhanced SSR. By the end of this guide, you will not only understand these concepts but also gain practical experience through numerous code examples and guided projects, enabling you to build cleaner, more efficient, and robust Angular applications.

1. Introduction to Angular

What is Angular?

Angular is a popular, open-source framework developed by Google for building single-page applications (SPAs) and complex web applications. It provides a structured and opinionated approach to development, focusing on maintainability, scalability, and performance. Written in TypeScript, a superset of JavaScript, Angular offers strong typing, which aids in catching errors early and improving code quality.

At its core, Angular applications are built around components, which are self-contained units of UI and logic. These components communicate with each other, manage state, and interact with services to perform business logic and data fetching.

Why Learn Angular? (Benefits, Use Cases, Industry Relevance)

Learning Angular in depth is a valuable investment for several reasons:

• Robust Framework: Angular provides a complete ecosystem for web development, including routing, state management, forms, and HTTP communication, reducing the need for many third-party libraries.
• Scalability: Its modular architecture and strong typing make it an excellent choice for large-scale enterprise applications with multiple developers and long-term maintenance needs.
• Performance: With continuous advancements like Signals, Zoneless Change Detection, and improved SSR, Angular is highly optimized for performance, leading to faster loading times and smoother user experiences.
• Developer Experience (DX): The Angular CLI (Command Line Interface) significantly boosts productivity by automating tasks like project setup, component generation, and testing. Features like Hot Module Replacement (HMR) and a rich IDE integration further enhance DX.
• Strong Community & Ecosystem: Backed by Google, Angular has a vast and active community, extensive documentation, and a rich ecosystem of tools and libraries.
• Career Opportunities: Angular is widely adopted by many companies, from startups to large enterprises, ensuring a strong demand for skilled Angular developers.

Use Cases: Angular is ideal for a wide range of applications, including:

• Enterprise Web Applications: Complex business applications, dashboards, and internal tools.
• Single-Page Applications (SPAs): Interactive and dynamic web experiences.
• Progressive Web Apps (PWAs): Web applications that offer an app-like experience with offline capabilities.
• Cross-Platform Mobile Apps: Using Ionic or NativeScript.
• Micro Frontends: Decomposing large applications into smaller, independently deployable units.

A Brief History (Optional, keep it concise)

Angular’s journey began with AngularJS (version 1.x) in 2010. While revolutionary for its time, it faced performance and architectural challenges. In 2016, Angular (often referred to as Angular 2+) was a complete rewrite, offering a component-based architecture, TypeScript, and significantly improved performance. Since then, Angular has followed a predictable release schedule, delivering major updates every six months, with a strong focus on backward compatibility and migration paths. Angular 20 (released in May 2025) represents a significant evolution, solidifying its commitment to modern web standards and fine-grained reactivity.

Setting up your development environment

To embark on your advanced Angular journey, you’ll need a stable development environment. Follow these steps:

1. Install Node.js: Angular applications run on Node.js and leverage its package manager, npm. Angular 20 requires Node.js version 20.19 or higher.

   • Download the latest LTS version from the official Node.js website.
   • Verify installation:

     node -v
     npm -v
     

2. Install Angular CLI: The Angular CLI is your primary tool for creating, developing, and maintaining Angular applications.

   • Install it globally:

     npm install -g @angular/cli@20
     

   • Verify installation:

     ng version
     

3. Choose a Code Editor: Visual Studio Code (VS Code) is highly recommended due to its excellent TypeScript support and a rich ecosystem of Angular extensions.

   • Download and install VS Code from the official website.

4. Create a New Angular Project (with Angular 20 features):

   • Open your terminal or command prompt.
   • Navigate to the directory where you want to create your project.
   • Use the ng new command. For Angular 20, you can enable zoneless change detection and standalone components from the start:

     ng new my-advanced-angular-app --standalone --zoneless
     

     • The --standalone flag initializes the project using standalone components, which is the recommended future-proof approach, eliminating the need for NgModules in many cases.
     • The --zoneless flag enables zoneless change detection from the get-go, leveraging the new reactivity model.
     • The CLI will prompt you for routing and stylesheet format (e.g., CSS, SCSS). For this guide, SCSS is often a good choice.

5. Run Your Application:

   • Navigate into your new project directory:

     cd my-advanced-angular-app
     

   • Start the development server:

     ng serve --open
     

     This command compiles your application and launches it in your default web browser at http://localhost:4200/. The --open flag automatically opens a new browser tab.

Now your environment is set up, and you’re ready to explore the advanced concepts of Angular 20!

2. Core Reactivity & Change Detection (The “Why” and “How”)

Understanding how Angular detects changes and updates the UI is fundamental to building performant applications. Angular 20 brings a significant evolution in this area, moving towards a more fine-grained and efficient reactivity model.

1. Signals (Deep Dive into signal(), computed(), effect())

Signals are the most significant paradigm shift in Angular’s reactivity. They offer fine-grained reactivity, where only the parts of the UI that depend on a changing value are updated, leading to better performance and predictability.

What are Signals?

A signal is a wrapper around a value that notifies interested consumers when that value changes. Think of it as a special container that holds a value and broadcasts whenever its contents change.

• signal(): Creates a writable signal that holds a value. You can read its value by calling it as a function (mySignal()) and update it using .set() or .update().
• computed(): Creates a read-only signal that derives its value from one or more other signals. It automatically re-evaluates and updates its value only when its dependencies change, and it’s lazily evaluated.
• effect(): Registers a side-effect that runs whenever one of its dependent signals changes. Effects are for synchronizing reactive state with external systems (e.g., logging, DOM manipulation outside Angular’s rendering, making API calls). Crucially, effects should not directly update other signals to avoid infinite loops.

Mechanism: How Signals Track Dependencies Automatically

Signals achieve fine-grained reactivity through a dependency tracking mechanism. When a computed() signal or an effect() runs, it automatically “subscribes” to any signal() values it reads. When a signal()’s value changes, it only notifies its direct consumers (other computed()s or effect()s) that depend on it, which then trigger their re-evaluation. This contrasts sharply with Zone.js, which broadly detects any asynchronous operation and triggers a potentially wide change detection cycle.

Example: Basic Signal Usage

Let’s create a simple counter component using signals.

// src/app/counter/counter.component.ts
import { Component, signal, computed, effect, OnInit, OnDestroy, EffectRef } from '@angular/core';
import { CommonModule } from '@angular/common'; // Needed for standalone components if not already imported

@Component({
  selector: 'app-counter',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card">
      <h2>Signal Counter</h2>
      <p>Current Count: {{ count() }}</p>
      <p>Doubled Count: {{ doubledCount() }}</p>
      <p>Is Even: {{ isEven() ? 'Yes' : 'No' }}</p>

      <button (click)="increment()">Increment</button>
      <button (click)="decrement()">Decrement</button>
      <button (click)="reset()">Reset</button>

      <input type="number" [value]="count()" (input)="setCount($event)" />
    </div>
  `,
  styles: [`
    .card {
      border: 1px solid #ccc;
      padding: 20px;
      margin: 20px;
      border-radius: 8px;
      text-align: center;
    }
    button {
      margin: 5px;
      padding: 10px 15px;
      font-size: 16px;
      cursor: pointer;
    }
    input {
      margin-top: 10px;
      padding: 8px;
      font-size: 16px;
      width: 100px;
      text-align: center;
    }
  `]
})
export class CounterComponent implements OnInit, OnDestroy {
  // Writable signal for the count
  count = signal(0);

  // Computed signal for doubled count
  doubledCount = computed(() => this.count() * 2);

  // Computed signal to check if the count is even
  isEven = computed(() => this.count() % 2 === 0);

  // Effect to log changes to the console
  private countEffect: EffectRef;

  constructor() {
    // Effects are typically created in the constructor or using `inject`
    this.countEffect = effect(() => {
      console.log(`Count changed to: ${this.count()} (Doubled: ${this.doubledCount()}, Even: ${this.isEven()})`);
      // Example of a side effect: update browser title
      document.title = `Count: ${this.count()}`;
    });
  }

  ngOnInit(): void {
    // You could also create effects here, but constructor is common for component-level effects
  }

  ngOnDestroy(): void {
    // It's good practice to destroy effects manually if they are not automatically destroyed with component
    this.countEffect.destroy();
  }

  increment() {
    // Update signal based on its previous value
    this.count.update(value => value + 1);
  }

  decrement() {
    this.count.update(value => value - 1);
  }

  reset() {
    // Set signal to a specific value
    this.count.set(0);
  }

  setCount(event: Event) {
    const value = parseInt((event.target as HTMLInputElement).value, 10);
    if (!isNaN(value)) {
      this.count.set(value);
    }
  }
}

Exercise:

1. Integrate the CounterComponent into your AppComponent.
2. Observe the console logs and the browser tab title as you interact with the counter. Notice how doubledCount and isEven automatically update when count changes, without any explicit calls.

Interoperability: RxJS Observables to Signals (toSignal()) and Vice-Versa (toObservable())

While signals are powerful for UI state, RxJS Observables remain crucial for complex asynchronous operations, event streams, and reactive programming patterns. Angular provides utilities to bridge these two reactivity models.

• toSignal(): Converts an RxJS Observable into a Signal. The signal will emit a new value whenever the observable emits. It handles subscriptions and unsubscribes automatically when the component or injector scope is destroyed.

  // src/app/data-fetcher/data-fetcher.component.ts
  import { Component, signal, inject } from '@angular/core';
  import { HttpClient, HttpClientModule } from '@angular/common/http';
  import { toSignal } from '@angular/core/rxjs-interop'; // Important import
  import { CommonModule } from '@angular/common';
  import { of, delay, catchError } from 'rxjs';
  
  interface User {
    id: number;
    name: string;
    email: string;
  }
  
  @Component({
    selector: 'app-data-fetcher',
    standalone: true,
    imports: [CommonModule, HttpClientModule],
    template: `
      <div class="card">
        <h2>Data Fetcher with toSignal()</h2>
        <button (click)="fetchUser(currentUserId())">Fetch User {{ currentUserId() }}</button>
        <button (click)="nextUser()">Next User</button>
  
        @if (user()?.name) {
          <div>
            <h3>User Details:</h3>
            <p>ID: {{ user()?.id }}</p>
            <p>Name: {{ user()?.name }}</p>
            <p>Email: {{ user()?.email }}</p>
          </div>
        } @else if (user() === undefined) {
          <p>Loading user data...</p>
        } @else if (user() === null) {
          <p style="color: red;">Error loading user. Please try again.</p>
        }
      </div>
    `,
    styles: [`
      .card {
        border: 1px solid #ccc;
        padding: 20px;
        margin: 20px;
        border-radius: 8px;
        text-align: center;
      }
      button {
        margin: 5px;
        padding: 10px 15px;
        font-size: 16px;
        cursor: pointer;
      }
    `]
  })
  export class DataFetcherComponent {
    private http = inject(HttpClient);
    currentUserId = signal(1);
  
    // Convert an Observable to a Signal
    // `initialValue: undefined` means the signal will initially be undefined
    // until the observable emits its first value.
    // `toSignal` automatically handles subscription and unsubscription.
    user = toSignal(
      this.http.get<User>(`https://jsonplaceholder.typicode.com/users/${this.currentUserId()}`).pipe(
        delay(500), // Simulate network delay
        catchError((err) => {
          console.error('Error fetching user:', err);
          return of(null); // Emit null on error so signal has a value
        })
      ),
      { initialValue: undefined } // `undefined` for loading, `null` for error
    );
  
    fetchUser(id: number) {
      this.currentUserId.set(id);
      // Note: `toSignal` will automatically re-subscribe to the observable
      // when `currentUserId()` changes, triggering a new HTTP request.
    }
  
    nextUser() {
      this.currentUserId.update(id => (id % 10) + 1); // Cycle through users 1-10
    }
  }
  

  Explanation: When currentUserId signal changes, the toSignal function automatically detects this change because it’s part of the observable’s dependency graph. It then triggers a new HTTP request with the updated ID. The user signal will reflect the loading state (initially undefined), then the data, or null on error.

• toObservable(): Converts a Signal into an RxJS Observable. The observable will emit whenever the signal’s value changes. This is useful when you need to integrate a signal’s value into an existing RxJS pipeline.

  // src/app/signal-to-observable/signal-to-observable.component.ts
  import { Component, signal, effect, inject, OnInit } from '@angular/core';
  import { CommonModule } from '@angular/common';
  import { toObservable } from '@angular/core/rxjs-interop'; // Important import
  import { debounceTime, filter, tap } from 'rxjs/operators';
  
  @Component({
    selector: 'app-signal-to-observable',
    standalone: true,
    imports: [CommonModule],
    template: `
      <div class="card">
        <h2>Signal to Observable Interop</h2>
        <input type="text" [value]="searchTerm()" (input)="updateSearchTerm($event)" placeholder="Search...">
        <p>Current Search Term (Signal): {{ searchTerm() }}</p>
        <p>Debounced Search Term (Observable): {{ debouncedSearchTerm }}</p>
      </div>
    `,
    styles: [`
      .card {
        border: 1px solid #ccc;
        padding: 20px;
        margin: 20px;
        border-radius: 8px;
        text-align: center;
      }
      input {
        padding: 8px;
        font-size: 16px;
        width: 250px;
      }
    `]
  })
  export class SignalToObservableComponent implements OnInit {
    searchTerm = signal('');
    debouncedSearchTerm: string = '';
  
    constructor() {}
  
    ngOnInit() {
      // Convert the `searchTerm` signal to an Observable
      toObservable(this.searchTerm)
        .pipe(
          debounceTime(500), // Wait 500ms after last keystroke
          filter(term => term.length > 2 || term.length === 0), // Only search for terms > 2 chars or empty
          tap(term => {
            console.log('API call simulation for term:', term);
            // In a real app, you'd make an HTTP call here
            this.debouncedSearchTerm = term; // Update local state for display
          })
        )
        .subscribe(); // `toObservable` manages subscription cleanup with component lifecycle
    }
  
    updateSearchTerm(event: Event) {
      this.searchTerm.set((event.target as HTMLInputElement).value);
    }
  }
  

  Explanation: The searchTerm signal updates immediately with user input. However, the toObservable utility allows us to treat this signal as a source for an RxJS pipeline, applying debounceTime and filter operators before performing a simulated API call.

Exercise:

1. Add DataFetcherComponent and SignalToObservableComponent to your AppComponent.
2. Interact with both components. Observe how toSignal automatically refreshes data when currentUserId changes, and how toObservable applies debouncing to the search input.

Best Practices: When to use Signals vs. RxJS, avoiding common pitfalls in effect()

• Signals for UI state: Prefer signals for simple, synchronous, and frequently changing UI state within components (e.g., isOpen, selectedId, count). They offer better readability and simpler management for these scenarios.
• RxJS for complex async flows: Continue using RxJS for complex asynchronous operations like HTTP requests, WebSockets, event streams, and orchestrating multiple data sources. Its rich set of operators is unmatched for transforming, combining, and handling these streams.
• Bridge them strategically: Use toSignal() to bring asynchronous data from services (often RxJS-based) into components for UI rendering with signals. Use toObservable() when a signal’s value needs to initiate a complex RxJS pipeline.
• effect() pitfalls:
  • Don’t update other signals inside effect() directly: This can lead to infinite loops or unexpected behavior. If you need to derive state, use computed().
  • Effects are for side effects: Use them for things like logging, modifying the DOM outside of Angular’s template, interacting with browser APIs (e.g., localStorage), or making network requests (but consider the new resource() API for this, covered later).
  • Cleanup effects: While effect() typically cleans itself up when the injector is destroyed (e.g., component destroyed), for long-lived effects or those created imperatively, ensure manual destruction using effectRef.destroy().

Performance implications: How signals lead to better performance compared to Zone.js

Zone.js works by patching asynchronous browser APIs (like setTimeout, addEventListener, fetch). Whenever one of these patched APIs completes, Zone.js tells Angular that something might have changed, triggering a full change detection cycle from the application’s root. This global check, even if only a small part of the UI actually changed, can be a performance bottleneck in large applications.

Signals, on the other hand, enable fine-grained reactivity. When a signal changes, only the computed() signals and effect()s that directly depend on it are re-evaluated. This creates a highly optimized dependency graph, ensuring that Angular only updates the minimum necessary parts of the DOM. This significantly reduces the overhead of change detection, leading to:

• Faster rendering: Fewer components need to be checked and re-rendered.
• Smaller bundle sizes: As Angular moves away from Zone.js, the zone.js polyfill can potentially be removed, reducing the application’s initial download size.
• Improved debugging: Stack traces become cleaner without Zone.js’s “monkey patching,” making it easier to pinpoint the origin of changes.

2. Zoneless Change Detection (Stable in Angular 20.2)

Zoneless change detection is the future of Angular’s change detection strategy, offering significant performance improvements and a more predictable reactivity model. As of Angular v20.2, zoneless APIs are stable and production-ready.

Zone.js vs. Zoneless: The fundamental differences and why Angular is moving away from Zone.js

• Zone.js (Default behavior pre-Zoneless):

  • Global Change Detection: Zone.js intercepts all asynchronous events (user interactions, timers, HTTP requests) and triggers a global change detection cycle across the entire application’s component tree.
  • Pros: Automatically ensures UI updates for almost any change, easy for beginners.
  • Cons: Performance overhead (even minor changes trigger widespread checks), larger bundle size (due to Zone.js polyfill), harder to debug (stack traces are convoluted).

• Zoneless Change Detection:

  • Explicit & Fine-grained: Relies on Angular’s own reactive primitives (Signals, AsyncPipe, HostListener) to explicitly inform the framework when a part of the UI needs updating. No global “dirty checking.”
  • Pros: Significant performance gains (only relevant parts of the UI are checked), smaller bundle sizes (Zone.js can be removed), cleaner debugging, better interoperability with other libraries that don’t rely on Zone.js.
  • Cons: Requires a more explicit understanding of reactivity. Developers need to ensure all changes that affect the UI are driven by signals, inputs, or event listeners that Angular can track.

Angular is moving away from Zone.js primarily to improve performance, reduce bundle sizes, and enhance the debugging experience. The shift empowers developers with more control and predictability over the change detection mechanism.

How to enable and configure provideZonelessChangeDetection

To enable zoneless change detection in your application, update your application configuration in app.config.ts (for standalone applications) or your root AppModule (for NgModule-based applications).

For Standalone Applications (Recommended in Angular 20):

// src/app/app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideZonelessChangeDetection } from '@angular/core'; // Import this
import { provideHttpClient } from '@angular/common/http'; // Often needed for data fetching

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(), // If you use HttpClient
    provideZonelessChangeDetection(), // THIS BRINGS THE MAGIC
    // ... other providers
  ]
};

For NgModule-based Applications:

// src/app/app.module.ts
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core'; // Import this

import { AppComponent } from './app.component';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  declarations: [
    AppComponent,
    // ... other components, directives, pipes
  ],
  imports: [
    BrowserModule,
    HttpClientModule,
    // ... other modules
  ],
  providers: [
    provideZonelessChangeDetection(), // THIS BRINGS THE MAGIC
    // ... other providers
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

Removing Zone.js from the Build:

For zoneless applications to reap the full performance and bundle size benefits, you should remove Zone.js entirely from your build.

1. Uninstall zone.js:

   npm uninstall zone.js
   

2. Remove from angular.json:
   • Open angular.json.
   • In the build and test targets, locate the polyfills option.
   • Remove 'zone.js' and 'zone.js/testing' from the array.
   • Example (before and after):

     // Before (example)
     "polyfills": [
       "zone.js",
       "zone.js/testing"
     ],
     // After
     "polyfills": []
     

3. Remove from polyfills.ts (if you have one):
   • If your project uses an explicit polyfills.ts file, remove the import 'zone.js'; and import 'zone.js/testing'; lines.

Manual Change Detection in a Zoneless Environment

In a zoneless application, traditional manual change detection methods (like ChangeDetectorRef.detectChanges()) are still available but become less frequently necessary if your application fully embraces signals and other reactive patterns.

Angular relies on these notifications to determine when to run change detection:

• Updating a signal that’s read in a template.
• ChangeDetectorRef.markForCheck() (often implicitly called by AsyncPipe).
• ComponentRef.setInput().
• Bound host or template listener callbacks.
• Attaching a view that was marked dirty.

Example: Force Change Detection (less common with signals)

While rare with a well-designed signal-based zoneless app, you might encounter scenarios where you need to force a check, for instance, when integrating with a legacy library.

// src/app/manual-cd/manual-cd.component.ts
import { Component, ChangeDetectionStrategy, ChangeDetectorRef, signal, inject } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-manual-cd',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card">
      <h2>Manual Change Detection (Zoneless)</h2>
      <p>External Value: {{ externalValue }}</p>
      <p>Signal Value: {{ signalValue() }}</p>
      <button (click)="updateExternalValue()">Update External Value (No Signal)</button>
      <button (click)="triggerSignalUpdate()">Update Signal Value</button>
      <button (click)="forceCheck()">Force Change Detection (for External Value)</button>
    </div>
  `,
  styles: [`
    .card {
      border: 1px solid #ccc;
      padding: 20px;
      margin: 20px;
      border-radius: 8px;
      text-align: center;
    }
    button {
      margin: 5px;
      padding: 10px 15px;
      font-size: 16px;
      cursor: pointer;
    }
  `],
  // With zoneless, OnPush is often the natural state or preferred.
  // It signifies that the component only re-renders when inputs change,
  // or explicit events/signals trigger it.
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ManualCdComponent {
  externalValue: number = 0;
  signalValue = signal(0);
  private cdr = inject(ChangeDetectorRef);

  updateExternalValue() {
    this.externalValue++;
    console.log('External value updated, but UI will not reflect without markForCheck() or explicit signal/event in zoneless.');
    // To make UI reflect this, uncomment the next line:
    // this.cdr.markForCheck(); // Or this.cdr.detectChanges(); if you want immediate check
  }

  triggerSignalUpdate() {
    this.signalValue.update(value => value + 1);
    console.log('Signal value updated, UI will reflect automatically.');
  }

  forceCheck() {
    console.log('Manually marking component for check.');
    this.cdr.markForCheck(); // Marks the component and its ancestors as dirty, triggering a check in the next render cycle.
    // If you need an immediate update, use detectChanges().
    // this.cdr.detectChanges();
  }
}

Exercise:

1. Add ManualCdComponent to your AppComponent.
2. Observe the externalValue. Click “Update External Value (No Signal)”. Notice it doesn’t update in the UI.
3. Click “Force Change Detection”. Now externalValue updates.
4. Click “Update Signal Value”. Notice it updates automatically.
5. This exercise demonstrates that in a zoneless environment, traditional property changes might not trigger UI updates without an explicit notification to Angular, such as through signals, input changes, or markForCheck().

Implications for Libraries: How existing libraries that rely on Zone.js might need to adapt

Most well-maintained Angular libraries have already adapted to work with OnPush change detection and should generally function well in a zoneless environment. However, libraries that heavily rely on NgZone APIs (like onMicrotaskEmpty, onUnstable, onStable) or deeply introspect Zone.js for their functionality might require updates.

• NgZone.onMicrotaskEmpty, NgZone.onUnstable, NgZone.onStable: These observables will never emit in a zoneless application. Libraries using them to wait for Angular to complete change detection should replace them with afterNextRender (for a single check) or afterEveryRender (for continuous checks) where appropriate.
• PendingTasks for SSR: For libraries or applications using Server-Side Rendering (SSR), if they have asynchronous tasks that should prevent server-side serialization until completion, they must use the PendingTasks service to make Angular aware of these tasks.

3. OnPush Change Detection Strategy (and its nuances)

While OnPush has always been a best practice for performance, it becomes even more critical and synergizes perfectly with signals and zoneless Angular. Deeply understanding when OnPush components re-render is vital.

What is OnPush?

ChangeDetectionStrategy.OnPush instructs Angular to run change detection for a component (and its children) only when:

1. Inputs change (by reference): An input property’s reference (not just its internal value) changes. If an input is an object and only its properties change, OnPush won’t detect it.
2. An event originates from the component or its children: A user interaction (e.g., click, keypress) or a HostListener within the component or its template.
3. An Observable bound to the template via the AsyncPipe emits a new value.
4. ChangeDetectorRef.markForCheck() is called: This marks the component (and its ancestors up to the root) as dirty, ensuring it’s checked in the next change detection cycle.
5. ChangeDetectorRef.detectChanges() is called: This performs a direct, immediate change detection for the component and its children.

Immutable Data: The strong relationship between OnPush and immutable data structures

OnPush heavily relies on shallow comparison of input references. If you pass an object or array as an input and then mutate it internally (e.g., myArray.push(item) or myObject.prop = newValue), OnPush will not detect the change because the reference to myArray or myObject remains the same.

To work effectively with OnPush, always prefer immutable data structures or practices that create new references when data changes:

• Arrays: Use slice(), map(), filter(), reduce(), or spread syntax ([...arr, newItem]) to create new array instances when modifying.
• Objects: Use spread syntax ({ ...myObject, newProp: 'value' }) to create new object instances when modifying properties.

Example: OnPush with Mutable vs. Immutable Data

// src/app/onpush-demo/onpush-demo.component.ts
import { Component, ChangeDetectionStrategy, Input, signal, inject, ChangeDetectorRef } from '@angular/core';
import { CommonModule } from '@angular/common';

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

@Component({
  selector: 'app-onpush-demo',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card" [style.background-color]="changeDetected ? 'yellow' : 'white'">
      <h3>{{ title }} (OnPush)</h3>
      <p>Data Updated: {{ changeDetected ? 'YES' : 'NO' }}</p>
      <p>User ID: {{ user.id }}</p>
      <p>User Name: {{ user.name }}</p>
      <button (click)="triggerLocalChange()">Trigger Local Change (Signal)</button>
    </div>
  `,
  styles: [`
    .card {
      border: 1px solid #0056b3;
      padding: 15px;
      margin: 10px;
      border-radius: 5px;
      font-size: 14px;
    }
    button {
      margin-top: 10px;
      padding: 8px 12px;
      font-size: 14px;
      cursor: pointer;
    }
  `],
  changeDetection: ChangeDetectionStrategy.OnPush // Crucial for this demo
})
export class OnPushDemoComponent {
  @Input() title: string = '';
  @Input({ required: true }) user!: User;

  // Internal signal to demonstrate local changes can still trigger CD for OnPush component
  localCounter = signal(0);

  changeDetected: boolean = false;
  private cdr = inject(ChangeDetectorRef);

  ngOnChanges(changes: any): void {
    if (changes['user']) {
      this.changeDetected = true;
      console.log(`${this.title}: Input 'user' changed. Re-rendering.`);
      setTimeout(() => this.changeDetected = false, 500); // Reset visual indicator
    }
  }

  // A local change in an OnPush component triggers its own change detection
  triggerLocalChange() {
    this.localCounter.update(c => c + 1);
    console.log(`${this.title}: Local signal updated. Re-rendering.`);
    this.changeDetected = true;
    setTimeout(() => this.changeDetected = false, 500); // Reset visual indicator
  }

  // To manually force a check, though less common with signals
  forceCheck() {
    this.cdr.markForCheck();
  }
}

// src/app/app.component.ts (or a parent component)
import { Component, signal, CommonModule } from '@angular/core';
import { OnPushDemoComponent } from './onpush-demo/onpush-demo.component';
import { CounterComponent } from './counter/counter.component'; // Import for demonstration

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

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [CommonModule, OnPushDemoComponent, CounterComponent],
  template: `
    <h1>Advanced Angular Guide</h1>
    <app-counter></app-counter>

    <div style="display: flex; justify-content: center; align-items: flex-start; gap: 20px; margin-top: 40px;">
      <div class="parent-controls">
        <h2>Parent Controls</h2>
        <p>Mutable User (passed to OnPushDemo): {{ mutableUser().name }}</p>
        <p>Immutable User (passed to OnPushDemo): {{ immutableUser().name }}</p>
        <button (click)="changeMutableUserName()">Change Mutable User Name (Mutation)</button>
        <button (click)="changeImmutableUserName()">Change Immutable User Name (New Reference)</button>
        <button (click)="changeBothUserReferences()">Change Both User References</button>
      </div>

      <app-onpush-demo [title]="'Mutable Data Demo'" [user]="mutableUser()"></app-onpush-demo>
      <app-onpush-demo [title]="'Immutable Data Demo'" [user]="immutableUser()"></app-onpush-demo>
    </div>
  `,
  styles: [`
    h1 { text-align: center; margin-bottom: 30px; }
    .parent-controls {
      border: 1px solid #4CAF50;
      padding: 20px;
      border-radius: 8px;
      background-color: #e8f5e9;
    }
    .parent-controls button {
      display: block;
      margin: 10px 0;
      width: 100%;
    }
  `]
})
export class AppComponent {
  mutableUser = signal<User>({ id: 1, name: 'Alice' });
  immutableUser = signal<User>({ id: 2, name: 'Bob' });

  changeMutableUserName() {
    // Directly mutate the object stored in the signal (bad practice for OnPush inputs)
    const currentUser = this.mutableUser();
    currentUser.name = 'Alice Changed ' + Date.now().toString().slice(-4);
    // Note: mutableUser.set(currentUser) is still needed to notify the signal
    // if `currentUser` was retrieved from a direct `.get()` and not `.set()` initially
    // However, for an object within a signal, if you mutate it and then `set` the *same* reference,
    // the signal still detects a change *in the signal itself*.
    // The key here is how the parent component passes it *as an input* to an OnPush child.
    // If the signal's value itself is mutated without a .set() or .update() then Angular will not re-render.
    // In a zoneless world, the signal will tell the parent to re-render, and the parent will pass the SAME reference.
    // The OnPush child will *not* re-render because the input reference didn't change.
    this.mutableUser.set(currentUser); // Update the signal with the *same* reference
    console.log('Parent: Mutated mutableUser, then updated signal with same reference.');
  }

  changeImmutableUserName() {
    // Create a new object with updated properties (good practice for OnPush inputs)
    this.immutableUser.update(current => ({
      ...current,
      name: 'Bob Changed ' + Date.now().toString().slice(-4)
    }));
    console.log('Parent: Changed immutableUser by creating new object reference.');
  }

  changeBothUserReferences() {
    this.mutableUser.update(current => ({
      ...current,
      name: 'Alice Ref Updated ' + Date.now().toString().slice(-4)
    }));
    this.immutableUser.update(current => ({
      ...current,
      name: 'Bob Ref Updated ' + Date.now().toString().slice(-4)
    }));
    console.log('Parent: Changed both user references by creating new objects.');
  }
}

Explanation & Exercise:

1. Run the application. You’ll see two OnPushDemoComponent instances.
2. In the “Parent Controls”, click “Change Mutable User Name (Mutation)”.
   • Observe the “Mutable Data Demo” component. Its user.name will update in the UI. This is because, even though we mutated the object, we then called this.mutableUser.set(currentUser) which explicitly tells the signal its value has changed.
   • However, if this mutableUser was a simple class property and not a signal, and you mutated it without explicitly calling ChangeDetectorRef.markForCheck() in a zoneless environment, the OnPush child would not re-render. This highlights why signals are preferred with OnPush and zoneless.
3. Click “Change Immutable User Name (New Reference)”.
   • Observe the “Immutable Data Demo” component. Its user.name updates, and you’ll see “Data Updated: YES” briefly. This is the ideal way to update OnPush component inputs as it guarantees the input reference changes.
4. Click “Trigger Local Change (Signal)” on either OnPushDemoComponent.
   • Notice that the component itself briefly shows “Data Updated: YES”. This demonstrates that a local signal change within an OnPush component does trigger its own change detection.

This example, especially in a zoneless setup, helps differentiate how changes propagate. With OnPush components:

• Changes to @Input properties only trigger change detection if the reference of the input changes.
• Internal component changes driven by signals or template event handlers will trigger its own change detection.

ChangeDetectorRef: Mastering markForCheck(), detectChanges(), and detach()

ChangeDetectorRef provides manual control over the change detection mechanism. Its methods become particularly relevant in OnPush components and zoneless applications, though less so if you fully embrace signals for all UI-bound state.

• markForCheck(): Marks the component (and all its ancestors up to the root) as dirty. This ensures that the component will be checked in the next change detection cycle, even if its inputs haven’t changed reference. It’s often used when an internal, non-input state changes in a way Angular might not automatically detect (e.g., a service modifies an object that the component’s template uses, but isn’t an @Input or signal).
• detectChanges(): Performs an immediate, synchronous change detection check for the current component and all its children. This is a more aggressive approach and should be used cautiously, primarily in specific scenarios like testing or integrating with non-Angular libraries that perform synchronous updates.
• detach(): Detaches the component from the change detection tree. Angular will not check this component (or its children) for changes until it is re-attached with reattach(). This can be used for extreme performance optimizations in components that rarely change or are manually updated.
• reattach(): Re-attaches a previously detached component to the change detection tree.

When to use markForCheck() vs detectChanges():

• markForCheck() (preferred): Use when you want to inform Angular that something has changed and the component needs to be checked in the next natural change detection run. This is less disruptive and allows Angular to optimize its schedule.
• detectChanges() (use sparingly): Use when you need an immediate update to the UI. This can be useful in specific testing scenarios or when working with external libraries that modify the DOM directly and you need Angular to synchronize with those changes instantly.

Example: ChangeDetectorRef in action

// src/app/cdr-demo/cdr-demo.component.ts
import { Component, ChangeDetectionStrategy, ChangeDetectorRef, signal, OnInit, inject } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-cdr-demo',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card" [style.background-color]="background()">
      <h2>ChangeDetectorRef Demo (OnPush)</h2>
      <p>Timestamp: {{ timestamp }}</p>
      <p>Manual Clicks: {{ manualClicks }}</p>
      <p>Signal Clicks: {{ signalClicks() }}</p>

      <button (click)="updateTimestampManually()">Update Timestamp (Manually via cdr)</button>
      <button (click)="updateTimestampAndMark()">Update Timestamp (Mark for Check)</button>
      <button (click)="updateTimestampAndDetect()">Update Timestamp (Detect Changes)</button>
      <button (click)="updateSignalClicks()">Update Signal Clicks (Auto)</button>

      <div style="margin-top: 20px;">
        <button (click)="detachComponent()" [disabled]="!isAttached()">Detach Component</button>
        <button (click)="reattachComponent()" [disabled]="isAttached()">Reattach Component</button>
        <p>Attached: {{ isAttached() ? 'Yes' : 'No' }}</p>
      </div>
    </div>
  `,
  styles: [`
    .card {
      border: 1px solid #1a237e;
      padding: 20px;
      margin: 20px;
      border-radius: 8px;
      text-align: center;
    }
    button {
      margin: 5px;
      padding: 10px 15px;
      font-size: 16px;
      cursor: pointer;
    }
  `],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class CdrDemoComponent implements OnInit {
  timestamp: string = new Date().toLocaleTimeString();
  manualClicks: number = 0;
  signalClicks = signal(0);
  isAttached = signal(true);
  background = signal('white');

  private cdr = inject(ChangeDetectorRef);

  ngOnInit(): void {
    // Demonstrate a periodic change that wouldn't automatically update OnPush
    setInterval(() => {
      // If we don't markForCheck, timestamp wouldn't update after detach()
      if (this.isAttached()) {
         // this.cdr.markForCheck(); // Would be needed here in a non-signal scenario for this change
      }
    }, 1000);
  }

  updateTimestampManually() {
    this.timestamp = new Date().toLocaleTimeString() + ' (Manual ' + ++this.manualClicks + ')';
    console.log('Timestamp updated manually, UI not updated without cdr.markForCheck() or detectChanges()');
    this.background.set('lightcoral');
    setTimeout(() => this.background.set('white'), 500);
  }

  updateTimestampAndMark() {
    this.timestamp = new Date().toLocaleTimeString() + ' (Marked ' + ++this.manualClicks + ')';
    this.cdr.markForCheck(); // Mark as dirty
    console.log('Timestamp updated and component marked for check.');
    this.background.set('lightgreen');
    setTimeout(() => this.background.set('white'), 500);
  }

  updateTimestampAndDetect() {
    this.timestamp = new Date().toLocaleTimeString() + ' (Detected ' + ++this.manualClicks + ')';
    this.cdr.detectChanges(); // Immediately run CD
    console.log('Timestamp updated and detectChanges() called.');
    this.background.set('lightblue');
    setTimeout(() => this.background.set('white'), 500);
  }

  updateSignalClicks() {
    this.signalClicks.update(c => c + 1);
    console.log('Signal clicks updated, UI refreshes automatically.');
    this.background.set('lightgoldenrodyellow');
    setTimeout(() => this.background.set('white'), 500);
  }

  detachComponent() {
    this.cdr.detach();
    this.isAttached.set(false);
    console.log('Component detached from change detection.');
  }

  reattachComponent() {
    this.cdr.reattach();
    this.isAttached.set(true);
    // After reattaching, you might need to markForCheck or detectChanges
    // if there were changes while detached, or rely on next event/signal.
    this.cdr.detectChanges(); // Ensure it picks up current state immediately
    console.log('Component reattached to change detection.');
  }
}

Exercise:

1. Add CdrDemoComponent to your AppComponent.
2. Click “Update Timestamp (Manually via cdr)”. Notice the UI doesn’t update (only the background changes due to signal).
3. Click “Update Timestamp (Mark for Check)”. Notice the UI updates.
4. Click “Update Timestamp (Detect Changes)”. Notice the UI updates immediately.
5. Click “Detach Component”. Now, try all the update buttons.
   • Neither “Update Timestamp (Manually)” nor “Update Timestamp (Mark for Check)” will update the timestamp in the UI because the component is detached.
   • “Update Timestamp (Detect Changes)” will update the timestamp because detectChanges() forces a check regardless of attachment status, but it’s a local check, not part of the global cycle.
   • “Update Signal Clicks” will update the UI because signals have their own independent reactivity that doesn’t fully rely on the component’s attachment status for its own updates within the template.
6. Click “Reattach Component”. Then try the update buttons again.

This exercise illustrates the power and danger of direct ChangeDetectorRef manipulation. With zoneless and signals, explicit markForCheck() becomes less common for component-internal state if you rely on signals.

Performance Implications: How to optimize rendering cycles in large component trees

• Embrace Signals: This is the most significant performance optimization. Signals provide fine-grained reactivity, ensuring only what needs to be updated is updated.
• Adopt OnPush Strategy: Make all components OnPush by default. This forces you to think about input changes (prefer immutable data) and explicit reactivity, which is more performant.
• Lazy Loading: Use lazy loading for modules and, with Angular 20, for specific components and template sections using @defer. This reduces the initial bundle size and JavaScript execution time.
• Zoneless: Enable zoneless change detection to completely remove the Zone.js overhead, reducing bundle size and improving runtime performance.
• TrackBy Function in @for: Always provide a trackBy function for @for loops to help Angular optimize DOM manipulation when items in a list are added, removed, or reordered.
• Avoid Expensive Computations in Templates: Templates are re-evaluated frequently. Move complex calculations to computed() signals or methods that are memoized.
• detach() / reattach() (Advanced): For very specific, performance-critical components that update rarely or are controlled entirely manually, detach() can prevent unnecessary checks. Use with extreme caution.
• Web Workers: Offload heavy computations to web workers to prevent blocking the main UI thread.

II. Dependency Injection (Beyond the Basics)

Dependency Injection (DI) is a core Angular mechanism for providing dependencies to components, services, and other parts of your application. Mastering its advanced aspects is crucial for building scalable, testable, and maintainable applications.

1. DI Hierarchy and Injector Tree

Angular builds an injector tree that mirrors your application’s component hierarchy and module structure. Understanding this tree is fundamental to knowing where and how dependencies are resolved, influencing service lifetime and instance sharing.

• providedIn: 'root': The most common and recommended way to provide services. Services provided in root are singleton instances throughout the application and are tree-shakable (only included in the bundle if actually used).

  // src/app/services/logger.service.ts
  import { Injectable } from '@angular/core';
  
  @Injectable({
    providedIn: 'root'
  })
  export class LoggerService {
    log(message: string): void {
      console.log(`[LoggerService] ${message}`);
    }
  }
  

  Benefit: Single instance, globally accessible, automatically tree-shaken.

• Module Providers (e.g., AppModule, FeatureModule): When you declare a service in the providers array of an NgModule, that service will have a single instance for that module and all its child components and services.

  • If the module is eagerly loaded, the service is a singleton for the entire application.
  • If the module is lazy-loaded, the service is a singleton within the lazy-loaded bundle. This means if two separate lazy-loaded modules provide the same service, they will each get their own instance.

  // src/app/feature/feature.module.ts (example for an NgModule)
  import { NgModule } from '@angular/core';
  import { CommonModule } from '@angular/common';
  import { DataService } from '../services/data.service'; // Assuming a service
  
  @NgModule({
    declarations: [],
    imports: [CommonModule],
    providers: [DataService] // DataService provided here
  })
  export class FeatureModule { }
  

  Use Case: If you have a legacy NgModule or need a specific service instance per lazy-loaded feature module.

• Component Providers: When you declare a service in the providers array of a @Component decorator, that service will have a new instance created for every instance of that component. This is useful for component-specific state or resources that should not be shared globally.

  // src/app/component-specific-service/component-specific.service.ts
  import { Injectable } from '@angular/core';
  
  @Injectable() // No providedIn: 'root'
  export class ComponentSpecificService {
    private id = Math.random().toFixed(4);
    getId(): string { return this.id; }
  }
  
  // src/app/component-specific-service/component-consumer/component-consumer.component.ts
  import { Component } from '@angular/core';
  import { CommonModule } from '@angular/common';
  import { ComponentSpecificService } from '../component-specific.service';
  
  @Component({
    selector: 'app-component-consumer',
    standalone: true,
    imports: [CommonModule],
    providers: [ComponentSpecificService], // Service provided here, new instance per component
    template: `
      <div class="card">
        <h4>Component Consumer Instance {{ id }}</h4>
        <p>Service ID: {{ serviceId }}</p>
      </div>
    `,
    styles: [`
      .card { border: 1px solid #ff9800; padding: 10px; margin: 5px; border-radius: 4px; }
    `]
  })
  export class ComponentConsumerComponent {
    id = Math.random().toFixed(4);
    serviceId: string;
  
    constructor(private componentSpecificService: ComponentSpecificService) {
      this.serviceId = this.componentSpecificService.getId();
    }
  }
  
  // src/app/app.component.ts
  import { Component, CommonModule } from '@angular/core';
  import { ComponentConsumerComponent } from './component-specific-service/component-consumer/component-consumer.component';
  
  @Component({
    selector: 'app-root',
    standalone: true,
    imports: [CommonModule, ComponentConsumerComponent],
    template: `
      <h1>Advanced Angular Guide</h1>
      <app-component-consumer></app-component-consumer>
      <app-component-consumer></app-component-consumer>
      <app-component-consumer></app-component-consumer>
    `
  })
  export class AppComponent {}
  

  Exercise: Observe the console or render the ComponentConsumerComponent multiple times. Notice that each ComponentConsumerComponent instance gets a unique Service ID.

@Self(), @Host(), @SkipSelf(), @Optional(): Mastering these decorators

These DI decorators allow fine-grained control over how Angular resolves dependencies in the injector tree.

• @Self(): Instructs Angular to look for the dependency only on the current element’s injector. If not found, it throws an error.

  • Use Case: Ensuring a component uses its own private service instance, or that a directive only applies to an element with a specific provider.

• @Host(): Instructs Angular to look for the dependency up the injector tree, but only until it reaches the host component (the component that contains the element or template where the injection is happening). It won’t look beyond the host component.

  • Use Case: Directives or child components needing to access a service provided by their direct host component, but not necessarily higher up in the application.

• @SkipSelf(): Instructs Angular to start looking for the dependency from the parent injector upwards, skipping the current element’s injector.

  • Use Case: A component needing to inject a different instance of a service than the one it itself provides, or when a service needs to access an older instance of itself.

• @Optional(): Allows Angular to return null if the dependency cannot be resolved. Without this, Angular would throw an error if the dependency isn’t found.

  • Use Case: When a dependency is truly optional, and your code can gracefully handle its absence.

Example: DI Decorators

// src/app/di-decorators/parent/parent.component.ts
import { Component, Optional, Self, Host, SkipSelf, inject, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { DiService } from '../di.service';
import { ChildComponent } from '../child/child.component';

@Component({
  selector: 'app-parent',
  standalone: true,
  imports: [CommonModule, ChildComponent],
  providers: [
    { provide: DiService, useValue: { id: 'PARENT_SERVICE', value: 'Provided by Parent' } }
  ],
  template: `
    <div class="card parent-card">
      <h2>Parent Component (Provides DiService: {{ (parentDiService?.id) || 'N/A' }})</h2>
      <app-child></app-child>
      <h3>Parent trying to inject DiService:</h3>
      <ul>
        <li>Default: {{ defaultDiService?.id }}</li>
        <li>@Self: {{ selfDiService?.id }}</li>
        <li>@SkipSelf: {{ skipSelfDiService?.id }}</li>
        <li>@Optional: {{ optionalDiService?.id }}</li>
        <li>@Optional @SkipSelf: {{ optionalSkipSelfDiService?.id }}</li>
      </ul>
    </div>
  `,
  styles: [`
    .parent-card { border: 2px solid #3f51b5; padding: 20px; margin: 20px; background-color: #e8eaf6; }
    h2, h3 { color: #3f51b5; }
    ul { list-style: none; padding: 0; }
    li { margin-bottom: 5px; }
  `]
})
export class ParentComponent implements OnInit {
  parentDiService = inject(DiService); // This parent's own instance

  defaultDiService: DiService | undefined;
  selfDiService: DiService | undefined;
  skipSelfDiService: DiService | undefined;
  optionalDiService: DiService | undefined;
  optionalSkipSelfDiService: DiService | undefined;

  // We can't use `inject` with decorators directly as it's a function.
  // We'll simulate by calling inject in ngOnInit, which is okay for this example.
  ngOnInit(): void {
    try { this.defaultDiService = inject(DiService); } catch (e) { this.defaultDiService = { id: 'ERROR', value: 'Default Not Found' }; }
    try { this.selfDiService = inject(DiService, { self: true }); } catch (e) { this.selfDiService = { id: 'ERROR', value: 'Self Not Found' }; }
    try { this.skipSelfDiService = inject(DiService, { skipSelf: true }); } catch (e) { this.skipSelfDiService = { id: 'ERROR', value: 'SkipSelf Not Found' }; }
    try { this.optionalDiService = inject(DiService, { optional: true }); } catch (e) { this.optionalDiService = { id: 'ERROR', value: 'Optional Not Found' }; }
    try { this.optionalSkipSelfDiService = inject(DiService, { optional: true, skipSelf: true }); } catch (e) { this.optionalSkipSelfDiService = { id: 'ERROR', value: 'Optional SkipSelf Not Found' }; }
  }
}

// src/app/di-decorators/child/child.component.ts
import { Component, Optional, Self, Host, SkipSelf, inject, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { DiService } from '../di.service';

@Component({
  selector: 'app-child',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card child-card">
      <h3>Child Component (Provides DiService: {{ (childDiService?.id) || 'N/A' }})</h3>
      <h4>Child trying to inject DiService:</h4>
      <ul>
        <li>Default: {{ defaultDiService?.id }}</li>
        <li>@Self: {{ selfDiService?.id }}</li>
        <li>@Host: {{ hostDiService?.id }}</li>
        <li>@SkipSelf: {{ skipSelfDiService?.id }}</li>
        <li>@Optional: {{ optionalDiService?.id }}</li>
        <li>@Optional @Host: {{ optionalHostDiService?.id }}</li>
      </ul>
    </div>
  `,
  styles: [`
    .child-card { border: 2px solid #00acc1; padding: 15px; margin: 10px; background-color: #e0f7fa; }
    h3, h4 { color: #00acc1; }
    ul { list-style: none; padding: 0; }
    li { margin-bottom: 5px; }
  `],
  providers: [
    { provide: DiService, useValue: { id: 'CHILD_SERVICE', value: 'Provided by Child' } }
  ]
})
export class ChildComponent implements OnInit {
  childDiService = inject(DiService); // This child's own instance

  defaultDiService: DiService | undefined;
  selfDiService: DiService | undefined;
  hostDiService: DiService | undefined;
  skipSelfDiService: DiService | undefined;
  optionalDiService: DiService | undefined;
  optionalHostDiService: DiService | undefined;

  ngOnInit(): void {
    // Using inject with DI flags (object notation is preferred)
    try { this.defaultDiService = inject(DiService); } catch (e) { this.defaultDiService = { id: 'ERROR', value: 'Default Not Found' }; }
    try { this.selfDiService = inject(DiService, { self: true }); } catch (e) { this.selfDiService = { id: 'ERROR', value: 'Self Not Found' }; }
    try { this.hostDiService = inject(DiService, { host: true }); } catch (e) { this.hostDiService = { id: 'ERROR', value: 'Host Not Found' }; }
    try { this.skipSelfDiService = inject(DiService, { skipSelf: true }); } catch (e) { this.skipSelfDiService = { id: 'ERROR', value: 'SkipSelf Not Found' }; }
    try { this.optionalDiService = inject(DiService, { optional: true }); } catch (e) { this.optionalDiService = { id: 'ERROR', value: 'Optional Not Found' }; }
    try { this.optionalHostDiService = inject(DiService, { optional: true, host: true }); } catch (e) { this.optionalHostDiService = { id: 'ERROR', value: 'Optional Host Not Found' }; }
  }
}

// src/app/di-decorators/di.service.ts
export interface DiService {
  id: string;
  value: string;
}

Exercise:

1. Add ParentComponent to your AppComponent.
2. Observe the output in the browser and console.
   • Parent Component:
     • Parent trying to inject DiService: Default: Should be PARENT_SERVICE (itself).
     • @Self: PARENT_SERVICE (itself).
     • @SkipSelf: This will depend on whether DiService is provided at a higher level (e.g., App component or app.config.ts). If not, it will be ERROR or null if @Optional() was used.
   • Child Component:
     • Child trying to inject DiService: Default: CHILD_SERVICE (itself).
     • @Self: CHILD_SERVICE (itself).
     • @Host: PARENT_SERVICE (from its parent component).
     • @SkipSelf: This will skip the child and try to find it in the parent (ParentComponent) -> PARENT_SERVICE.
     • @Optional: CHILD_SERVICE.
     • @Optional @Host: PARENT_SERVICE.

This example highlights how these decorators manipulate the injector lookup process.

InjectionToken: For providing non-class dependencies

InjectionToken is used to provide dependencies that don’t have a runtime type (like interface, string, or configuration objects). It allows you to define a “token” that uniquely identifies a dependency.

// src/app/config.token.ts
import { InjectionToken } from '@angular/core';

export interface AppConfig {
  apiUrl: string;
  featureFlags: { [key: string]: boolean };
}

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

// src/app/config-consumer/config-consumer.component.ts
import { Component, inject } from '@angular/core';
import { CommonModule } from '@angular/common';
import { APP_CONFIG, AppConfig } from '../config.token';

@Component({
  selector: 'app-config-consumer',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card">
      <h3>App Configuration</h3>
      <p>API URL: {{ config.apiUrl }}</p>
      <p>Feature 'beta' enabled: {{ config.featureFlags['beta'] }}</p>
    </div>
  `,
  styles: [`
    .card { border: 1px solid #7cb342; padding: 15px; margin: 20px; border-radius: 4px; }
  `]
})
export class ConfigConsumerComponent {
  // Inject the configuration using the InjectionToken
  config: AppConfig = inject(APP_CONFIG);
}

// src/app/app.config.ts (where you provide the token)
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideZonelessChangeDetection } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

import { routes } from './app.routes';
import { APP_CONFIG } from './config.token'; // Import the token

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideZonelessChangeDetection(),
    // Provide the actual configuration object for the InjectionToken
    {
      provide: APP_CONFIG,
      useValue: {
        apiUrl: 'https://api.example.com/v1',
        featureFlags: {
          beta: true,
          darkMode: false
        }
      }
    }
  ]
};

Exercise:

1. Add ConfigConsumerComponent to your AppComponent.
2. Observe the configuration values rendered in the component.
3. Modify apiUrl or featureFlags in app.config.ts and see how it reflects in the component.

2. inject() function (and its advantages)

The inject() function, introduced in Angular 14 and promoted in Angular 20, is the modern and preferred way to perform dependency injection in Angular. It offers several advantages over traditional constructor injection.

Comparing inject() with constructor injection: Pros and cons

Constructor Injection (Traditional):

class MyService { /* ... */ }

@Component({ /* ... */ })
export class MyComponent {
  constructor(private myService: MyService) { }
}

• Pros: Familiar to those with OOP backgrounds, clear declaration of dependencies.
• Cons:
  • Boilerplate: Requires private/public modifiers and type annotations.
  • Limitations: Cannot inject into class fields or non-constructor functions (e.g., lifecycle hooks, computed properties, private methods). This limits composability.
  • Order of Operations: Constructor injection happens before class fields are initialized, which can sometimes lead to issues if a field needs an injected dependency.

inject() Function (Modern):

import { inject } from '@angular/core';
import { MyService } from './my.service'; // Assume MyService is provided somewhere

@Component({ /* ... */ })
export class MyComponent {
  // Inject directly into a class field
  private myService = inject(MyService);

  // Inject into a computed signal
  // (Assuming you have other signals like `count`)
  // readonly someComputedValue = computed(() => {
  //   const value = this.myService.getValue(this.count());
  //   return value * 2;
  // });

  // Can inject inside functions (if they run within an injection context)
  ngOnInit() {
    // const element = inject(ElementRef); // Would throw if not in proper context
  }

  // Use inject in helper functions or factories
  // (Covered more in "Multi-Providers")
}

• Pros:

  • Readability & Conciseness: Reduces boilerplate, especially with class fields.
  • Flexibility: Can be used in class fields, computed() signals, effect()s, route resolvers, guards, interceptors, and factories. This enables more functional and composable patterns.
  • Type Inference: TypeScript automatically infers the type, leading to less verbose code.
  • Composability: Enables the creation of reusable functions and patterns that depend on injection, without needing a full class.
  • Order of Operations: Class field initializers run after the constructor, allowing inject() to be used in class fields and still access dependencies.

• Cons:

  • Context Dependency: inject() must be called within an injection context (e.g., during class construction, provider definition, or within runInInjectionContext). This is a common pitfall for beginners.
  • Migrating existing code: Large codebases might require effort to transition from constructor injection.

Using inject() outside of constructors: How it enables more functional programming patterns in Angular

inject()’s power truly shines when used outside of constructors, especially in combination with standalone components, functional guards, and resolvers.

Example: inject() in Functional Resolver

// src/app/services/user.service.ts
import { Injectable } from '@angular/core';
import { Observable, of, delay } from 'rxjs';

export interface UserDetail {
  id: number;
  name: string;
  description: string;
}

@Injectable({ providedIn: 'root' })
export class UserDetailService {
  getUser(id: number): Observable<UserDetail> {
    console.log(`Fetching user ${id}...`);
    // Simulate API call
    return of({ id, name: `User ${id}`, description: `Details for User ${id}` }).pipe(delay(1000));
  }
}

// src/app/resolvers/user.resolver.ts
import { ResolveFn } from '@angular/router';
import { inject } from '@angular/core';
import { UserDetailService, UserDetail } from '../services/user.service';

// Functional resolver using `inject()`
export const userDetailResolver: ResolveFn<UserDetail> = (route, state) => {
  const userDetailService = inject(UserDetailService);
  const userId = Number(route.paramMap.get('id'));
  return userDetailService.getUser(userId);
};

// src/app/user-detail/user-detail.component.ts
import { Component, Input, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { UserDetail } from '../services/user.service';

@Component({
  selector: 'app-user-detail',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card">
      <h2>User Detail (from Resolver)</h2>
      @if (user) {
        <p>ID: {{ user.id }}</p>
        <p>Name: {{ user.name }}</p>
        <p>Description: {{ user.description }}</p>
      } @else {
        <p>User not found.</p>
      }
    </div>
  `,
  styles: [`
    .card { border: 1px solid #9c27b0; padding: 20px; margin: 20px; border-radius: 8px; }
  `]
})
export class UserDetailComponent implements OnInit {
  // Data comes from the route resolver, mapped to an input by the router
  @Input() user?: UserDetail;

  ngOnInit(): void {
    console.log('UserDetailComponent initialized with:', this.user);
  }
}

// src/app/app.routes.ts
import { Routes } from '@angular/router';
import { UserDetailComponent } from './user-detail/user-detail.component';
import { userDetailResolver } from './resolvers/user.resolver'; // Import resolver
import { AppComponent } from './app.component'; // Ensure AppComponent is imported for use

export const routes: Routes = [
  { path: '', component: AppComponent }, // Example root or landing page
  {
    path: 'user/:id',
    component: UserDetailComponent,
    resolve: {
      user: userDetailResolver // Use the functional resolver
    }
  }
];

Exercise:

1. Add RouterOutlet to AppComponent template to display routed components.

   <!-- src/app/app.component.ts -->
   <router-outlet></router-outlet>
   

2. Navigate to /user/1, then /user/2. Observe in the network tab how the getUser service call happens before the component is rendered, and inject() works seamlessly in the resolver.

Migration strategies: How to transition existing code to inject()

• Start with New Code: For any new services, components, guards, or resolvers, prioritize inject().

• Refactor Incrementally: Target areas that benefit most from inject(), such as:

  • Class fields: Convert simple constructor injections to class field injections.
  • Functional patterns: Convert class-based guards/resolvers/interceptors to their functional equivalents.
  • Factory functions: Use inject() inside useFactory providers.

• Use runInInjectionContext (Advanced): If you need to call inject() from outside an injection context (e.g., from a plain JavaScript function or a utility), you can use runInInjectionContext. This requires a reference to an injector.

  // src/app/utils/injection-utils.ts
  import { inject, EnvironmentInjector } from '@angular/core';
  import { LoggerService } from '../services/logger.service';
  
  export function logMessageGlobally(message: string, injector: EnvironmentInjector) {
    // Cannot use inject() directly here without a context
    injector.runInInjectionContext(() => {
      const logger = inject(LoggerService);
      logger.log(`Global Utility: ${message}`);
    });
  }
  
  // Example usage in a component (passing its injector)
  // import { Component, inject, EnvironmentInjector } from '@angular/core';
  // import { logMessageGlobally } from './utils/injection-utils';
  //
  // @Component({ /* ... */ })
  // export class MyComponent {
  //   private injector = inject(EnvironmentInjector);
  //
  //   someMethod() {
  //     logMessageGlobally('Hello from MyComponent!', this.injector);
  //   }
  // }
  

3. Multi-Providers (multi: true)

Multi-providers allow you to register multiple values for a single InjectionToken. When you inject that token, you receive an array of all the provided values. This is a powerful feature for extensibility and modularity.

Use Cases: Interceptors, validators, custom error handlers, extensibility points

• HTTP Interceptors: The most common use case. Angular’s HTTP_INTERCEPTORS token is a multi-provider, allowing you to chain multiple interceptors for request/response modification.
• Custom Validators: Providing multiple validators for form controls.
• Error Handlers: Registering multiple error handling strategies or loggers.
• Plugin Architectures: Allowing different modules or libraries to “plug in” their implementations for a specific feature.

How providers are combined when multi: true is used

When multi: true is used with a provide token, Angular collects all registered providers for that token into an array. The order in which they appear in the providers array (or in the import chain of modules/standalone components) can matter for some use cases (like HTTP interceptors).

Example: Multi-Providers for Feature Plugins

Let’s imagine a “dashboard” where different widgets can be registered as plugins.

// src/app/multi-providers/widget.token.ts
import { InjectionToken, Type } from '@angular/core';

export interface DashboardWidget {
  title: string;
  component: Type<any>; // The component class to render
}

export const DASHBOARD_WIDGETS = new InjectionToken<DashboardWidget[]>('DashboardWidgets');

// src/app/multi-providers/widgets/greeting-widget/greeting-widget.component.ts
import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-greeting-widget',
  standalone: true,
  imports: [CommonModule],
  template: `<div class="widget-card"><h3>Hello Widget!</h3><p>Welcome to your dashboard.</p></div>`,
  styles: [`
    .widget-card { border: 1px solid #fbc02d; padding: 10px; margin: 5px; background-color: #fffde7; }
  `]
})
export class GreetingWidgetComponent {}

// src/app/multi-providers/widgets/time-widget/time-widget.component.ts
import { Component, signal, OnInit, OnDestroy } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-time-widget',
  standalone: true,
  imports: [CommonModule],
  template: `<div class="widget-card"><h3>Current Time</h3><p>{{ currentTime() | date:'mediumTime' }}</p></div>`,
  styles: [`
    .widget-card { border: 1px solid #29b6f6; padding: 10px; margin: 5px; background-color: #e1f5fe; }
  `]
})
export class TimeWidgetComponent implements OnInit, OnDestroy {
  currentTime = signal(new Date());
  private intervalId: any;

  ngOnInit(): void {
    this.intervalId = setInterval(() => {
      this.currentTime.set(new Date());
    }, 1000);
  }

  ngOnDestroy(): void {
    if (this.intervalId) {
      clearInterval(this.intervalId);
    }
  }
}

// src/app/multi-providers/dashboard/dashboard.component.ts
import { Component, inject, Type, ViewContainerRef, ViewChild, AfterViewInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { DASHBOARD_WIDGETS, DashboardWidget } from '../widget.token';

@Component({
  selector: 'app-dashboard',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="card dashboard-container">
      <h2>My Dynamic Dashboard</h2>
      <div #widgetHost class="widget-area">
        <!-- Widgets will be rendered here -->
      </div>
    </div>
  `,
  styles: [`
    .dashboard-container { border: 2px solid #5e35b1; padding: 20px; margin: 20px; background-color: #ede7f6; }
    .widget-area { display: flex; flex-wrap: wrap; gap: 10px; margin-top: 15px; }
  `]
})
export class DashboardComponent implements AfterViewInit {
  // Inject all registered widgets as an array
  widgets: DashboardWidget[] = inject(DASHBOARD_WIDGETS, { optional: true }) || [];

  @ViewChild('widgetHost', { read: ViewContainerRef, static: true })
  widgetHost!: ViewContainerRef;

  ngAfterViewInit(): void {
    this.renderWidgets();
  }

  renderWidgets(): void {
    this.widgetHost.clear();
    this.widgets.forEach(widget => {
      this.widgetHost.createComponent(widget.component);
    });
  }
}

// src/app/app.config.ts (where you provide the multi-providers)
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideZonelessChangeDetection } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { APP_CONFIG } from './config.token';
import { DASHBOARD_WIDGETS } from './multi-providers/widget.token'; // Import token
import { GreetingWidgetComponent } from './multi-providers/widgets/greeting-widget/greeting-widget.component'; // Import widget
import { TimeWidgetComponent } from './multi-providers/widgets/time-widget/time-widget.component'; // Import widget

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideZonelessChangeDetection(),
    {
      provide: APP_CONFIG,
      useValue: {
        apiUrl: 'https://api.example.com/v1',
        featureFlags: { beta: true, darkMode: false }
      }
    },
    // Registering multiple widgets as multi-providers
    {
      provide: DASHBOARD_WIDGETS,
      useValue: { title: 'Greeting', component: GreetingWidgetComponent },
      multi: true // THIS IS THE KEY!
    },
    {
      provide: DASHBOARD_WIDGETS,
      useValue: { title: 'Time', component: TimeWidgetComponent },
      multi: true // THIS IS THE KEY!
    },
    // You can add more widgets here as needed
  ]
};

Exercise:

1. Add DashboardComponent to your AppComponent.
2. Observe how both GreetingWidgetComponent and TimeWidgetComponent are rendered dynamically in the dashboard.
3. Add another dummy widget component, register it as a multi-provider, and see it appear in the dashboard.

Multi-providers are extremely powerful for creating extensible architectures where different parts of your application (or different libraries) can contribute to a common set of functionalities.

III. Templates & Components (Advanced Features)

Angular templates have seen significant enhancements, especially with Angular 20. Mastering these new features is crucial for writing more performant, readable, and developer-friendly UI code.

1. Control Flow Syntax (@if, @for, @switch)

The new built-in control flow syntax, stable since Angular 18, is a game-changer. It replaces structural directives like *ngIf, *ngFor, and *ngSwitch with a cleaner, more performant block-based syntax. These traditional structural directives are now deprecated as of Angular 20 and will likely be removed in Angular 22.

Performance Benefits: How it avoids Zone.js interaction and improves hydration

The new control flow is compiled directly into highly optimized JavaScript instructions by the Angular compiler, unlike the old structural directives which relied on ng-template and ViewContainerRef manipulation at runtime. This direct compilation brings several benefits:

• No Zone.js Interaction: The new control flow operates outside of Zone.js’s change detection mechanism, especially beneficial in zoneless applications, contributing to faster runtime performance.
• Reduced Bundle Size: Eliminates the need for runtime structural directive code.
• Improved Hydration: Plays a crucial role in server-side rendering (SSR) and hydration, as the server can render the exact HTML structure, and the client-side Angular can efficiently “hydrate” (make interactive) only the necessary parts.
• Enhanced Readability: The block-based syntax is more intuitive and closer to standard JavaScript control flow.

Syntax and usage: Mastering the new @if, @for (with track and empty blocks), and @switch

@if, @else if, @else (Replaces *ngIf)

<!-- src/app/control-flow-demo/control-flow-demo.component.ts (template snippet) -->
<div class="card">
  <h3>@if / @else if / @else</h3>
  <button (click)="toggleLoggedIn()">Toggle Login</button>
  <button (click)="changeUserRole()">Change Role</button>
  <p>Logged In: {{ isLoggedIn() }} | Role: {{ userRole() }}</p>

  @if (isLoggedIn()) {
    <p class="success">Welcome, {{ userRole() }}!</p>
  } @else if (userRole() === 'GUEST') {
    <p class="info">Please log in to access full features.</p>
  } @else {
    <p class="error">Access Denied. You are not logged in.</p>
  }

  <!-- Referencing Expression Results -->
  @if (userRole(); as role) {
    <p>Your current role is: <strong>{{ role }}</strong></p>
  } @else {
    <p>No role assigned.</p>
  }
</div>

• @if (condition): Renders content if the condition is true.
• @else if (condition): Renders content if the preceding @if and @else if conditions are false and this condition is true.
• @else: Renders content if all preceding conditions are false.
• @if (expression; as localVariable): Allows you to capture the result of an expression into a local variable within the block, useful for observables with async pipe.

@for (Replaces *ngFor)

<!-- src/app/control-flow-demo/control-flow-demo.component.ts (template snippet) -->
<div class="card">
  <h3>@for Loop</h3>
  <button (click)="addTodo()">Add Todo</button>
  <button (click)="removeTodo()">Remove Last Todo</button>
  <button (click)="clearTodos()">Clear All</button>

  @for (todo of todos(); track todo.id; let i = $index, first = $first, last = $last, even = $even, odd = $odd) {
    <div class="todo-item" [class.first-item]="first" [class.last-item]="last" [class.even-item]="even" [class.odd-item]="odd">
      {{ i + 1 }}. {{ todo.text }}
      <span *ngIf="first">(First)</span>
      <span *ngIf="last">(Last)</span>
    </div>
  } @empty {
    <p class="info">No todos yet! Add some.</p>
  }
</div>

• @for (item of collection; track item.property): Loops over a collection.
• track item.property: Mandatory. Provides a unique identifier for each item. This is crucial for performance, as Angular uses it to identify items when the collection changes, preventing unnecessary re-rendering of entire lists. If no unique property exists, track $index can be used as a fallback, but trackBy unique identifier is preferred for maintaining DOM elements and state.
• Local Variables: let i = $index, let first = $first, let last = $last, let even = $even, let odd = $odd are available.
• @empty block: Renders content when the collection is empty, replacing the need for an *ngIf to check for an empty array.

@switch (Replaces *ngSwitch)

<!-- src/app/control-flow-demo/control-flow-demo.component.ts (template snippet) -->
<div class="card">
  <h3>@switch Case</h3>
  <button (click)="nextStatus()">Next Status</button>
  <p>Current Status: {{ currentStatus() }}</p>

  @switch (currentStatus()) {
    @case ('ACTIVE') {
      <p class="success">Status: Active and ready.</p>
    }
    @case ('PENDING') {
      <p class="info">Status: Pending approval.</p>
    }
    @case ('ERROR') {
      <p class="error">Status: An error occurred.</p>
    }
    @default {
      <p>Status: Unknown.</p>
    }
  }
</div>

• @switch (expression): Evaluates an expression.
• @case ('value'): Renders content if the expression matches ‘value’.
• @default: Renders content if no @case matches.

Example: Comprehensive Control Flow Demo Component

// src/app/control-flow-demo/control-flow-demo.component.ts
import { Component, signal } from '@angular/core';
import { CommonModule } from '@angular/common';

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

type UserRole = 'ADMIN' | 'EDITOR' | 'GUEST';
type Status = 'ACTIVE' | 'PENDING' | 'ERROR' | 'UNKNOWN';

@Component({
  selector: 'app-control-flow-demo',
  standalone: true,
  imports: [CommonModule],
  template: `
    <h2>New Control Flow Syntax (Angular 20)</h2>

    <div class="container">
      <!-- @if / @else if / @else -->
      <div class="card">
        <h3>@if / @else if / @else</h3>
        <button (click)="toggleLoggedIn()">Toggle Login</button>
        <button (click)="changeUserRole()">Change Role</button>
        <p>Logged In: {{ isLoggedIn() }} | Role: {{ userRole() }}</p>

        @if (isLoggedIn()) {
          <p class="success">Welcome, {{ userRole() }}!</p>
        } @else if (userRole() === 'GUEST') {
          <p class="info">Please log in to access full features.</p>
        } @else {
          <p class="error">Access Denied. You are not logged in.</p>
        }

        @if (userRole(); as role) {
          <p>Your current role is: <strong>{{ role }}</strong> (captured in 'as' variable)</p>
        } @else {
          <p>No role assigned.</p>
        }
      </div>

      <!-- @for Loop -->
      <div class="card">
        <h3>@for Loop</h3>
        <button (click)="addTodo()">Add Todo</button>
        <button (click)="removeTodo()">Remove Last Todo</button>
        <button (click)="clearTodos()">Clear All</button>

        @for (todo of todos(); track todo.id; let i = $index, first = $first, last = $last, even = $even, odd = $odd) {
          <div class="todo-item"
               [class.first-item]="first"
               [class.last-item]="last"
               [class.even-item]="even"
               [class.odd-item]="odd"
               [style.background-color]="odd ? '#f0f0f0' : '#ffffff'">
            {{ i + 1 }}. {{ todo.text }}
            @if (first) { (First) }
            @if (last) { (Last) }
          </div>
        } @empty {
          <p class="info">No todos yet! Add some.</p>
        }
      </div>

      <!-- @switch Case -->
      <div class="card">
        <h3>@switch Case</h3>
        <button (click)="nextStatus()">Next Status</button>
        <p>Current Status: <strong>{{ currentStatus() }}</strong></p>

        @switch (currentStatus()) {
          @case ('ACTIVE') {
            <p class="success">Status: Active and ready.</p>
          }
          @case ('PENDING') {
            <p class="info">Status: Pending approval.</p>
          }
          @case ('ERROR') {
            <p class="error">Status: An error occurred.</p>
          }
          @default {
            <p>Status: Unknown.</p>
          }
        }
      </div>
    </div>
  `,
  styles: [`
    h2 { text-align: center; margin-bottom: 30px; }
    .container {
      display: grid;
      grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
      gap: 20px;
      margin: 0 20px;
    }
    .card {
      border: 1px solid #ccc;
      padding: 20px;
      border-radius: 8px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
    }
    .card h3 {
      text-align: center;
      margin-top: 0;
      color: #333;
    }
    button {
      margin: 5px;
      padding: 8px 12px;
      font-size: 14px;
      cursor: pointer;
    }
    p { margin: 5px 0; }
    .success { color: green; font-weight: bold; }
    .info { color: blue; }
    .error { color: red; font-weight: bold; }
    .todo-item {
      padding: 8px;
      border-bottom: 1px dotted #eee;
    }
    .todo-item.first-item { font-weight: bold; }
    .todo-item.last-item { border-bottom: none; font-style: italic; }
  `]
})
export class ControlFlowDemoComponent {
  // @if / @else if / @else
  isLoggedIn = signal(false);
  userRole = signal<UserRole>('GUEST');
  private roles: UserRole[] = ['GUEST', 'ADMIN', 'EDITOR'];
  private currentRoleIndex = 0;

  toggleLoggedIn() {
    this.isLoggedIn.update(value => !value);
  }

  changeUserRole() {
    this.currentRoleIndex = (this.currentRoleIndex + 1) % this.roles.length;
    this.userRole.set(this.roles[this.currentRoleIndex]);
  }

  // @for Loop
  todos = signal<Todo[]>([
    { id: 1, text: 'Learn Signals' },
    { id: 2, text: 'Explore Zoneless CD' },
    { id: 3, text: 'Master New Control Flow' },
  ]);
  private nextTodoId = 4;

  addTodo() {
    this.todos.update(currentTodos => [...currentTodos, { id: this.nextTodoId++, text: `New Todo ${this.nextTodoId}` }]);
  }

  removeTodo() {
    this.todos.update(currentTodos => currentTodos.slice(0, currentTodos.length - 1));
  }

  clearTodos() {
    this.todos.set([]);
    this.nextTodoId = 1; // Reset ID for demo
  }

  // @switch Case
  currentStatus = signal<Status>('UNKNOWN');
  private statuses: Status[] = ['ACTIVE', 'PENDING', 'ERROR', 'UNKNOWN'];
  private currentStatusIndex = 0;

  nextStatus() {
    this.currentStatusIndex = (this.currentStatusIndex + 1) % this.statuses.length;
    this.currentStatus.set(this.statuses[this.currentStatusIndex]);
  }
}