DEV Community: Atilla Baspinar

Deployment

Atilla Baspinar — Mon, 29 Jun 2026 20:59:50 +0000

1. Manual Deployment

npm run build
# or equivalently:
ng build

The production build outputs to dist/<project-name>/browser/. This folder contains only static files — upload it to any static host (Netlify, Vercel, S3, GitHub Pages, Nginx, etc.) following that host's instructions.

Server configuration for SPA routing

Angular is a Single Page Application — only index.html exists on disk. If a user refreshes /tasks/42 or pastes a deep link, the server must return index.html for any path that doesn't match a static file, otherwise it returns a 404.

Nginx:

server {
  listen 80;
  root /usr/share/nginx/html;
  index index.html;

  location / {
    try_files $uri $uri/ /index.html;
  }
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
RewriteRule ^ /index.html

2. Deployment with CLI

The Angular CLI has first-class integrations with common hosting providers. Add the provider's package once, then deploy with a single command:

ng add @angular/fire        # Firebase Hosting
ng add @netlify-builder/deploy  # Netlify
ng add angular-cli-ghpages  # GitHub Pages

ng deploy

The builder handles the production build and upload automatically.

3. Server-Side Rendering (SSR)

Setup

Add SSR to an existing project:

ng add @angular/ssr

Or start a new project with it included:

ng new my-app --ssr

ng add @angular/ssr creates these additional files:

File	Purpose
`server.ts`	Node.js / Express server entry point
`main.server.ts`	Server-side bootstrap
`app.config.server.ts`	Server-specific providers (e.g. `provideServerRendering`)
`app.routes.server.ts`	Per-route rendering mode configuration (Angular 19+)

After building, the dist/ folder has two subfolders:

dist/my-app/
  browser/   ← static assets and client JS
  server/    ← Node.js server bundle

Run the server:

node dist/my-app/server/server.mjs

Rendering modes (Angular 19+)

Since Angular 19, you configure how each route is rendered in app.routes.server.ts. There are three modes:

RenderMode.Prerender — SSG (Static Site Generation)
Angular runs at build time and generates a ready-made HTML file for the route, stored in dist/browser/. The server just sends that file — no Angular processing at runtime. Fastest possible response, works on any static host, great SEO. Only suitable for content that is the same for all users.

RenderMode.Server — SSR (Server-Side Rendering)
Angular runs on the Node.js server for every incoming request and generates HTML on the fly. Supports user-specific or real-time content. Requires a running Node.js server. Slower than SSG but more flexible.

RenderMode.Client — CSR (Client-Side Rendering)
The server sends a bare index.html. Angular bootstraps entirely in the browser. No SEO benefit. Use for auth-gated pages or routes that depend on browser APIs.

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  { path: '',       renderMode: RenderMode.Prerender },  // / → pre-built index.html
  { path: 'about',  renderMode: RenderMode.Prerender },  // /about → pre-built about/index.html
  { path: 'profile', renderMode: RenderMode.Server },    // /profile → rendered per request
  { path: 'tasks',  renderMode: RenderMode.Client },     // /tasks → rendered in browser
];

Default behavior: Routes without dynamic segments (:param) default to Prerender. Routes with dynamic segments default to Server, because Angular cannot know all possible param values at build time.

Prerendering dynamic routes is possible if you provide the param values explicitly:

{
  path: 'tasks/:id',
  renderMode: RenderMode.Prerender,
  getPrerenderParams: async () => [{ id: '1' }, { id: '2' }, { id: '3' }],
}

This generates dist/browser/tasks/1/index.html, dist/browser/tasks/2/index.html, etc. at build time.

Before Angular 19

Older versions had no per-route control. The whole app was either SSR or fully static, configured globally via outputMode in angular.json.

4. Pitfalls

Browser-only code (localStorage, DOM)

Code that accesses browser APIs (localStorage, window, DOM manipulation) will crash on the server during SSR because those APIs don't exist in Node.js.

Use afterNextRender() to run code exclusively in the browser — it is skipped entirely on the server:

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

@Component({ ... })
export class ThemeComponent {
  constructor() {
    afterNextRender(() => {
      const saved = localStorage.getItem('theme');
      // safe — this only runs in the browser
    });
  }
}

Resolvers in SSR

Resolvers run on the server during the first render — the data is fetched server-side and serialized into the HTML. This means:

The resolver must not use browser-only APIs
HTTP calls in resolvers during SSR are made from the Node.js server, not the browser
On subsequent client-side navigations (after hydration), the resolver runs normally in the browser

If your resolver uses localStorage or window, guard it with isPlatformBrowser():

import { inject, PLATFORM_ID } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import { ResolveFn } from '@angular/router';

export const myResolver: ResolveFn<string> = () => {
  if (isPlatformBrowser(inject(PLATFORM_ID))) {
    return localStorage.getItem('key') ?? '';
  }
  return '';
};

Routing

Atilla Baspinar — Mon, 29 Jun 2026 20:59:24 +0000

Angular's router has three core pieces: routes (which component shows at which URL), outlets (where the component renders in the template), and links (how users navigate without a full page reload).

1. Setup

`app.routes.ts`

Define your routes in a dedicated file. Angular uses first-match wins, so order matters — put more specific routes before general ones. Unlike React Router (v6+), which automatically ranks routes by specificity regardless of order, Angular matches top-to-bottom and stops at the first hit:

import { Routes } from '@angular/router';
import { HomeComponent } from './home/home.component';
import { TasksComponent } from './tasks/tasks.component';
import { NotFoundComponent } from './not-found/not-found.component';

export const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'tasks', component: TasksComponent },
  { path: '**', component: NotFoundComponent },  // wildcard — must be last
];

`app.config.ts`

Pass the routes to provideRouter in your app config:

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';

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

`main.ts`

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';
import { appConfig } from './app/app.config';

bootstrapApplication(AppComponent, appConfig);

2. `<router-outlet>`

Place <router-outlet /> in your root component's template where matched components should render:

import { RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [RouterOutlet],
  template: `
    <nav>...</nav>
    <router-outlet />
  `,
})
export class AppComponent {}

3. `routerLink` — Navigation Links

Use routerLink instead of href to navigate without a full page reload:

import { RouterLink } from '@angular/router';

@Component({
  imports: [RouterLink],
  template: `
    <a routerLink="/tasks">Tasks</a>
  `,
})
export class NavComponent {}

routerLink also accepts an array, which is useful for building dynamic links:

<!-- static -->
<a [routerLink]="['/tasks']">Tasks</a>

<!-- with a dynamic param -->
<a [routerLink]="['/tasks', task.id]">{{ task.title }}</a>

Paths starting with / are absolute — they always navigate from the app root. Paths without a leading slash are relative — they resolve from the current route:

<!-- absolute: always goes to /tasks -->
<a routerLink="/tasks">Tasks</a>

<!-- relative: from /users/123 → /users/123/tasks -->
<a routerLink="tasks">Tasks</a>

<!-- go up one level: from /users/123 → /users -->
<a routerLink="..">Back</a>

For programmatic relative navigation, pass relativeTo to Router.navigate():

// from /users/123 → /users/123/edit
this.router.navigate(['edit'], { relativeTo: this.route });

// go up one level
this.router.navigate(['..'], { relativeTo: this.route });

Active link styling with `RouterLinkActive`

RouterLinkActive adds a CSS class to the element when its route is active:

import { RouterLink, RouterLinkActive } from '@angular/router';

@Component({
  imports: [RouterLink, RouterLinkActive],
  template: `
    <a routerLink="/tasks" routerLinkActive="active-link">Tasks</a>
  `,
})
export class NavComponent {}

For the root path, use [routerLinkActiveOptions]="{ exact: true }" to prevent it from matching every route:

<a routerLink="/" routerLinkActive="active-link" [routerLinkActiveOptions]="{ exact: true }">Home</a>

4. Route Parameters

Define a dynamic segment with :paramName:

{ path: 'tasks/:id', component: TaskDetailComponent }

Option A — `ActivatedRoute`

Inject ActivatedRoute and subscribe to its params or paramMap observable.

params gives a plain object — simple, but less safe:

this.route.params.subscribe(params => {
  this.taskId.set(params['id']);
});

paramMap is preferred — it provides helper methods (get(), has(), getAll()) and handles multi-value params:

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

@Component({ ... })
export class TaskDetailComponent {
  taskId = signal('');
  private route = inject(ActivatedRoute);

  constructor() {
    this.route.paramMap
      .pipe(takeUntilDestroyed())
      .subscribe(params => {
        this.taskId.set(params.get('id') ?? '');
      });
  }
}

Use takeUntilDestroyed() to automatically unsubscribe when the component is destroyed. Call it inside the constructor (or any injection context) — it needs access to DestroyRef internally.

Option B — `input()` binding (Angular 16+)

Since Angular 16 you can bind route params directly to component inputs. Enable it once in app.config.ts:

import { withComponentInputBinding } from '@angular/router';

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

Then declare an input whose name matches the route param — no ActivatedRoute needed:

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

@Component({ ... })
export class TaskDetailComponent {
  id = input<string>();  // automatically set to the :id param
}

This also works with @Input() for class-based style. Prefer input() signals for new code.

Redirect routes

Redirect one path to another using redirectTo. Use pathMatch: 'full' on the empty path so it doesn't match every route:

{ path: '', redirectTo: '/tasks', pathMatch: 'full' },

5. Programmatic Navigation

Inject the Router service to navigate from code (e.g. after a form submit):

import { Router } from '@angular/router';

@Component({ ... })
export class NewTaskComponent {
  private router = inject(Router);

  onSubmit() {
    // ... save task
    this.router.navigate(['/tasks']);
    // or with a param:
    this.router.navigate(['/tasks', taskId]);
  }
}

navigateByUrl is an alternative when you have a full URL string:

this.router.navigateByUrl('/tasks');

6. Page Titles

Set the browser tab title per route with the title property:

{ path: 'tasks', component: TasksComponent, title: 'My Tasks' },

The title can also be a resolver function for dynamic titles:

{
  path: 'tasks/:id',
  component: TaskDetailComponent,
  title: (route: ActivatedRouteSnapshot) => `Task ${route.paramMap.get('id')}`,
}

7. Nested Routes

Use children to nest routes under a parent. The parent component must contain its own <router-outlet /> where child components render.

export const routes: Routes = [
  {
    path: 'users/:userId',
    component: UserShellComponent,  // renders the layout, contains <router-outlet />
    children: [
      { path: '', component: UserDetailComponent },    // /users/42
      { path: 'edit', component: UserEditComponent },  // /users/42/edit
    ],
  },
];

UserShellComponent holds the shared layout (e.g. a header with the user's name) and a <router-outlet /> for the active child:

@Component({
  imports: [RouterOutlet],
  template: `
    <h2>User Profile</h2>
    <router-outlet />
  `,
})
export class UserShellComponent {}

Child components can read the :userId param from ActivatedRoute directly — the router provides the parent route's params to all child routes:

@Component({ ... })
export class UserDetailComponent {
  private route = inject(ActivatedRoute);

  constructor() {
    this.route.paramMap
      .pipe(takeUntilDestroyed())
      .subscribe(params => {
        const userId = params.get('userId');
        // load user...
      });
  }
}

8. `snapshot` vs Observable

ActivatedRoute exposes two ways to read route state:

snapshot — a one-time read of the current route. Fast and simple, but not reactive.
paramMap observable — emits every time the route changes. Required when the component stays mounted while params change.

The trap with snapshot: if you navigate from /users/1 to /users/2 and the UserDetailComponent is reused (not destroyed), the snapshot stays frozen at the first value and your UI won't update.

// ❌ snapshot — only reads once, misses future param changes
const userId = this.route.snapshot.paramMap.get('userId');

// ✓ observable — reacts to every navigation
this.route.paramMap
  .pipe(takeUntilDestroyed())
  .subscribe(params => {
    const userId = params.get('userId');
    // load user...
  });

Use snapshot only when you know the component is always destroyed and recreated on navigation (i.e. it's not a reused route). In all other cases, subscribe to the observable.

9. Query Params

Query params are the ?key=value part of the URL (e.g. /tasks?order=asc). Unlike route params, they are optional and don't affect which route is matched.

Setting query params

Via routerLink using [queryParams]:

<a routerLink="." [queryParams]="{ order: 'asc' }">Sort ascending</a>

Or programmatically:

this.router.navigate(['/tasks'], { queryParams: { order: 'asc' } });

Use queryParamsHandling: 'merge' to update one param while keeping the rest:

this.router.navigate([], {
  queryParams: { order: 'desc' },
  queryParamsHandling: 'merge',
  relativeTo: this.route,
});

Reading query params

Option A — `input()` signal (Angular 16+)

With withComponentInputBinding() enabled, query params are automatically bound to inputs whose name matches the param key:

@Component({ ... })
export class TaskListComponent {
  order = input<'asc' | 'desc'>('asc');  // bound to ?order=...
}

<!-- read and pass the current value back when linking -->
<a routerLink="." [queryParams]="{ order: order() }">Re-sort</a>

Option B — observable

@Component({ ... })
export class TaskListComponent {
  private route = inject(ActivatedRoute);
  order: 'asc' | 'desc' = 'asc';

  constructor() {
    this.route.queryParams
      .pipe(takeUntilDestroyed())
      .subscribe(params => {
        this.order = params['order'] ?? 'asc';
      });
  }
}

10. Route Data Resolvers

A resolver fetches data before a route activates, so the component receives it immediately on load instead of having to handle a loading state itself. Define one with ResolveFn:

// user-tasks.resolver.ts
import { inject } from '@angular/core';
import { ResolveFn, ActivatedRouteSnapshot } from '@angular/router';
import { TaskService } from './task.service';
import { Task } from './task.model';

export const userTasksResolver: ResolveFn<Task[]> = (route: ActivatedRouteSnapshot) => {
  const userId = route.paramMap.get('userId')!;
  return inject(TaskService).getTasksByUser(userId);
};

// user-friends.resolver.ts
import { inject } from '@angular/core';
import { ResolveFn, ActivatedRouteSnapshot } from '@angular/router';
import { UserService } from './user.service';
import { User } from './user.model';

export const userFriendsResolver: ResolveFn<User[]> = (route: ActivatedRouteSnapshot) => {
  const userId = route.paramMap.get('userId')!;
  return inject(UserService).getFriends(userId);
};

Attach both to the route under the resolve key:

{
  path: 'users/:userId',
  component: UserDetailComponent,
  resolve: {
    tasks: userTasksResolver,
    friends: userFriendsResolver,
  },
}

By default, resolvers only re-run when path params change. Use runGuardsAndResolvers to control when they execute:

{
  path: 'users/:userId',
  component: UserDetailComponent,
  resolve: { tasks: userTasksResolver },
  runGuardsAndResolvers: 'paramsOrQueryParamsChange',  // also re-run on ?sort=... changes
}

Value	Re-runs when
`paramsChange` (default)	Path or path params change
`pathParamsChange`	Only path params change (ignores query params)
`paramsOrQueryParamsChange`	Path params or query params change
`always`	Every navigation, regardless of what changed

Read the resolved data in the component via ActivatedRoute.data:

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

@Component({ ... })
export class UserDetailComponent {
  private data = toSignal(inject(ActivatedRoute).data);

  tasks   = computed(() => this.data()?.['tasks']);
  friends = computed(() => this.data()?.['friends']);
}

Or with withComponentInputBinding() (Angular 16+), resolved data is bound directly to inputs — no ActivatedRoute needed:

@Component({ ... })
export class UserDetailComponent {
  tasks   = input<Task[]>();
  friends = input<User[]>();
}

The resolver can return a value, a Promise, or an Observable. Angular waits for it to complete before rendering the component.

Comparison to React Router loaders

React Router v6.4+ has a very similar concept called loaders. The main differences:

	Angular resolver	React loader
Definition	Separate `ResolveFn` function	Inline `loader` function on the route object
Reading data	`ActivatedRoute.data` or `input()`	`useLoaderData()` hook
Multiple resolvers	Multiple keys under `resolve: {}`	Single loader, return an object with multiple keys
Cancellation	Unsubscribes Observable on navigation cancel	Uses `request.signal` (AbortSignal)

Both block navigation until data is ready, and both support returning Promises or observables/async values.

11. Route Guards

Guards are functions that run before (or after) a navigation and decide whether it should proceed. Since Angular 14, the preferred style is functional guards — plain functions using inject(), no class needed. Class-based guards still work but are deprecated.

Guard	Applied on route as	Runs when
`canActivate`	`canActivate: [guard]`	Entering a route
`canActivateChild`	`canActivateChild: [guard]`	Entering any child route
`canDeactivate`	`canDeactivate: [guard]`	Leaving a route
`canMatch`	`canMatch: [guard]`	Deciding whether a route can be matched at all

A guard returns true to allow navigation, false to block it, or a RedirectCommand / UrlTree to redirect instead.

`canActivate` — protect a route

// auth.guard.ts
import { inject } from '@angular/core';
import { CanActivateFn, Router, RedirectCommand } from '@angular/router';
import { AuthService } from './auth.service';

export const authGuard: CanActivateFn = () => {
  const auth = inject(AuthService);
  const router = inject(Router);

  if (auth.isLoggedIn()) {
    return true;
  }

  return new RedirectCommand(router.parseUrl('/login'));
};

Attach it to a route:

{
  path: 'dashboard',
  component: DashboardComponent,
  canActivate: [authGuard],
}

Return new RedirectCommand(urlTree) instead of false — it redirects the user cleanly without requiring a separate router.navigate() call.

`canDeactivate` — guard against leaving

Useful for unsaved form changes. The guard receives the current component instance, so it can check its state:

import { CanDeactivateFn } from '@angular/router';
import { TaskEditComponent } from './task-edit.component';

export const unsavedChangesGuard: CanDeactivateFn<TaskEditComponent> = (component) => {
  if (component.hasUnsavedChanges()) {
    return confirm('You have unsaved changes. Leave anyway?');
  }
  return true;
};

{
  path: 'tasks/:id/edit',
  component: TaskEditComponent,
  canDeactivate: [unsavedChangesGuard],
}

`canMatch` — conditional route matching

Unlike canActivate (which blocks navigation), canMatch makes the route invisible to the router — if it returns false, Angular falls through to the next matching route. Useful for feature flags or role-based route variants:

import { CanMatchFn } from '@angular/router';
import { inject } from '@angular/core';
import { AuthService } from './auth.service';

export const adminOnlyGuard: CanMatchFn = () => {
  return inject(AuthService).isAdmin();
};

{ path: 'settings', component: AdminSettingsComponent, canMatch: [adminOnlyGuard] },
{ path: 'settings', component: UserSettingsComponent },  // fallback for non-admins

Reactive Forms

Atilla Baspinar — Mon, 29 Jun 2026 20:58:55 +0000

Reactive forms define the form structure and validation entirely in the component class using FormGroup and FormControl. The template only binds to these objects — no ngModel, no template variables for validation state.

Import ReactiveFormsModule in the component's imports array.

1. Setting up a reactive form

Define the form as a class field using FormGroup and FormControl:

import { Component } from '@angular/core';
import { FormGroup, FormControl, ReactiveFormsModule } from '@angular/forms';

@Component({
  imports: [ReactiveFormsModule],
  ...
})
export class SignUpComponent {
  form = new FormGroup({
    email:    new FormControl(''),  // initial value
    password: new FormControl(''),
  });
}

Use [formGroup] on the <form> element and formControlName on each input:

<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <input formControlName="email" type="email" />
  <input formControlName="password" type="password" />
  <button type="submit">Submit</button>
</form>

To bind a single control outside of a [formGroup], use [formControl] directly:

<input [formControl]="form.controls.email" />

No form argument is needed in the submit handler — this.form is always available in the class:

onSubmit() {
  console.log(this.form.value);                // { email: '...', password: '...' }
  console.log(this.form.controls.email.value); // '...'
}

2. Built-in validators

Pass validators in the FormControl options object using the Validators class from @angular/forms:

import { FormGroup, FormControl, Validators } from '@angular/forms';

form = new FormGroup({
  email: new FormControl('', {
    validators: [Validators.required, Validators.email],
  }),
  password: new FormControl('', {
    validators: [Validators.required, Validators.minLength(8)],
  }),
});

Common built-in validators: required, email, minLength(n), maxLength(n), min(n), max(n), pattern(regex).

Displaying errors in the template

Use a getter to keep the template readable:

get emailInvalid() {
  const ctrl = this.form.controls.email;
  return ctrl.touched && ctrl.invalid;
}

<input formControlName="email" />
@if (emailInvalid) {
  <p class="error">Enter a valid email address.</p>
}

@if (form.controls.password.errors?.['minlength']) {
  <p class="error">Password must be at least 8 characters.</p>
}

<button type="submit" [disabled]="form.invalid">Submit</button>

3. Custom validators

A custom validator is a plain function that receives an AbstractControl and returns null if valid, or a ValidationErrors object if invalid. The object key becomes the error name.

import { AbstractControl, ValidationErrors } from '@angular/forms';

function mustContainQuestionMark(control: AbstractControl): ValidationErrors | null {
  if (control.value?.includes('?')) {
    return null; // valid
  }
  return { missingQuestionMark: true }; // invalid
}

Use it alongside built-in validators:

form = new FormGroup({
  password: new FormControl('', {
    validators: [Validators.required, mustContainQuestionMark],
  }),
});

@if (form.controls.password.errors?.['missingQuestionMark']) {
  <p class="error">Password must contain a question mark.</p>
}

4. Async validators

Async validators return an Observable<ValidationErrors | null> instead of a synchronous value. Angular sets the control's status to 'PENDING' while waiting and updates validity once the Observable emits.

A typical use case is checking whether an email is already registered:

import { Component, inject } from '@angular/core';
import { AbstractControl, ValidationErrors, FormGroup, FormControl, Validators } from '@angular/forms';
import { Observable, of, timer } from 'rxjs';
import { switchMap, map, catchError } from 'rxjs';
import { AuthService } from './auth.service';

@Component({ ... })
export class SignUpComponent {
  private authService = inject(AuthService);

  form = new FormGroup({
    email: new FormControl('', {
      validators: [Validators.required, Validators.email],
      asyncValidators: [(control: AbstractControl): Observable<ValidationErrors | null> =>
        timer(400).pipe(
          switchMap(() => this.authService.isEmailTaken(control.value)),
          map(taken => taken ? { emailTaken: true } : null),
          catchError(() => of(null))
        )
      ],
    }),
  });
}

<input formControlName="email" />

@if (form.controls.email.status === 'PENDING') {
  <span>Checking availability…</span>
}
@if (form.controls.email.errors?.['emailTaken']) {
  <p class="error">This email is already registered.</p>
}

How the debouncing works: timer(400) delays the API call by 400 ms. If the user types again before 400 ms elapse, Angular triggers a new validation cycle — unsubscribing from the previous Observable (which cancels the timer) and starting a fresh one. This naturally debounces the API call without any extra operator.

catchError(() => of(null)) ensures a network error does not permanently block submission — the field is treated as valid and the user can continue.

5. Reacting to value changes

form.valueChanges is an Observable that emits the full form value whenever any control changes. Subscribe to it in ngOnInit — the FormGroup is defined as a class field so it is ready before ngOnInit runs.

Use takeUntilDestroyed to clean up the subscription automatically when the component is destroyed:

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

@Component({ ... })
export class SignUpComponent implements OnInit {
  private destroyRef = inject(DestroyRef);

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

  ngOnInit() {
    // whole form
    this.form.valueChanges.pipe(
      debounceTime(300),
      distinctUntilChanged(),
      takeUntilDestroyed(this.destroyRef)
    ).subscribe(value => {
      console.log(value); // { email: '...', password: '...' }
    });

    // single control
    this.form.controls.email.valueChanges.pipe(
      debounceTime(300),
      takeUntilDestroyed(this.destroyRef)
    ).subscribe(email => {
      console.log('email changed:', email);
    });
  }
}

distinctUntilChanged() prevents re-processing when the emitted value is the same as the previous one — useful when you are triggering a search or API call.

6. Setting values programmatically

Use these methods to pre-fill a form (e.g. loading a user profile for editing) or to reset it after submission.

// setValue — must provide a value for every control; throws if any are missing
this.form.setValue({ email: 'user@example.com', password: 'secret' });

// patchValue — updates only the controls you specify; ignores the rest
this.form.patchValue({ email: 'user@example.com' }); // password is unchanged

// set a single control
this.form.controls.email.setValue('user@example.com');

// reset — clears values and resets state to pristine and untouched
this.form.reset();

// reset with specific initial values
this.form.reset({ email: 'user@example.com', password: '' });

Method	Requires all controls	Resets state
`setValue(obj)`	Yes — throws if any key is missing	No
`patchValue(obj)`	No — partial update is fine	No
`reset(obj?)`	No	Yes — pristine, untouched

Prefer patchValue when pre-filling from an API response that may not include every field. Use reset() after a successful form submission to clear the form and its validation state.

7. Nested FormGroup

Nest a FormGroup inside another FormGroup to organise related fields. In the template, use formGroupName to scope the inner group.

form = new FormGroup({
  name: new FormControl('', Validators.required),
  address: new FormGroup({
    street:   new FormControl(''),
    postcode: new FormControl(''),
  }),
});

<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <input formControlName="name" placeholder="Full name" />

  <fieldset formGroupName="address">
    <input formControlName="street" placeholder="Street" />
    <input formControlName="postcode" placeholder="Postcode" />
  </fieldset>

  <button type="submit">Submit</button>
</form>

form.value mirrors the nesting: { name: '...', address: { street: '...', postcode: '...' } }. Access a nested control with form.controls.address.controls.street.

8. FormArray

FormArray holds a dynamic list of controls whose length is not known at design time — for example, a list of email addresses the user can add or remove.

import { Component } from '@angular/core';
import { FormArray, FormControl, FormGroup, ReactiveFormsModule, Validators } from '@angular/forms';

@Component({
  imports: [ReactiveFormsModule],
  ...
})
export class ContactComponent {
  form = new FormGroup({
    emails: new FormArray([new FormControl('', Validators.email)]),
  });

  get emails() {
    return this.form.controls.emails;
  }

  addEmail() {
    this.emails.push(new FormControl('', Validators.email));
  }

  removeEmail(index: number) {
    this.emails.removeAt(index);
  }
}

Use formArrayName in the template and bind each control by its index with [formControlName]="$index":

<form [formGroup]="form">
  <div formArrayName="emails">
    @for (ctrl of emails.controls; track $index) {
      <div>
        <input [formControlName]="$index" type="email" placeholder="Email" />
        <button type="button" (click)="removeEmail($index)">Remove</button>
      </div>
    }
  </div>
  <button type="button" (click)="addEmail()">Add email</button>
</form>

Key FormArray methods: push(control), removeAt(index), at(index), length.

9. FormGroup validators

A validator registered on the FormGroup receives the entire group as its AbstractControl, allowing comparison across fields. Register it in the second argument to FormGroup:

function passwordsMatch(group: AbstractControl): ValidationErrors | null {
  const password = group.get('password')?.value;
  const confirm  = group.get('confirmPassword')?.value;
  return password === confirm ? null : { passwordMismatch: true };
}

form = new FormGroup({
  password:        new FormControl('', [Validators.required, Validators.minLength(8)]),
  confirmPassword: new FormControl('', Validators.required),
}, {
  validators: [passwordsMatch],
});

The error lands on form.errors, not on any individual control:

<input formControlName="confirmPassword" type="password" placeholder="Confirm password" />
@if (form.errors?.['passwordMismatch'] && form.controls.confirmPassword.touched) {
  <p class="error">Passwords do not match.</p>
}

Angular also adds aggregate state classes to the <form> element — ng-valid, ng-dirty, ng-touched, ng-pending, and ng-submitted — each reflecting the combined state across all controls.

Angular HTTP Client

Atilla Baspinar — Mon, 29 Jun 2026 20:58:05 +0000

Angular's HttpClient sends HTTP requests and returns RxJS Observables. Each request Observable emits exactly one value (the response) and then completes — or emits an error if the request fails.

1. Setup

Provide HttpClient globally in the app config. This is the recommended approach for standalone apps (Angular 15+).

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
  ],
};

HttpClientModule (the NgModule alternative) is deprecated since Angular 18. Use provideHttpClient() in new apps.

2. GET — Fetching data

Inject HttpClient with inject() and call .get<T>() with the expected response type as a generic. Call .subscribe() to start the request — the Observable is cold and does nothing until subscribed.

import { Component, inject, signal, OnInit } from '@angular/core';
import { HttpClient } from '@angular/common/http';

interface Task {
  id: number;
  title: string;
}

@Component({ ... })
export class TasksComponent implements OnInit {
  private http = inject(HttpClient);

  tasks = signal<Task[]>([]);

  ngOnInit() {
    this.http.get<Task[]>('/api/tasks').subscribe({
      next: (data) => this.tasks.set(data),
    });
  }
}

Loading and error state

complete is called after a successful response, but is not called when the request errors — so resetting isLoading in complete leaves it stuck on true after failures. Use finalize() instead: it runs after both completion and error.

import { finalize } from 'rxjs';

@Component({ ... })
export class TasksComponent implements OnInit {
  private http = inject(HttpClient);

  tasks     = signal<Task[]>([]);
  isLoading = signal(false);
  error     = signal('');

  ngOnInit() {
    this.isLoading.set(true);

    this.http.get<Task[]>('/api/tasks').pipe(
      finalize(() => this.isLoading.set(false))
    ).subscribe({
      next:  (data) => this.tasks.set(data),
      error: (err)  => this.error.set(err.message),
    });
  }
}

@if (isLoading()) {
  <p>Loading…</p>
} @else if (error()) {
  <p class="error">{{ error() }}</p>
} @else {
  @for (task of tasks(); track task.id) {
    <li>{{ task.title }}</li>
  }
}

3. Transforming the response with `pipe()`

Use map() to reshape the response before it reaches subscribe(). This is useful when the API wraps its data in a wrapper object.

import { map, finalize } from 'rxjs';

this.http.get<{ tasks: Task[]; total: number }>('/api/tasks').pipe(
  map(response => response.tasks),
  finalize(() => this.isLoading.set(false))
).subscribe({
  next:  (tasks) => this.tasks.set(tasks),
  error: (err)   => this.error.set(err.message),
});

4. Custom error handling with `catchError()`

catchError() intercepts an error in the pipeline before it reaches subscribe. Use it to add context to the message or return a safe fallback value.

Re-throw with a custom message:

import { map, catchError, finalize } from 'rxjs';
import { throwError } from 'rxjs';

this.http.get<{ tasks: Task[] }>('/api/tasks').pipe(
  map(response => response.tasks),
  catchError(err =>
    throwError(() => new Error('Could not load tasks: ' + err.message))
  ),
  finalize(() => this.isLoading.set(false))
).subscribe({
  next:  (tasks) => this.tasks.set(tasks),
  error: (err)   => this.error.set(err.message), // receives the remapped error
});

throwError(() => new Error(...)) — the factory function form is required in RxJS 7+. The old throwError('string') form is deprecated.

Return a fallback instead of re-throwing — lets the stream complete normally with a safe default:

import { catchError, of } from 'rxjs';

this.http.get<Task[]>('/api/tasks').pipe(
  catchError(() => of([]))  // on error, emit empty array and complete
).subscribe({
  next: (tasks) => this.tasks.set(tasks),
});

5. Sending data — POST, PUT, PATCH, DELETE

Pass the request body as the second argument. Angular serializes it to JSON and sets Content-Type: application/json automatically.

POST — create a resource

addTask(title: string) {
  this.http.post<Task>('/api/tasks', { title }).subscribe({
    next:  (created) => this.tasks.update(list => [...list, created]),
    error: (err)     => this.error.set(err.message),
  });
}

PUT — replace a resource

updateTask(task: Task) {
  this.http.put<Task>(`/api/tasks/${task.id}`, task).subscribe({
    next:  (updated) => this.tasks.update(list =>
      list.map(t => t.id === updated.id ? updated : t)
    ),
    error: (err) => this.error.set(err.message),
  });
}

DELETE — remove a resource

deleteTask(id: number) {
  this.http.delete(`/api/tasks/${id}`).subscribe({
    next:  () => this.tasks.update(list => list.filter(t => t.id !== id)),
    error: (err) => this.error.set(err.message),
  });
}

put() replaces the entire resource. Use patch() with the same signature to send only the changed fields.

6. HTTP in a service

Moving HTTP calls into a service separates data-fetching from the component and makes it reusable. The service returns the Observable; the component subscribes and handles the response.

// tasks.service.ts
import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

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

  getTasks(): Observable<Task[]> {
    return this.http.get<Task[]>('/api/tasks');
  }

  addTask(title: string): Observable<Task> {
    return this.http.post<Task>('/api/tasks', { title });
  }
}

In the component, subscribe and use takeUntilDestroyed to cancel the in-flight request if the component is destroyed before the response arrives:

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

@Component({ ... })
export class TasksComponent implements OnInit {
  private tasksService = inject(TasksService);
  private destroyRef   = inject(DestroyRef);

  tasks = signal<Task[]>([]);

  ngOnInit() {
    this.tasksService.getTasks()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe({
        next:  (data) => this.tasks.set(data),
        error: (err)  => console.error(err),
      });
  }
}

HTTP observables complete after one emission, so takeUntilDestroyed mainly guards against the component being destroyed mid-request — preventing signal updates on a destroyed view.

7. Shared state with signals in a service

When multiple components need the same data, hold the state in a signal inside the service. The service performs the HTTP call and updates the signal via tap(). Components read the signal directly — no need to pass data through @Input()/@Output().

// tasks.service.ts
import { Injectable, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { tap, finalize, catchError } from 'rxjs';
import { throwError } from 'rxjs';

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

  // shared reactive state
  tasks     = signal<Task[]>([]);
  isLoading = signal(false);
  error     = signal('');

  loadTasks() {
    this.isLoading.set(true);
    this.error.set('');

    return this.http.get<Task[]>('/api/tasks').pipe(
      tap(tasks => this.tasks.set(tasks)),
      catchError(err => {
        this.error.set(err.message);
        return throwError(() => err);
      }),
      finalize(() => this.isLoading.set(false))
    );
  }
}

The component triggers the load and reads signals directly from the service. No next handler is needed — tap() already updated the signal.

// tasks-list.component.ts
@Component({ ... })
export class TasksListComponent implements OnInit {
  private tasksService = inject(TasksService);

  tasks     = this.tasksService.tasks;
  isLoading = this.tasksService.isLoading;
  error     = this.tasksService.error;

  ngOnInit() {
    this.tasksService.loadTasks().subscribe({
      error: () => {}, // error is already set on the service signal
    });
  }
}

Any other component can read the same signal without triggering another request:

// tasks-summary.component.ts
@Component({ ... })
export class TasksSummaryComponent {
  private tasksService = inject(TasksService);

  taskCount = computed(() => this.tasksService.tasks().length);
}

Because tasks is a signal on the singleton service, all components that read it update automatically when loadTasks() completes.

8. App-wide error handling with a shared error service

A common pattern in Angular apps is a singleton ErrorService that holds the current error as a signal. Any HTTP service that encounters an error calls errorService.show(). A single modal component in AppComponent reads that signal and displays the message — one place handles all errors, regardless of which service triggered them.

Why this is a best practice: it decouples error display from the services that produce errors, avoids duplicating modal/toast logic in every component, and works naturally with signals since the modal reacts to changes automatically.

// error.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class ErrorService {
  private _message = signal<string | null>(null);
  readonly message = this._message.asReadonly(); // expose read-only to outside

  show(message: string) {
    this._message.set(message);
  }

  clear() {
    this._message.set(null);
  }
}

asReadonly() prevents other classes from calling .set() directly — only the service's own methods can change the value.

The modal component reads the signal and shows itself when it has a value:

// error-modal.component.ts
import { Component, inject } from '@angular/core';
import { ErrorService } from './error.service';

@Component({
  selector: 'app-error-modal',
  standalone: true,
  template: `
    @if (errorService.message(); as message) {
      <div class="modal-overlay">
        <div class="modal">
          <p>{{ message }}</p>
          <button (click)="errorService.clear()">Dismiss</button>
        </div>
      </div>
    }
  `,
})
export class ErrorModalComponent {
  errorService = inject(ErrorService);
}

Place it once in AppComponent so it is always present regardless of which route is active:

// app.component.ts
@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet, ErrorModalComponent],
  template: `
    <router-outlet />
    <app-error-modal />
  `,
})
export class AppComponent {}

HTTP services inject ErrorService and call show() in catchError. Return EMPTY instead of re-throwing — the error has been handled centrally so subscribers don't need an error handler:

// tasks.service.ts
import { Injectable, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { tap, catchError, finalize } from 'rxjs';
import { EMPTY } from 'rxjs';
import { ErrorService } from './error.service';

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

  tasks     = signal<Task[]>([]);
  isLoading = signal(false);

  loadTasks() {
    this.isLoading.set(true);
    return this.http.get<Task[]>('/api/tasks').pipe(
      tap(tasks => this.tasks.set(tasks)),
      catchError(err => {
        this.errorService.show('Failed to load tasks: ' + err.message);
        return EMPTY; // swallow — error is handled by the error service
      }),
      finalize(() => this.isLoading.set(false))
    );
  }
}

The component subscribes with no error handler — the service and modal take care of it:

ngOnInit() {
  this.tasksService.loadTasks().subscribe();
}

9. HTTP Interceptors

An interceptor sits between your code and the HTTP transport layer. Every request and response passes through it, making it the right place for cross-cutting concerns — auth headers, logging, global error handling — that would otherwise be duplicated across every service.

Functional interceptors (Angular 15+)

The modern form is a plain function typed as HttpInterceptorFn. It receives the outgoing request and a next function, and returns an Observable of the response.

// auth.interceptor.ts
import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { AuthService } from './auth.service';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthService).token();
  if (!token) return next(req);

  const authReq = req.clone({
    setHeaders: { Authorization: `Bearer ${token}` }
  });
  return next(authReq);
};

req.clone() is required because HttpRequest objects are immutable — you cannot modify a request in place.

Register interceptors in app.config.ts with withInterceptors(). They run in the order listed — first registered runs first on the way out and last on the way back in.

// app.config.ts
import { provideHttpClient, withInterceptors } from '@angular/common/http';
import { authInterceptor } from './auth.interceptor';
import { errorInterceptor } from './error.interceptor';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withInterceptors([authInterceptor, errorInterceptor]))
  ]
};

Intercepting the response

The response is available on the Observable returned by next(req). Pipe onto it to transform data or handle errors on the way back.

// error.interceptor.ts
import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { catchError, throwError } from 'rxjs';
import { ErrorService } from './error.service';

export const errorInterceptor: HttpInterceptorFn = (req, next) => {
  const errorService = inject(ErrorService);
  return next(req).pipe(
    catchError(err => {
      errorService.show(err.message);
      return throwError(() => err);
    })
  );
};

With this interceptor registered, no individual service needs to handle HTTP errors — they are caught centrally and displayed by the error modal from section 8.

Class-based interceptors (pre-Angular 15)

Before Angular 15, interceptors were classes implementing HttpInterceptor:

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler } from '@angular/common/http';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
  intercept(req: HttpRequest<unknown>, next: HttpHandler) {
    const authReq = req.clone({
      setHeaders: { Authorization: `Bearer ${this.getToken()}` }
    });
    return next.handle(authReq); // next.handle() instead of next()
  }
}

Registered in the module providers array:

{ provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true }

For standalone apps that still use class interceptors, pass withInterceptorsFromDi() to provideHttpClient():

provideHttpClient(withInterceptorsFromDi())

Prefer functional interceptors in modern code — they are easier to test (plain functions), tree-shakable, and use inject() without a constructor.

Common use cases

Use case	Intercepts	Technique
Add auth token	Request	`req.clone({ setHeaders: { Authorization: ... } })`
Prefix a base URL	Request	`req.clone({ url: baseUrl + req.url })`
Global error handling	Response	`pipe(catchError(...))`
Retry on server error	Response	`pipe(retry({ count: 2, delay: 1000 }))`
Log requests and responses	Both	`tap()` on the response Observable, log `req` in closure
Track in-flight requests	Both	Increment counter on request, decrement in `finalize()`

10. Modern pattern: `toSignal()`

For simple one-off fetches with no manual loading/error state, toSignal() converts the Observable directly to a signal and manages the subscription automatically.

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

@Component({ ... })
export class TasksComponent {
  private http = inject(HttpClient);

  tasks = toSignal(
    this.http.get<Task[]>('/api/tasks'),
    { initialValue: [] }
  );
}

@for (task of tasks(); track task.id) {
  <li>{{ task.title }}</li>
}

For reactive GET patterns like debounced search, combine toObservable() and toSignal():

query = signal('');

results = toSignal(
  toObservable(this.query).pipe(
    debounceTime(300),
    switchMap(q => this.http.get<Task[]>(`/api/tasks?search=${q}`))
  ),
  { initialValue: [] }
);

switchMap cancels the in-flight request when query changes before the response arrives, preventing stale results.

Summary

Use case	Approach
Simple fetch	`http.get<T>().subscribe({ next, error })`
Loading state that resets on error too	`pipe(finalize(() => isLoading.set(false)))`
Remap error messages	`pipe(catchError(err => throwError(() => new Error(...))))`
Safe fallback on error	`pipe(catchError(() => of(defaultValue)))`
Reusable HTTP logic	Move to a service, return Observable, subscribe in component
Shared state across components	Signal in service + `tap()` to update it
Simple fetch, no manual state	`toSignal(http.get(...), { initialValue: [] })`
Reactive fetch from a signal input	`toObservable(signal).pipe(debounceTime, switchMap) → toSignal`

Change Detection

Atilla Baspinar — Mon, 29 Jun 2026 20:57:35 +0000

Change detection is how Angular keeps the DOM in sync with component state. Understanding it matters for performance and for knowing why an update sometimes doesn't appear when expected.

1. How Angular detects changes (Zone.js)

By default Angular uses Zone.js, which monkey-patches browser async APIs — setTimeout, Promise.then, addEventListener, XMLHttpRequest — so Angular knows when any async operation completes. After each one, Angular runs change detection: it walks the component tree from root to leaves, evaluates every template binding, and updates the DOM where a value has changed.

This means every component is checked after every async event, even if only one unrelated component triggered it.

2. Development mode double check

In development mode Angular runs change detection twice per cycle. The second pass verifies that the first pass did not produce side effects that changed binding values. If a binding returns a different value on the second pass, Angular throws:

ExpressionChangedAfterItHasBeenCheckedError

This always points to a real problem — state is being mutated during rendering (in a lifecycle hook, a getter with side effects, etc.). Fix the root cause; do not suppress it.

3. `OnPush` change detection strategy

By default every component uses ChangeDetectionStrategy.Default — it is checked on every change detection cycle. Setting a component to OnPush tells Angular to skip it unless one of these conditions is met:

An @Input() receives a new reference (not a mutated value)
An event fires from within the component or one of its children (click, keydown, etc.)
An async pipe in the template receives a new emission
ChangeDetectorRef.markForCheck() is called manually
A signal read in the template changes (Angular 17+)

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

@Component({
  selector: 'app-task-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `...`,
})
export class TaskListComponent {}

OnPush is most effective on leaf or mid-tree components with stable inputs — it prevents large subtrees from being checked when unrelated state changes elsewhere.

The Angular CLI defaults to OnPush for generated components as of Angular 19, reflecting the shift toward signal-based components where fine-grained updates make full-tree scanning unnecessary.

4. `OnPush` with service-shared state

The main pitfall of OnPush: if a service holds a plain object or array and mutates it in place without replacing the reference, OnPush components depending on it will not update — none of the five conditions above are triggered.

// ❌ mutating in place — OnPush component will not re-render
this.tasksService.tasks.push(newTask);

Solution A — signals in the service (recommended)

Signals work automatically with OnPush. When a signal changes, Angular is notified directly without Zone.js or a reference change.

// tasks.service.ts
@Injectable({ providedIn: 'root' })
export class TasksService {
  tasks = signal<Task[]>([]);

  addTask(task: Task) {
    this.tasks.update(list => [...list, task]);
  }
}

@Component({
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @for (task of tasksService.tasks(); track task.id) {
      <li>{{ task.title }}</li>
    }
  `,
})
export class TaskListComponent {
  tasksService = inject(TasksService);
}

Solution B — `BehaviorSubject` + `async` pipe

The older pattern before signals. A BehaviorSubject holds the current value and emits it to new subscribers on demand. AsyncPipe subscribes, calls markForCheck() when a new value arrives, and unsubscribes on destroy automatically.

// tasks.service.ts
@Injectable({ providedIn: 'root' })
export class TasksService {
  private _tasks = new BehaviorSubject<Task[]>([]);
  tasks$ = this._tasks.asObservable();

  addTask(task: Task) {
    this._tasks.next([...this._tasks.value, task]);
  }
}

@Component({
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [AsyncPipe, NgFor],
  template: `
    <li *ngFor="let task of tasksService.tasks$ | async">{{ task.title }}</li>
  `,
})
export class TaskListComponent {
  tasksService = inject(TasksService);
}

Solution C — `ChangeDetectorRef.markForCheck()`

If you use a plain subscription instead of the async pipe, call markForCheck() manually after updating local state:

@Component({ changeDetection: ChangeDetectionStrategy.OnPush })
export class TaskListComponent implements OnInit {
  private cdr = inject(ChangeDetectorRef);
  tasks: Task[] = [];

  ngOnInit() {
    this.tasksService.tasks$.subscribe(tasks => {
      this.tasks = tasks;
      this.cdr.markForCheck(); // schedule this component for checking
    });
  }
}

5. `ChangeDetectorRef`

ChangeDetectorRef gives direct access to a component's slot in the change detection tree.

Method	What it does
`markForCheck()`	Schedules this component and its ancestors for the next CD cycle (lazy)
`detectChanges()`	Synchronously checks this component and its children immediately
`detach()`	Removes this component from the CD tree entirely
`reattach()`	Re-attaches a previously detached component

markForCheck() is lazy — it queues work for the next cycle. detectChanges() is immediate — use it when you need the DOM updated synchronously, such as after receiving a value from a non-Angular callback (e.g., a third-party library):

private cdr = inject(ChangeDetectorRef);

onExternalCallback(value: string) {
  this.title = value;
  this.cdr.detectChanges(); // DOM updates immediately, not on the next cycle
}

6. `NgZone` — running code outside Angular

Every async operation inside Angular's zone triggers change detection. High-frequency work — scroll listeners, canvas animations, WebSocket frames, setInterval-based polling — inside the zone causes Angular to re-check the entire tree on every tick.

NgZone.runOutsideAngular() runs code without Zone.js tracking it. When you need to push a result back to the UI, call NgZone.run() to re-enter the zone and trigger change detection.

import { NgZone, inject } from '@angular/core';

@Component({ ... })
export class ChartComponent implements OnInit {
  private ngZone = inject(NgZone);
  private rawValue = 0;
  displayValue = 0;

  ngOnInit() {
    this.ngZone.runOutsideAngular(() => {
      setInterval(() => {
        this.rawValue = this.readSensor(); // runs every 16ms, no CD triggered
      }, 16);
    });
  }

  onUserAction() {
    this.ngZone.run(() => {
      this.displayValue = this.rawValue; // re-enters zone, CD runs after this
    });
  }
}

NgZone is only relevant in Zone.js-based apps. In zoneless mode there is no zone to escape from.

7. Zoneless mode (Angular 18+)

In zoneless mode Zone.js is not loaded at all. Angular no longer triggers change detection after async events. Instead, updates happen only when Angular is explicitly notified:

A signal read in a template changes
ChangeDetectorRef.markForCheck() or detectChanges() is called
ApplicationRef.tick() is called manually

This makes OnPush the effective behaviour for all components — Angular only visits components it knows have changed state.

Enabling zoneless

// app.config.ts
import { provideZonelessChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(), // Angular 19+ name (was provideExperimentalZonelessChangeDetection in 18)
  ],
};

Remove zone.js from polyfills in angular.json:

"polyfills": []

Zoneless was developer preview in Angular 18, stable in Angular 19, and became the default in Angular 21.

Signals are the foundation

In a zoneless app, signals are the primary driver of change detection. Components that read signals get automatic, fine-grained DOM updates without Zone.js, OnPush boilerplate, or ChangeDetectorRef:

Approach	Zone.js	`OnPush`	`markForCheck()`
Default strategy + Zone.js	Required	Not needed	Not needed
`OnPush` + Zone.js	Required	Opt-in	Sometimes
`OnPush` + signals + Zone.js	Can remove	Auto-compatible	Not needed
Zoneless + signals	Not loaded	Irrelevant	Not needed

Dependency Injection

Atilla Baspinar — Mon, 29 Jun 2026 20:57:13 +0000

Dependency Injection (DI) is a pattern where dependencies are supplied to a class instead of created inside it. Angular has a built-in DI system that handles creation and sharing of services.

1. Creating a Service

Decorate a class with @Injectable to make it injectable. providedIn: 'root' registers it as an app-wide singleton that is also tree-shakable — if nothing injects it, it won't be in the bundle:

import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class AuthService {
  isLoggedIn = false;

  login() { this.isLoggedIn = true; }
  logout() { this.isLoggedIn = false; }
}

2. `@Service()` — Angular 22+

Angular 22 introduced @Service() as a shorthand for @Injectable({ providedIn: 'root' }). Less boilerplate, same behavior:

import { Service } from '@angular/core';

@Service()
export class AuthService {
  isLoggedIn = false;

  login() { this.isLoggedIn = true; }
  logout() { this.isLoggedIn = false; }
}

Note: @Service() only works with inject() — it does not support constructor injection. For most new services, prefer @Service() when targeting Angular 22+.

3. Injecting a Service

Use the inject() function in a class field — this is the modern, preferred approach:

import { Component, inject } from '@angular/core';
import { AuthService } from './auth.service';

@Component({ ... })
export class NavbarComponent {
  private auth = inject(AuthService);

  logout() { this.auth.logout(); }
}

Constructor injection is equivalent and still valid, but inject() is cleaner:

constructor(private auth: AuthService) {}

4. Providing at Component Level

Adding a service to a component's providers array creates a new instance scoped to that component and its children. The root singleton is untouched.

@Component({
  selector: 'app-cart',
  providers: [CartService],
  template: `...`,
})
export class CartComponent {
  private cart = inject(CartService);
}

Useful when different parts of the UI need isolated state (e.g. two independent forms on the same page).

5. `InjectionToken`

For non-class values like config objects, strings, or primitives, use InjectionToken. TypeScript interfaces are erased at runtime and cannot be used as tokens.

import { InjectionToken } from '@angular/core';

export interface AppConfig {
  apiUrl: string;
  production: boolean;
}

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

Provide it where you bootstrap the app:

bootstrapApplication(AppComponent, {
  providers: [
    { provide: APP_CONFIG, useValue: { apiUrl: 'https://api.example.com', production: false } }
  ]
});

Inject it normally:

private config = inject(APP_CONFIG);

6. Provider Types

`useValue` — static value

The most common use is injecting configuration:

providers: [
  { provide: APP_CONFIG, useValue: { apiUrl: '...', production: false } }
]

`useClass` — substitute an implementation

Swap one class for another — handy for mocking in tests:

providers: [
  { provide: Logger, useClass: MockLogger }
]

`useFactory` — compute the value at runtime

When the value depends on other services or runtime conditions:

providers: [
  {
    provide: LoggerService,
    useFactory: () => {
      const config = inject(APP_CONFIG);
      return new LoggerService(config.production ? 'error' : 'debug');
    }
  }
]

7. Optional Injection

If a dependency may or may not be provided, use { optional: true } to get null instead of an error:

private analytics = inject(AnalyticsService, { optional: true });

ngOnInit() {
  this.analytics?.track('page_view');
}

Angular Pipes

Atilla Baspinar — Mon, 29 Jun 2026 20:56:48 +0000

A pipe transforms a value in the template using the | operator. Pipes do not mutate the original value — they return a new transformed one.

<p>{{ username | uppercase }}</p>
<p>{{ dueDate | date:'mediumDate' }}</p>

1. Built-in pipes

All built-in pipes come from @angular/common. In standalone components, import each pipe individually rather than the entire CommonModule.

import { DatePipe, UpperCasePipe, CurrencyPipe } from '@angular/common';

@Component({
  imports: [DatePipe, UpperCasePipe, CurrencyPipe],
  ...
})

Pipe	Example	Output
`uppercase`	`'hello' \	uppercase`
`lowercase`	`'HELLO' \	lowercase`
`titlecase`	`'hello world' \	titlecase`
`date`	`date \	date:'mediumDate'`
`number`	`3.14159 \	number:'1.0-2'`
`currency`	`9.9 \	currency:'USD'`
`percent`	`0.85 \	percent`
`slice`	`'Angular' \	slice:0:3`
`json`	`obj \	json`
`keyvalue`	`obj \	keyvalue`
`async`	`obs$ \	async`

Pipe parameters

Pass parameters after the pipe name with :. Chain multiple parameters with more colons.

<!-- date format string -->
<p>{{ dueDate | date:'yyyy-MM-dd' }}</p>

<!-- number: minIntegers.minFractionDigits-maxFractionDigits -->
<p>{{ 3.14159 | number:'1.0-2' }}</p>              <!-- 3.14 -->

<!-- currency: currencyCode, display, digitsInfo -->
<p>{{ 9.9 | currency:'EUR':'symbol':'1.2-2' }}</p> <!-- €9.90 -->

Chaining pipes

Apply multiple pipes left to right:

<p>{{ username | slice:0:10 | uppercase }}</p>

`async` pipe

AsyncPipe subscribes to an Observable or Promise and returns its latest emitted value. It automatically unsubscribes when the component is destroyed.

@if (users$ | async; as users) {
  @for (user of users; track user.id) {
    <li>{{ user.name }}</li>
  }
}

In modern Angular, toSignal() is often a cleaner alternative — it converts the Observable to a signal so you can read the value with users() in the template without needing the async pipe.

2. Custom pipes

Create a pipe with the @Pipe decorator and implement the PipeTransform interface. The transform() method receives the input value as its first argument, followed by any additional parameters you declare.

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'truncate',
  standalone: true,
})
export class TruncatePipe implements PipeTransform {
  transform(value: string, limit: number = 20, ellipsis: string = '…'): string {
    return value.length > limit ? value.slice(0, limit) + ellipsis : value;
  }
}

Import it in the component and use it in the template. Extra arguments map to the additional parameters in transform(), in order:

@Component({
  imports: [TruncatePipe],
  ...
})

<p>{{ description | truncate }}</p>           <!-- limit=20, ellipsis='…' -->
<p>{{ description | truncate:50 }}</p>        <!-- limit=50, ellipsis='…' -->
<p>{{ description | truncate:50:'...' }}</p>  <!-- limit=50, ellipsis='...' -->

3. Pure vs impure pipes

By default every pipe is pure — Angular only calls transform() when the input value or parameters change by reference. If you mutate a property inside an object or push an item into an array without replacing the reference, a pure pipe will not re-run, because the object or array reference itself has not changed.

Set pure: false to make a pipe impure — Angular then calls transform() on every change detection cycle, regardless of whether the reference changed.

@Pipe({
  name: 'filterActive',
  standalone: true,
  pure: false,
})
export class FilterActivePipe implements PipeTransform {
  transform(items: Item[]): Item[] {
    return items.filter(item => item.active);
  }
}

With pure: true (the default), pushing a new item into items would not trigger the pipe. With pure: false, it runs on every cycle and picks up the change — but also runs constantly, which can hurt performance on large lists.

Prefer component logic over impure pipes. Filter or sort in the component class and expose the result as a property or computed signal. This gives you control over when the work runs and avoids the performance cost of running on every change detection cycle.

Angular Directives

Atilla Baspinar — Mon, 29 Jun 2026 20:56:21 +0000

A directive is a class that adds behavior to an element in the DOM. Angular has three kinds:

Type	What it does	Example
Component	Owns a template and DOM subtree	`@Component`
Attribute	Changes behavior or appearance of the host element	`NgModel`, custom `@Directive`
Structural	Adds or removes elements from the DOM	`ngIf`, `ngFor` — superseded by `@if`, `@for` in Angular 17+

1. Built-in attribute directives

Attribute directives do not alter the DOM structure — they change how the host element looks or behaves. Common built-in examples:

NgModel — two-way binding for form inputs (from FormsModule)
NgClass — conditionally apply CSS classes
NgStyle — conditionally apply inline styles

These are covered in the forms and class/style binding tutorials.

2. Structural directives

Structural directives modify the DOM by adding or removing elements. Angular 17+ introduced built-in control flow syntax that replaces the need for them:

Old (structural directive)	Modern (built-in control flow)
`*ngIf="condition"`	`@if (condition) { }`
`*ngFor="let x of list"`	`@for (x of list; track x.id) { }`
`ngSwitch` / `ngSwitchCase`	`@switch` / `@case`

The old * syntax still works but requires importing NgIf, NgFor (or CommonModule) in the component's imports array. Prefer built-in control flow in new code.

Custom structural directives use <ng-template> and ViewContainerRef under the hood — the *directive syntax is just shorthand for <ng-template [directive]>. They are rarely needed in modern Angular and are not covered in depth here.

3. Custom attribute directive

A custom directive is a class decorated with @Directive. The selector can be any valid CSS selector — element, attribute, or class — but an attribute selector ([appMyDirective]) is the convention for directives (element selectors are reserved for components).

Mark it standalone: true (recommended), then add it to the consuming component's imports array.

import { Directive, ElementRef, inject } from '@angular/core';

@Directive({
  selector: '[appHighlight]',
  standalone: true,
})
export class HighlightDirective {
  private el = inject(ElementRef);
}

<!-- consumer template -->
<p appHighlight>Hover over me</p>

// consumer component
@Component({
  imports: [HighlightDirective],
  ...
})

Listening to host events

The host property in @Directive maps DOM event names to handler expressions. Use $event to receive the native event object.

@Directive({
  selector: '[appHighlight]',
  standalone: true,
  host: {
    '(mouseenter)': 'onEnter($event)',
    '(mouseleave)': 'onLeave($event)',
  },
})
export class HighlightDirective {
  private el = inject(ElementRef);

  onEnter(event: MouseEvent) {
    this.el.nativeElement.style.backgroundColor = 'lightyellow';
  }

  onLeave(event: MouseEvent) {
    this.el.nativeElement.style.backgroundColor = '';
  }
}

@HostListener is the older decorator-based alternative and produces the same result:

@HostListener('mouseenter', ['$event'])
onEnter(event: MouseEvent) { ... }

Prefer the host property in modern code — it keeps all host bindings in one place and does not require a decorator import.

Directive inputs

Directives accept inputs from the template the same way components do. Use @Input() (decorator) or input() (signal, Angular 17.1+).

Explicit input

The directive attribute applies the directive; a separate binding sets the input by name.

@Directive({
  selector: '[appHighlight]',
  standalone: true,
  host: {
    '(mouseenter)': 'onEnter()',
    '(mouseleave)': 'onLeave()',
  },
})
export class HighlightDirective {
  color = input('yellow'); // signal input, default 'yellow'
  private el = inject(ElementRef);

  onEnter() {
    this.el.nativeElement.style.backgroundColor = this.color();
  }

  onLeave() {
    this.el.nativeElement.style.backgroundColor = '';
  }
}

<!-- directive applied with attribute; color passed separately -->
<p appHighlight [color]="'orange'">Hover me</p>

Simplified input — alias matching the selector

When the input's alias matches the selector name, the directive attribute itself carries the value. No separate attribute is needed.

color = input('yellow', { alias: 'appHighlight' });
// decorator style: @Input('appHighlight') color = 'yellow';

<!-- expression binding — evaluates 'orange' as a string expression -->
<p [appHighlight]="'orange'">Hover me</p>

<!-- static value — assigns the literal string without brackets -->
<p appHighlight="orange">Hover me</p>

The alias makes [appHighlight] double as both the directive selector and the input binding — one attribute does both jobs.

Service injection

Directives support dependency injection the same way components do. Use inject() in a field initializer (preferred) or constructor injection.

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

@Injectable({ providedIn: 'root' })
export class AuthService {
  isAdmin = signal(false);
}

import { Directive, ElementRef, inject, effect } from '@angular/core';
import { AuthService } from './auth.service';

@Directive({
  selector: '[appAdminOnly]',
  standalone: true,
})
export class AdminOnlyDirective {
  private auth = inject(AuthService);
  private el   = inject(ElementRef);

  constructor() {
    effect(() => {
      // reacts automatically whenever isAdmin changes
      this.el.nativeElement.style.display = this.auth.isAdmin() ? '' : 'none';
    });
  }
}

<button appAdminOnly>Delete user</button>

Constructor injection is also valid: constructor(private auth: AuthService) {}. inject() is preferred in modern code because it works in field initializers and keeps the constructor clean.

4. `hostDirectives` — applying a directive without an attribute

A component can attach directives to itself via hostDirectives in @Component. The directive is applied automatically — consumers do not need to add the attribute in the template.

import { Component } from '@angular/core';
import { HighlightDirective } from './highlight.directive';

@Component({
  selector: 'app-card',
  hostDirectives: [HighlightDirective],
  template: `<div class="card"><ng-content /></div>`,
})
export class CardComponent {}

<!-- no [appHighlight] needed — it is already attached by the component -->
<app-card>Card content</app-card>

To expose the directive's inputs or outputs to the component's consumers, list them explicitly:

hostDirectives: [{
  directive: HighlightDirective,
  inputs: ['color'],   // <app-card [color]="'blue'"> now works
}]

Signals and Effects

Atilla Baspinar — Mon, 29 Jun 2026 20:55:54 +0000

Version coverage

signal(), computed(), effect(), toSignal(), toObservable() — stable since Angular 17 (developer preview in Angular 16)

Effect onCleanup — stable since Angular 17

Zoneless mode — stable since Angular 18, default since Angular 21

A signal is a reactive value container. When a signal's value changes, Angular knows exactly which parts of the UI depend on it and updates only those parts — no full component scan needed.

1. Writable signals

Create a signal with signal(), passing the initial value. Read it by calling it like a function. Update it with set() or update().

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

export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(c => c + 1); // derive next value from current
  }

  reset() {
    this.count.set(0); // set an explicit value
  }
}

set() replaces the value. update() receives the current value and returns the next one.

2. Computed signals

computed() creates a read-only signal whose value is derived from other signals. Angular evaluates the derivation lazily (only when first read) and caches the result. When any dependency signal changes, the cached value is invalidated and recalculated on the next read.

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

export class CartComponent {
  items = signal<{ price: number }[]>([]);
  total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));
}

total always reflects the current sum of items. You never call .set() on it — Angular manages it.

3. Reading signals in templates

In a template, you read a signal by calling it as a function. Angular automatically tracks every signal called during template rendering and re-renders the component whenever any of those signals change.

<!-- counter.html -->
<p>Count: {{ count() }}</p>
<p>Total: {{ total() }}</p>
<button (click)="increment()">+1</button>

There is no async pipe, no subscription, and no manual change detection call needed. Angular handles all of it.

4. Why you don't "subscribe" to signals in the component class

Reading a signal in the component class (outside a reactive context) just returns the current value at that instant — it does not set up a reactive dependency. The read is synchronous and stateless.

ngOnInit() {
  const current = this.count(); // reads the value once — no subscription
  console.log(current);         // this will NOT re-run when count changes
}

This is intentional. Signals are not Observables. There is no .subscribe() method. If you need to react to signal changes in the class — for example to trigger a side effect — use effect().

5. `effect()` — reacting to signal changes in the class

effect() creates a reactive side effect. Angular runs its callback immediately, tracks which signals are read inside it, and re-runs the callback automatically whenever any of those signals change.

Use effect() when you need to bridge a signal to a non-reactive API: logging, calling a third-party library, writing to localStorage, or manipulating the DOM directly.

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

export class ThemeComponent {
  theme = signal<'light' | 'dark'>('light');

  constructor() {
    effect(() => {
      document.body.setAttribute('data-theme', this.theme()); // runs whenever theme changes
    });
  }
}

effect() must be called in an injection context — the constructor or a field initializer. It cannot be called inside a lifecycle hook like ngOnInit.

Why not just use a getter or computed()? computed() is for deriving reactive state. effect() is for side effects — actions with no return value that touch something outside Angular's reactivity system.

6. Effect cleanup

When an effect re-runs (because a dependency changed) or when the component is destroyed, you may need to clean up work from the previous run — cancel a timer, abort a fetch, remove a listener. The effect callback receives an optional onCleanup function for this purpose.

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

export class PollingComponent {
  interval = signal(3000);

  constructor() {
    effect((onCleanup) => {
      const id = setInterval(() => {
        this.fetchData();
      }, this.interval()); // tracked — effect re-runs if interval changes

      onCleanup(() => {
        clearInterval(id); // called before the next run, or when the component is destroyed
      });
    });
  }

  private fetchData() { /* ... */ }
}

The sequence when interval changes:

onCleanup callback runs → clearInterval(id) cancels the old timer
Effect re-runs → a new setInterval starts with the updated value

Without onCleanup, changing interval would start a new timer on each change while the old ones kept running.

7. Reactive context

Angular only tracks signal reads that happen inside a reactive context — an execution scope that Angular monitors for signal access. When a signal is read inside one, Angular registers it as a dependency and automatically re-runs the context whenever that signal's value changes.

There are three reactive contexts in Angular:

Context	Re-runs when
Template rendering	Any signal read during rendering changes
`computed()` callback	Any signal read inside the callback changes
`effect()` callback	Any signal read inside the callback changes

Reading a signal outside these contexts is a plain synchronous function call. It returns the current value at that instant but sets up no dependency — Angular will not re-run anything when the signal later changes.

export class ExampleComponent {
  count = signal(0);

  // reactive context — computed() tracks count()
  doubled = computed(() => this.count() * 2);

  constructor() {
    // reactive context — effect() tracks count()
    effect(() => {
      console.log('count is now:', this.count());
    });
  }

  ngOnInit() {
    const value = this.count(); // NOT reactive — one-time snapshot, no tracking
    console.log(value);         // will not re-run when count changes
  }

  onClick() {
    this.count.set(this.count() + 1); // reading here to derive a value is fine —
                                       // but it is still not tracked
  }
}

Template expressions are reactive contexts too — Angular re-renders only the parts of the template that read a changed signal:

<p>{{ count() }}</p>     <!-- reactive — updates when count changes -->
<p>{{ doubled() }}</p>   <!-- reactive — updates when doubled recomputes -->

This is the reason effect() exists. A plain method, event handler, or lifecycle hook is not a reactive context, so if you need to respond to a signal change from the class side, you must put that code inside an effect.

`untracked()` — reading a signal without tracking it

Inside a reactive context you can opt out of tracking a specific read by wrapping it in untracked(). The signal's current value is read, but Angular does not add it as a dependency — the context will not re-run when that particular signal changes.

import { effect, untracked } from '@angular/core';

effect(() => {
  const primary   = this.primarySignal();           // tracked
  const secondary = untracked(() => this.secondarySignal()); // not tracked
  console.log(primary, secondary);
  // re-runs only when primarySignal changes, even though secondarySignal is read
});

This is useful when an effect needs to read a supporting value for context but should only be triggered by a specific set of signals.

8. Signals vs. Zone.js change detection

Before signals, Angular relied on Zone.js to detect when anything in the app might have changed. Zone.js monkey-patches browser APIs (setTimeout, event listeners, Promises, etc.) so Angular knows when to trigger a full change detection scan of the component tree.

Signals make this unnecessary. Because Angular knows exactly which signal each template reads, it can skip the full scan and update only the components that actually depend on a changed value. This is the foundation of Angular's zoneless mode, which is stable from Angular 18+ and the default from Angular 21+. In zoneless mode, Zone.js is not loaded at all — change detection is driven entirely by signals.

In practice for new apps: prefer signals over @Input() / @Output() with plain class properties. Signals are what makes zoneless possible.

9. Signals and RxJS

Signals and RxJS solve overlapping but different problems. Angular provides an interop layer in @angular/core/rxjs-interop so you can use both together where needed.

When to use signals vs. RxJS

Use signals when…	Use RxJS when…
Holding and deriving UI state	Handling async streams (HTTP, WebSocket, events)
Driving template rendering	Combining, debouncing, or transforming event sequences
Replacing `@Input()` / `@Output()`	You need operators like `switchMap`, `debounceTime`, `combineLatest`
Working in a zoneless app	Integrating with libraries that return Observables

The general pattern in modern Angular: use RxJS for data fetching and complex async logic, then convert the result to a signal for the template.

`toSignal()` — Observable → Signal

toSignal() subscribes to an Observable and exposes its latest value as a read-only signal. The subscription is automatically cleaned up when the component is destroyed.

import { toSignal } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';

export class UsersComponent {
  private http = inject(HttpClient);

  users = toSignal(
    this.http.get<User[]>('/api/users'),
    { initialValue: [] }   // signal value before the Observable emits
  );
}

@for (user of users(); track user.id) {
  <li>{{ user.name }}</li>
}

initialValue sets the signal's value before the Observable has emitted. Without it, the signal type includes undefined until the first emission.

`toObservable()` — Signal → Observable

toObservable() wraps a signal as an Observable. It emits the signal's latest value after each change stabilises (not synchronously on every .set() call). Use it when you need to pipe a signal through RxJS operators.

import { toObservable } from '@angular/core/rxjs-interop';
import { debounceTime, switchMap } from 'rxjs/operators';

export class SearchComponent {
  query = signal('');

  results = toSignal(
    toObservable(this.query).pipe(
      debounceTime(300),
      switchMap(q => this.http.get<Result[]>(`/api/search?q=${q}`))
    ),
    { initialValue: [] }
  );
}

This pattern — toObservable → RxJS pipeline → toSignal — is the idiomatic way to do debounced search or any async transformation driven by a signal.

10. `input()`, `model()`, and `output()`

Angular 17+ introduced decorator-free alternatives to @Input(), @Output(), and two-way binding. Two of them are signals; one is not.

`input()` — read-only signal input (Angular 17.1+)

input() replaces @Input(). It returns an InputSignal — a read-only signal whose value is set by the parent. Because it is a signal, you can use it directly inside computed() and effect() without any extra wiring.

import { input, computed } from '@angular/core';

export class UserCardComponent {
  // optional with a default
  name = input('Anonymous');

  // required — throws at runtime if parent does not provide it
  userId = input.required<number>();

  // derived value reacts automatically when userId changes
  profileUrl = computed(() => `/users/${this.userId()}`);
}

<!-- user-card.html — read signals with () just like any other signal -->
<h2>{{ name() }}</h2>
<a [href]="profileUrl()">Profile</a>

Because name and profileUrl are signals, they must be called with () in the template. This is different from @Input() where you would write {{ name }} without parentheses. The () is what tells Angular to track the value reactively and re-render when it changes.

<!-- parent template -->
<app-user-card [userId]="42" [name]="'Alice'" />

InputSignal is read-only — calling .set() or .update() on it is a compile error.

`model()` — writable signal for two-way binding (Angular 17.2+)

model() creates a ModelSignal, which is a writable signal that also acts as an input/output pair. The parent can bind to it with [()] syntax; the child can update it with .set() or .update() and the new value is automatically propagated back to the parent.

Under the hood, model() declares both an input named property and an output named propertyChange — the same convention used by @Input() + @Output() two-way binding, but without the boilerplate.

import { model } from '@angular/core';

export class RatingComponent {
  // writable signal — parent can read it, child can change it
  rating = model(0);

  increase() {
    this.rating.update(r => r + 1); // parent's bound variable updates automatically
  }
}

<!-- rating.html — read with () like any writable signal -->
<p>Current rating: {{ rating() }}</p>
<button (click)="increase()">+</button>

rating() reads the current value reactively. When increase() calls this.rating.update(), Angular updates both the child template and the parent's bound variable in one step. Compare this to @Input() where you would write {{ rating }} without () and the parent's variable would not update at all without a manual @Output() emit.

<!-- parent template -->
<app-rating [(rating)]="userRating" />
<p>Parent sees: {{ userRating }}</p>

[(rating)] desugars to [rating]="userRating" (ratingChange)="userRating = $event" — exactly what you would write manually with @Input() + @Output(). The difference is that model() sets this up in one line, and this.rating is a real signal usable inside computed() and effect().

	`@Input()` + `@Output()`	`model()`
Two-way binding syntax	`[(prop)]` ✓	`[(prop)]` ✓
Value as signal	No	Yes — `ModelSignal`
Writable from child	Manual emit	`.set()` / `.update()`
Use in `computed()`	No	Yes

`output()` — decorator-free event emitter (Angular 17.3+)

output() replaces @Output() + EventEmitter. It is not a signal. It returns an OutputEmitterRef<T> which only has one method: .emit(). You cannot call this.myOutput() to read a value from it — it is a one-way notification channel, not a reactive value.

import { output } from '@angular/core';

export class SearchComponent {
  searched = output<string>(); // OutputEmitterRef<string> — not a signal

  onSearch(query: string) {
    this.searched.emit(query);
  }
}

<!-- parent template — identical to @Output() usage -->
<app-search (searched)="handleSearch($event)" />

output() belongs to the same decorator-free API family as input() and model(), but it has no connection to signal reactivity. It is included here for completeness.

	`input()`	`model()`	`output()`
Type returned	`InputSignal`	`ModelSignal`	`OutputEmitterRef`
Is a signal	Yes (read-only)	Yes (writable)	No
Direction	Parent → Child	Parent ↔ Child	Child → Parent
Usable in `computed()` / `effect()`	Yes	Yes	No
Replaces	`@Input()`	`@Input()` + `@Output()` pair	`@Output()` + `EventEmitter`

11. Signals and effects compared to React

If you come from React, Angular signals and effects map closely to concepts you already know — but with two key structural differences: Angular tracks dependencies automatically (no dependency arrays), and a signal change only updates the parts of the template that read it, not the whole component.

`useState` vs `signal()`

Both hold reactive state. The API is slightly different:

// React
const [count, setCount] = useState(0);
setCount(5);                        // set a value
setCount(prev => prev + 1);         // derive from previous

// Angular
count = signal(0);
this.count.set(5);                  // set a value
this.count.update(prev => prev + 1); // derive from previous

Reading is the biggest visible difference. In React, count is a plain variable captured by the render closure. In Angular, count() is a function call — the () is what registers the reactive dependency.

	React `useState`	Angular `signal()`
Read	`count`	`count()`
Write (replace)	`setCount(val)`	`count.set(val)`
Write (derive)	`setCount(prev => ...)`	`count.update(prev => ...)`
On change	Whole component re-renders	Only signal-dependent DOM updates
Stale closure risk	Yes — closures capture old values	No — `count()` always reads current value

`useMemo` vs `computed()`

Both derive a cached value from other state. The critical difference is that React requires you to list dependencies manually, while Angular tracks them automatically by observing which signals are called during the derivation.

// React — dependency array is manual and error-prone
const total = useMemo(
  () => items.reduce((sum, item) => sum + item.price, 0),
  [items]   // must be kept in sync by hand
);

// Angular — no dependency array; Angular tracks items() automatically
total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));

If you add a new signal inside the computed() body, Angular picks it up automatically. In React, forgetting to add a dependency to useMemo silently produces stale values.

`useEffect` vs `effect()`

Both run a side effect in response to state changes. Same automatic vs. manual dependency distinction applies.

// React — manual dependency array
useEffect(() => {
  document.body.setAttribute('data-theme', theme);
}, [theme]);   // must list every dependency

// Angular — automatic tracking
effect(() => {
  document.body.setAttribute('data-theme', this.theme()); // theme() is tracked automatically
});

Cleanup — `return` vs `onCleanup`

React's cleanup is a return value from the effect callback. Angular's is a parameter passed into it.

// React — return a cleanup function
useEffect(() => {
  const id = setInterval(() => fetch('/api/poll'), 3000);
  return () => clearInterval(id);   // runs before next effect or on unmount
}, []);

// Angular — onCleanup parameter
effect((onCleanup) => {
  const id = setInterval(() => this.poll(), this.interval());
  onCleanup(() => clearInterval(id)); // runs before next effect or on destroy
});

Both cleanup functions run at the same moments: before the effect re-runs due to a dependency change, and when the component is destroyed/unmounted.

Summary of differences

	React	Angular
Dependency tracking	Manual arrays (`[dep1, dep2]`)	Automatic — reads inside the callback
On state change	Whole component re-renders	Only the affected template nodes update
Stale closure problem	Yes — must manage carefully	No — signals always read current value
Derived state	`useMemo` with dep array	`computed()` — no array needed
Side effects	`useEffect` with dep array	`effect()` — no array needed
Cleanup	Return a function	`onCleanup` parameter
Where effects can be called	Top level of component only	Constructor or field initializer

Summary

	Signal	Computed	Effect	RxJS Observable
Purpose	Holds reactive state	Derives reactive state	Side effects on signal change	Async event/data streams
Writable	Yes (`set`, `update`)	No	N/A	No (push-based)
Reactive in template	Yes — call as `value()`	Yes — call as `value()`	N/A	Only via `async` pipe or `toSignal()`
Reactive in class	Only inside `effect()` or `computed()`	Only inside `effect()` or `computed()`	Yes — auto-tracks reads	Yes — via `.subscribe()`
Cleanup	N/A	N/A	`onCleanup` callback	`unsubscribe()` or `takeUntilDestroyed`
Zoneless compatible	Yes	Yes	Yes	Yes, via `toSignal()`

Template-Driven Forms

Atilla Baspinar — Mon, 29 Jun 2026 20:55:25 +0000

Angular provides two approaches to forms: template-driven (covered here) and reactive. Template-driven forms use FormsModule and keep most form logic in the template via directives.

1. `FormsModule` and `ngSubmit`

Import FormsModule into the component's imports array to enable template-driven form directives.

When FormsModule is imported, Angular automatically attaches an NgForm directive to every <form> element. This directive tracks the form's state (validity, touched, dirty) and intercepts the native browser submit event.

Use (ngSubmit) instead of the native (submit) — NgForm suppresses the default browser navigation and gives you the Angular-managed form object.

@Component({
  selector: 'app-login',
  templateUrl: './login.html',
  imports: [FormsModule],
})
export class LoginComponent {
  onSubmit() {
    console.log('form submitted');
  }
}

<!-- login.html -->
<form (ngSubmit)="onSubmit()">
  <input type="email" name="email" />
  <button type="submit">Log in</button>
</form>

Every <input> inside a template-driven form must have a name attribute — Angular uses it to register the control with NgForm.

2. Two-way binding with `[(ngModel)]`

ngModel (from FormsModule) binds an input's value to a component property in both directions: the DOM updates when the property changes, and the property updates when the user types.

export class LoginComponent {
  email = '';
  password = '';

  onSubmit() {
    console.log(this.email, this.password);
  }
}

<form (ngSubmit)="onSubmit()">
  <input type="email" name="email" [(ngModel)]="email" />
  <input type="password" name="password" [(ngModel)]="password" />
  <button type="submit">Log in</button>
</form>

[(ngModel)] is syntactic sugar for [ngModel]="email" (ngModelChange)="email = $event". The square brackets push the value in; the parentheses listen for changes coming out.

3. Template variables

A template variable is declared with a # prefix on any element or component in the template. It is similar to a ref in React — it gives you a direct handle to that element or component instance within the same template.

<input #emailInput type="email" />
<button (click)="emailInput.focus()">Focus email</button>

emailInput is a reference to the native HTMLInputElement.

Template variables on custom components

When you place #ref on a custom component, Angular assigns the variable to the component class instance, not the underlying DOM element.

<!-- myRef is the CardComponent instance, not an HTMLElement -->
<app-card #myRef />
<button (click)="myRef.reset()">Reset card</button>

This lets you call methods or read properties directly on the component from within the template.

Referencing the form with `NgForm`

When FormsModule is imported, Angular attaches an NgForm directive to every <form>. You can capture that directive instance by assigning ngForm to a template variable:

<form #loginForm="ngForm" (ngSubmit)="onSubmit(loginForm)">
  <input type="email" name="email" ngModel />
  <input type="password" name="password" ngModel />
  <button type="submit">Log in</button>
  <button type="button" (click)="loginForm.reset()">Reset</button>
</form>

import { NgForm } from '@angular/forms';

export class LoginComponent {
  onSubmit(form: NgForm) {
    if (form.valid) {
      console.log(form.value); // { email: '...', password: '...' }
    }
  }
}

form.value is a plain object keyed by each input's name attribute. loginForm.reset() clears all field values and resets validation state.

Without `NgForm` — binding fields to component member variables

If you don't need NgForm's validity tracking or form.value object, bind each field to a component property with [(ngModel)] and use a plain template variable to get the native HTMLFormElement for reset.

<form #loginForm (ngSubmit)="onSubmit()">
  <input type="email" name="email" [(ngModel)]="email" />
  <input type="password" name="password" [(ngModel)]="password" />
  <button type="submit">Log in</button>
  <button type="button" (click)="reset(loginForm)">Reset</button>
</form>

export class LoginComponent {
  email = '';
  password = '';

  onSubmit() {
    console.log(this.email, this.password);
  }

  reset(form: HTMLFormElement) {
    this.email = '';      // [(ngModel)] propagates '' back to the input
    this.password = '';
    form.reset();         // also resets native browser state (validation highlights, autofill)
  }
}

#loginForm without ="ngForm" is a reference to the native HTMLFormElement — the DOM element itself, not the NgForm directive. So form in reset(form: HTMLFormElement) is the HTMLFormElement, and form.reset() is the native DOM method.

The difference between the two approaches (#form="ngForm" vs plain #form) is covered in the table below. For accessing the form element from the component class instead of passing it through a method argument, see @ViewChild in Section 5.

	`#form="ngForm"`	`#form` (no assignment)
Type	`NgForm` directive instance	`HTMLFormElement`
`form.value`	Object of all field values	Not available
Validity tracking	`form.valid`, `form.dirty`, etc.	Not available
Reset	`form.reset()` (Angular)	`form.reset()` (native DOM)
When to use	When you need validation state	When fields are bound via `[(ngModel)]`

4. Form validation

When FormsModule is imported, Angular recognises standard HTML validation attributes (required, email, minlength, etc.) and tracks validity state on each control automatically.

Per-field validation with a template variable

Bind ngModel to a template variable to get the NgModel instance for that control and read its state directly in the template:

<form #signUpForm="ngForm" (ngSubmit)="onSubmit(signUpForm)">
  <input name="email" ngModel required email #emailCtrl="ngModel" />
  @if (emailCtrl.touched && emailCtrl.invalid) {
    <p class="error">Enter a valid email address.</p>
  }

  <input name="password" ngModel required minlength="8" #passwordCtrl="ngModel" />
  @if (passwordCtrl.touched && passwordCtrl.errors?.['minlength']) {
    <p class="error">Password must be at least 8 characters.</p>
  }

  <button type="submit" [disabled]="signUpForm.invalid">Submit</button>
</form>

import { NgForm } from '@angular/forms';

export class SignUpComponent {
  onSubmit(form: NgForm) {
    if (form.valid) {
      console.log(form.value); // { email: '...', password: '...' }
      form.reset();
    }
  }
}

Key properties available on both NgModel (per-field) and NgForm (whole form):

Property	Meaning
`valid` / `invalid`	Passes / fails all validators
`touched` / `untouched`	Has / has not been focused and blurred
`dirty` / `pristine`	Value has / has not been changed by the user
`errors`	Object with error keys, e.g. `{ required: true }`, `{ minlength: { ... } }`

CSS classes added by Angular

Angular keeps these classes in sync on every form input automatically:

Class pair	What it signals
`ng-pristine` / `ng-dirty`	Value unchanged / changed by user
`ng-untouched` / `ng-touched`	Not yet focused / has been focused
`ng-valid` / `ng-invalid`	All validators pass / at least one fails

Use them in CSS to give validation feedback without extra logic in the component:

input.ng-touched.ng-invalid {
  border-color: red;
}

input.ng-touched.ng-valid {
  border-color: green;
}

5. `@ViewChild` — querying a single element (decorator)

@ViewChild lets you access a template element, component, or directive from inside the component class. The result is available from ngAfterViewInit onwards — not in ngOnInit, because the view hasn't been built yet.

@ViewChild accepts:

Argument	What it selects
A component or directive class	The first matching instance in the view
A template variable name (string)	The element or component the `#variable` points to
`TemplateRef`	An `<ng-template>` element

Example A — querying an `NgForm` directive instance

When the template variable uses ="ngForm", @ViewChild typed as NgForm gives you the directive directly — no .nativeElement needed.

<form #loginForm="ngForm" (ngSubmit)="onSubmit()">
  <input type="email" name="email" ngModel />
  <button type="submit">Log in</button>
  <button type="button" (click)="resetForm()">Reset</button>
</form>

import { ViewChild, AfterViewInit } from '@angular/core';
import { NgForm } from '@angular/forms';

export class LoginComponent implements AfterViewInit {
  @ViewChild('loginForm') form!: NgForm;

  ngAfterViewInit() {
    console.log(this.form.value); // NgForm is available here
  }

  resetForm() {
    this.form.reset();
  }
}

Example B — querying a native HTML element

When the template variable has no ="..." assignment, @ViewChild on a plain HTML element returns an ElementRef — a wrapper around the DOM node. The actual element is at .nativeElement.

<form #loginForm (ngSubmit)="onSubmit()">
  <input type="email" name="email" [(ngModel)]="email" />
  <input type="password" name="password" [(ngModel)]="password" />
  <button type="submit">Log in</button>
  <button type="button" (click)="reset()">Reset</button>
</form>

import { ViewChild, ElementRef, AfterViewInit } from '@angular/core';

export class LoginComponent implements AfterViewInit {
  @ViewChild('loginForm') loginFormEl!: ElementRef<HTMLFormElement>;

  email = '';
  password = '';

  onSubmit() {
    console.log(this.email, this.password);
  }

  reset() {
    this.email = '';
    this.password = '';
    this.loginFormEl.nativeElement.reset(); // native DOM reset for browser-level state
  }
}

This is the @ViewChild equivalent of Option A from Section 3 — the difference is that the form element lives on the class rather than being passed as a method argument.

`@ViewChildren` — querying multiple elements

@ViewChildren selects all matching elements or directives in the view and returns a live QueryList. Useful when you have a dynamic list of child components.

import { ViewChildren, QueryList, AfterViewInit } from '@angular/core';
import { NgModel } from '@angular/forms';

@Component({
  selector: 'app-signup',
  templateUrl: './signup.html',
  imports: [FormsModule],
})
export class SignupComponent implements AfterViewInit {
  @ViewChildren(NgModel) controls!: QueryList<NgModel>;

  ngAfterViewInit() {
    this.controls.forEach(control => {
      console.log(control.name, control.valid);
    });
  }
}

QueryList is live — it updates when the view changes (e.g. when @if adds or removes elements). Subscribe to controls.changes to react to those updates.

6. `viewChild()` and `viewChildren()` — signal-based queries (Angular 17+)

Angular 17 introduced viewChild() and viewChildren() as function-based, signal alternatives to @ViewChild and @ViewChildren. They return signals, so the value is always up to date and composable with computed() and effect().

`viewChild()`

import { viewChild } from '@angular/core';
import { NgForm } from '@angular/forms';

export class LoginComponent {
  form = viewChild<NgForm>('loginForm'); // signal<NgForm | undefined>

  resetForm() {
    this.form()?.reset(); // call the signal to read its current value
  }
}

No need to implement AfterViewInit — the signal is updated automatically when the view initializes.

`viewChildren()`

import { viewChildren } from '@angular/core';
import { NgModel } from '@angular/forms';

export class SignupComponent {
  controls = viewChildren(NgModel); // signal<readonly NgModel[]>

  logAll() {
    this.controls().forEach(c => console.log(c.name, c.valid));
  }
}

viewChildren() returns a signal containing a readonly array (not a QueryList), which makes it straightforward to use in reactive contexts.

7. `@ContentChild` / `contentChild()` — querying projected content

@ContentChild (decorator) and contentChild() (signal, Angular 17+) work like their View equivalents, but they query content projected into the component via <ng-content> rather than elements defined in the component's own template. They are rarely needed in day-to-day development.

// component that receives projected content
@Component({
  selector: 'app-panel',
  template: `
    <div class="panel">
      <ng-content />
    </div>
  `,
})
export class PanelComponent implements AfterContentInit {
  @ContentChild('panelTitle') titleEl!: ElementRef;

  ngAfterContentInit() {
    console.log(this.titleEl.nativeElement.textContent);
  }
}

<!-- parent template -->
<app-panel>
  <h2 #panelTitle>My Panel</h2>
  <p>Some content</p>
</app-panel>

The signal version with contentChild():

import { contentChild, ElementRef } from '@angular/core';

export class PanelComponent {
  titleEl = contentChild<ElementRef>('panelTitle');
}

@ContentChildren / contentChildren() follow the same pattern and return all matches instead of just the first.

8. Related lifecycle hooks

Hook	Triggered when	Use for
`ngAfterViewInit`	Once, after the component's own template and all child views are initialized	First access to `@ViewChild` / `viewChild()` results
`ngAfterViewChecked`	After every change detection check of the component's view	Rarely needed; reading DOM state after each render
`ngAfterContentInit`	Once, after projected content (`<ng-content>`) is initialized	First access to `@ContentChild` / `contentChild()` results
`ngAfterContentChecked`	After every change detection check of projected content	Rarely needed

With signal queries (viewChild(), contentChild()), you generally don't need to implement these hooks — the signal itself handles timing. With decorator queries (@ViewChild, @ContentChild), access the result only inside or after the corresponding After*Init hook.

Angular Lifecycle Hooks

Atilla Baspinar — Mon, 29 Jun 2026 20:54:52 +0000

Angular calls a set of lifecycle hook methods on components and directives at specific moments — during creation, every change detection cycle, and finally before destruction. Implementing the corresponding interface (e.g. OnInit, OnDestroy) is optional but recommended for type safety.

1. `constructor` vs. `ngOnInit`

The constructor is a TypeScript feature, not an Angular lifecycle hook. Angular calls it before inputs are set, so @Input() values are undefined at that point.

@Component({ selector: 'app-card', template: '' })
export class CardComponent implements OnInit {
  @Input() title = '';

  constructor() {
    console.log(this.title); // always '' — input not yet set
  }

  ngOnInit() {
    console.log(this.title); // correct value, inputs are initialized
  }
}

Rule: Use the constructor only for dependency injection. Use ngOnInit for any initialization logic that depends on inputs or injected services.

2. Lifecycle hooks in order

`ngOnChanges(changes: SimpleChanges)`

Runs whenever one or more @Input() values change. On the first render it runs before ngOnInit. The changes argument is a map of input name → SimpleChange object, each containing previousValue, currentValue, and firstChange.

ngOnChanges(changes: SimpleChanges) {
  if (changes['title']) {
    const { previousValue, currentValue, firstChange } = changes['title'];
    console.log(`title changed from "${previousValue}" to "${currentValue}"`);
  }
}

Only implements when the component has @Input() properties. Not called if the component has no inputs.

`ngOnInit()`

Runs once, after all inputs have been set for the first time and ngOnChanges has been called for the first time (if applicable). The component's own template is not yet rendered at this point, but it is safe to read inputs and call services.

ngOnInit() {
  this.data = this.dataService.load(this.id);
}

`ngDoCheck()`

Runs on every change detection cycle that involves this component — which is very frequent. Use it only when you need to detect changes Angular's default change detection misses (e.g. mutated object references). Avoid heavy logic here.

ngDoCheck() {
  // runs on every CD cycle — keep this extremely lightweight
  if (this.items !== this.previousItems) {
    this.previousItems = this.items;
    this.recompute();
  }
}

`ngAfterContentInit()`

Runs once after Angular projects external content into the component's <ng-content> slots. This is where you can safely read @ContentChild / @ContentChildren queries.

@ContentChild(HeaderComponent) header!: HeaderComponent;

ngAfterContentInit() {
  console.log(this.header); // projected content is available here
}

`ngAfterContentChecked()`

Runs after every change detection check of the projected content, including the first. Rarely needed — prefer ngAfterContentInit for one-time setup.

`ngAfterViewInit()`

Runs once after the component's own template (and all child components within it) has been fully initialized. This is where you can safely read @ViewChild / @ViewChildren queries.

@ViewChild('canvas') canvasRef!: ElementRef<HTMLCanvasElement>;

ngAfterViewInit() {
  const ctx = this.canvasRef.nativeElement.getContext('2d');
  // safe to access DOM here
}

`ngAfterViewChecked()`

Runs after every change detection check of the component's view. Rarely needed. Be careful — modifying component state here can cause ExpressionChangedAfterItHasBeenChecked errors.

`ngOnDestroy()`

Runs once, just before Angular removes the component from the DOM. Use it to clean up anything that would otherwise cause memory leaks: timers, subscriptions, event listeners.

export class PollingComponent implements OnInit, OnDestroy {
  private intervalId!: ReturnType<typeof setInterval>;

  ngOnInit() {
    this.intervalId = setInterval(() => {
      this.poll();
    }, 3000);
  }

  ngOnDestroy() {
    clearInterval(this.intervalId); // without this the timer keeps running after the component is gone
  }

  private poll() { /* ... */ }
}

3. `DestroyRef` — modern alternative to `ngOnDestroy` (Angular 16+)

DestroyRef is an injectable token that lets you register a cleanup callback anywhere in the component — right next to the setup code, rather than in a separate ngOnDestroy method. This makes the code easier to follow.

export class PollingComponent implements OnInit {
  private destroyRef = inject(DestroyRef);

  ngOnInit() {
    const intervalId = setInterval(() => {
      this.poll();
    }, 3000);

    this.destroyRef.onDestroy(() => {
      clearInterval(intervalId); // cleanup lives next to setup
    });
  }

  private poll() { /* ... */ }
}

DestroyRef also works well with RxJS via the takeUntilDestroyed operator from @angular/core/rxjs-interop:

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

@Component({ ... })
export class PollingComponent implements OnInit {
  private destroyRef = inject(DestroyRef);

  ngOnInit() {
    interval(3000)
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(() => this.poll());
  }

  private poll() { /* ... */ }
}

The subscription is automatically cancelled when the component is destroyed — no ngOnDestroy needed.

4. Execution order

First render

Order	Hook	Notes
1	`constructor`	DI only — inputs not yet set
2	`ngOnChanges`	Only if the component has `@Input()` properties
3	`ngOnInit`	Inputs are ready
4	`ngDoCheck`
5	`ngAfterContentInit`	Projected content is ready
6	`ngAfterContentChecked`
7	`ngAfterViewInit`	Component's view and child views are ready
8	`ngAfterViewChecked`

Every subsequent change detection cycle

Order	Hook	Notes
1	`ngOnChanges`	Only if an `@Input()` value changed
2	`ngDoCheck`
3	`ngAfterContentChecked`
4	`ngAfterViewChecked`

On destruction

Order	Hook
1	`ngOnDestroy`

5. Which hooks are used most often?

Hook	How common	Typical use
`ngOnInit`	Very common	Load data, read inputs, subscribe to services
`ngOnChanges`	Common	React to input changes
`ngOnDestroy` / `DestroyRef`	Common	Clean up timers, subscriptions
`ngAfterViewInit`	Occasional	Access DOM refs, initialize third-party libraries
`ngAfterContentInit`	Occasional	Access projected content queries
`ngDoCheck`	Rare	Fine-grained change detection
`ngAfterViewChecked`	Rare	Post-render DOM reads
`ngAfterContentChecked`	Rare	Post-check projected content

Angular Class and Style Binding

Atilla Baspinar — Mon, 29 Jun 2026 20:53:21 +0000

Angular lets you bind CSS classes and inline styles to elements dynamically using bracket syntax directly in templates.

1. Class binding

Single class

<div [class.active]="isActive">Content</div>

The value must be truthy to add the class, falsy to remove it.

isActive = true;  // → <div class="active">
isActive = false; // → <div>

Multiple classes

Bind an object where each key is a class name and each value is a boolean expression:

<div [class]="{ active: isActive, disabled: isDisabled, highlighted: count > 0 }">Content</div>

Only keys with truthy values are added to the element.

2. Style binding

Single style

<div [style.background-color]="bgColor">Content</div>

The value must be a valid CSS value string. Setting it to null or undefined removes the style.

bgColor = 'coral';  // → <div style="background-color: coral;">
bgColor = null;     // → style removed

You can also include a unit directly in the property name:

<div [style.font-size.px]="fontSize">Content</div>

fontSize = 16; // → <div style="font-size: 16px;">

Multiple styles

Bind an object where each key is a CSS property name and each value is a CSS value string:

<div [style]="{ 'background-color': bgColor, 'font-size': fontSize + 'px', opacity: opacity }">Content</div>

3. Combining with static classes

Static classes and dynamic class bindings coexist safely — Angular merges them:

<!-- Tailwind static classes + dynamic binding -->
<button class="px-4 py-2 rounded font-semibold" [class.opacity-50]="isDisabled">
  Submit
</button>

The static Tailwind classes are always present. opacity-50 is added or removed based on isDisabled.

4. Single and multi binding on the same element

You can mix single-property and multi-property bindings on the same element. Angular evaluates them independently and merges the results:

<div
  class="card"
  [class.active]="isActive"
  [class]="{ highlighted: isHighlighted, pinned: isPinned }"
  [style.border-color]="borderColor"
  [style]="{ padding: '1rem', opacity: isVisible ? 1 : 0 }"
>
  Content
</div>

What happens to classes and styles not targeted by a binding?

They are preserved. Angular treats static classes and dynamic bindings as additive — each binding only controls the specific classes or styles it declares. Everything else is left untouched.

For classes:

class="card" always stays on the element. No binding touches it.
[class.active] only ever adds or removes the active class. All other classes are unaffected.
[class]="{ highlighted, pinned }" only manages highlighted and pinned. Every other class on the element is ignored.

For styles:

[style.border-color] only sets or removes border-color. All other inline styles remain.
[style]="{ padding, opacity }" only controls padding and opacity. Other styles are left as-is.

So with isActive = true, isHighlighted = false, isVisible = true, and borderColor = 'red', the rendered element would be:

<div class="card active pinned" style="border-color: red; padding: 1rem; opacity: 1;">
  Content
</div>

highlighted is absent because its value was false. card and pinned are present because nothing removed them. Angular never clears a class or style it was not explicitly told to manage.

DEV Community: Atilla Baspinar

Deployment

1. Manual Deployment

Server configuration for SPA routing

2. Deployment with CLI

3. Server-Side Rendering (SSR)

Setup

Rendering modes (Angular 19+)

Before Angular 19

4. Pitfalls

Browser-only code (localStorage, DOM)

Resolvers in SSR

Routing

1. Setup

app.routes.ts

app.config.ts

main.ts

2. <router-outlet>

3. routerLink — Navigation Links

Active link styling with RouterLinkActive

4. Route Parameters

Option A — ActivatedRoute

Option B — input() binding (Angular 16+)

Redirect routes

5. Programmatic Navigation

6. Page Titles

7. Nested Routes

8. snapshot vs Observable

9. Query Params

Setting query params

Reading query params

Option A — input() signal (Angular 16+)

Option B — observable

10. Route Data Resolvers

Comparison to React Router loaders

11. Route Guards

canActivate — protect a route

canDeactivate — guard against leaving

canMatch — conditional route matching

Reactive Forms

1. Setting up a reactive form

2. Built-in validators

Displaying errors in the template

3. Custom validators

4. Async validators

5. Reacting to value changes

6. Setting values programmatically

7. Nested FormGroup

8. FormArray

9. FormGroup validators

Angular HTTP Client

1. Setup

2. GET — Fetching data

Loading and error state

3. Transforming the response with pipe()

4. Custom error handling with catchError()

5. Sending data — POST, PUT, PATCH, DELETE

POST — create a resource

PUT — replace a resource

DELETE — remove a resource

6. HTTP in a service

7. Shared state with signals in a service

8. App-wide error handling with a shared error service

9. HTTP Interceptors

Functional interceptors (Angular 15+)

Intercepting the response

Class-based interceptors (pre-Angular 15)

Common use cases

10. Modern pattern: toSignal()

Summary

Change Detection

1. How Angular detects changes (Zone.js)

2. Development mode double check

3. OnPush change detection strategy

4. OnPush with service-shared state

Solution A — signals in the service (recommended)

Solution B — BehaviorSubject + async pipe

Solution C — ChangeDetectorRef.markForCheck()

5. ChangeDetectorRef

6. NgZone — running code outside Angular

`app.routes.ts`

`app.config.ts`

`main.ts`

2. `<router-outlet>`

3. `routerLink` — Navigation Links

Active link styling with `RouterLinkActive`

Option A — `ActivatedRoute`

Option B — `input()` binding (Angular 16+)

8. `snapshot` vs Observable

Option A — `input()` signal (Angular 16+)

`canActivate` — protect a route

`canDeactivate` — guard against leaving

`canMatch` — conditional route matching

3. Transforming the response with `pipe()`

4. Custom error handling with `catchError()`

10. Modern pattern: `toSignal()`

3. `OnPush` change detection strategy

4. `OnPush` with service-shared state

Solution B — `BehaviorSubject` + `async` pipe

Solution C — `ChangeDetectorRef.markForCheck()`

5. `ChangeDetectorRef`

6. `NgZone` — running code outside Angular

2. `@Service()` — Angular 22+

5. `InjectionToken`

`useValue` — static value

`useClass` — substitute an implementation

`useFactory` — compute the value at runtime

`async` pipe

4. `hostDirectives` — applying a directive without an attribute

5. `effect()` — reacting to signal changes in the class

`untracked()` — reading a signal without tracking it

`toSignal()` — Observable → Signal

`toObservable()` — Signal → Observable

10. `input()`, `model()`, and `output()`

`input()` — read-only signal input (Angular 17.1+)

`model()` — writable signal for two-way binding (Angular 17.2+)

`output()` — decorator-free event emitter (Angular 17.3+)

`useState` vs `signal()`

`useMemo` vs `computed()`

`useEffect` vs `effect()`

Cleanup — `return` vs `onCleanup`

1. `FormsModule` and `ngSubmit`

2. Two-way binding with `[(ngModel)]`

Referencing the form with `NgForm`

Without `NgForm` — binding fields to component member variables

5. `@ViewChild` — querying a single element (decorator)

Example A — querying an `NgForm` directive instance

`@ViewChildren` — querying multiple elements