Angular.

An Angular application is built from components, each a TypeScript class for the logic plus an HTML template for one part of the screen. Other blocks support them:

• Services hold logic not tied to a view. With dependency injection, Angular creates a service and passes it to each component that asks.
• Directives add behavior to DOM elements.
• Pipes transform data for display.
• Guards control navigation and access to routes.
• Interceptors read or change HTTP requests and responses.

NgModules can still group code, but components are standalone by default, so NgModules are optional.

TypeScript is a superset of JavaScript, so any JavaScript syntax is also legal TypeScript. It adds static typing, so the compiler checks types before the code runs.

Angular uses it because:

• Type errors appear at compile time instead of runtime.
• Editors use the types for autocomplete, refactoring and navigation.
• Interfaces and access modifiers build on classes and inheritance for object-oriented code.
• ES6 and later features compile down to older JavaScript.
• In a large codebase, a changed type flags every line that breaks.
• Error messages name the expected type, so debugging is faster.

The difference is who controls the flow. A library is a collection of functions that your code calls, so you decide when to use it. A framework provides the structure and calls your code, a principle called inversion of control.

Angular is a framework.

• Provides the application structure and architecture, and controls the flow through the component lifecycle.
• Its dependency injection manages object creation, so your code does not create its own dependencies.
• Ships built-in features such as routing, forms and an HTTP client.
• Expects your code to follow its conventions and patterns.

A component controls one part of the screen, called a view. It has four parts:

• A TypeScript class that holds the application logic.
• An HTML template that defines the view.
• CSS styles that define its appearance.
• Metadata from the @Component decorator, which tells Angular how to process the class.

To create one, run ng generate component example or write the class by hand.

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

@Component({
  selector: 'app-example',
  template: '<h1>{{title}}</h1>',
  styleUrls: ['./example.component.css']
})
export class ExampleComponent {
  title = 'Hello World';
}

The selector is the tag other templates use, here <app-example>. Components are standalone by default, so another component uses this one by adding ExampleComponent to its imports array.

The @Component decorator marks a class as an Angular component and attaches the metadata Angular uses to create and render it. Its options include:

• selector: the CSS selector that identifies the component in templates.
• template or templateUrl: the HTML, inline or in a separate file.
• styles or styleUrls: the component's CSS.
• imports: the components, directives and pipes its template uses.
• providers: services for the component, its children and projected content.
• viewProviders: services visible only inside its own view, hidden from projected content.
• encapsulation: whether the component's styles stay scoped to it.
• changeDetection: when Angular checks the component's view for changes.

template holds a component's HTML inline as a string inside the decorator, while templateUrl points to a separate HTML file.

@Component({
  selector: 'app-example',
  template: '<h1>{{title}}</h1><p>Inline template</p>'
})

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html'
})

Use template for simple, short templates, where the markup is easier to read next to the class. Use templateUrl for complex templates, because a separate file gets HTML syntax highlighting and keeps the class file organized.

The choice does not change how the app runs. The ahead-of-time (AOT) compiler inlines external templates into the JavaScript at build time.

Angular supports four types of data binding, and they differ in which way the data flows.

1. Interpolation shows a component value as text in the template. Data flows one way, from component to template.

<h1>{{title}}</h1>

1. Property binding sets a property of an element, such as src or disabled, from a component value. It also flows from component to template.

<img [src]="imageUrl">
<button [disabled]="isDisabled">

1. Event binding calls a component method when the template raises an event. Data flows one way, from template to component.

<button (click)="onClick()">Click me</button>

1. Two-way binding combines property and event binding, so a change on either side updates the other. Using it with ngModel needs FormsModule.

<input [(ngModel)]="username">

Both put component data into the template, but interpolation always converts the value to a string, while property binding passes the value with its type.

Interpolation uses double curly braces, {{ }}.

<h1>Welcome {{userName}}</h1>
<img src="{{imageUrl}}">

Property binding puts the element property in square brackets, such as [src].

<h1 [textContent]="userName"></h1>
<img [src]="imageUrl">

Inside an attribute, Angular treats interpolation as a property binding, so both img lines do the same thing. Use property binding for non-string properties, such as a boolean, a number or an object.

Neither syntax is more secure. Angular treats every bound value as untrusted, and it sanitizes and escapes values from template bindings and interpolation alike.

Event binding runs a component method when the user acts on an element, such as a click, a key press or a mouse movement. You write the event name in parentheses and the statement to run in quotes.

<button (click)="onClick()">Click me</button>
<input (keyup)="onKeyUp()">

To pass data, give the method $event, which holds the DOM event object. The handler can then read details such as the input's current value. You can also pass any template value, such as (click)="select(item)".

<input (keyup)="onKeyUp($event)">
<button (click)="onClick($event)">Click</button>

onKeyUp(event: any): void {
  console.log(event.target.value);
}

onClick(event: Event): void {
  console.log('Button clicked');
}

Directives are classes that add behavior to elements in Angular templates. There are three types:

1. Components are directives with their own template.
2. Structural directives change the DOM layout by adding or removing elements.
3. Attribute directives change the appearance or behavior of an element.

<!-- Structural Directives -->
<div *ngIf="condition">Content</div>
<li *ngFor="let item of items">{{item}}</li>

<!-- Attribute Directives -->
<div [ngClass]="cssClass">Content</div>
<div [ngStyle]="styleObject">Content</div>

NgIf and NgFor are deprecated since Angular 20, because the built-in @if and @for blocks now do their job. They still show how a structural directive works. For styling, the style guide prefers plain class and style bindings over ngClass and ngStyle.

ngIf and ngFor are structural directives, which add or remove elements in the DOM. ngSwitch is an attribute directive that works with the structural ngSwitchCase and ngSwitchDefault.

*ngIf includes or removes an element based on a condition, with an optional else template.

<div *ngIf="isVisible">This will show conditionally</div>
<div *ngIf="user; else noUser">Welcome {{user.name}}</div>
<ng-template #noUser>Please log in</ng-template>

*ngFor repeats an element for each item in a collection. index as i exposes the position. trackBy tells Angular how to match items when the list changes, so it can reuse their DOM elements.

<li *ngFor="let item of items; index as i; trackBy: trackByFn">
  {{i}}: {{item.name}}
</li>

ngSwitch displays one element out of several. You bind it as [ngSwitch] on a container. Each *ngSwitchCase child renders only when its value matches, and *ngSwitchDefault renders when none does.

<div [ngSwitch]="condition">
  <p *ngSwitchCase="'A'">Case A</p>
  <p *ngSwitchCase="'B'">Case B</p>
  <p *ngSwitchDefault>Default case</p>
</div>

All three have been deprecated since Angular 20 in favor of the built-in control flow blocks @if, @for and @switch. A @for block takes a track expression that identifies each item, so it can reuse views.

@if (user) {
  <div>Welcome {{user.name}}</div>
} @else {
  <p>Please log in</p>
}
@for (item of items; track item.id; let i = $index) {
  <li>{{i}}: {{item.name}}</li>
}

A service is a class with a specific purpose that provides functionality not tied to a view, so many components can share it. Use one for:

• Sharing data between components.
• Business logic that should not live in components.
• External communication, such as HTTP requests.
• Utility functions and helpers.
• State management.

import { Injectable } from '@angular/core';
@Injectable({
  providedIn: 'root'
})
export class DataService {
  private data: string[] = [];

  getData(): string[] {
    return this.data;
  }

  addData(item: string): void {
    this.data.push(item);
  }
}

providedIn: 'root' creates one shared instance for the whole app, and the build drops the service if nothing uses it. Components receive that instance through dependency injection. Newer Angular versions also offer @Service(), a shorter way to declare the same root-provided singleton.

A service declares what it needs, and Angular's injector supplies it. With constructor injection, you list the other service as a constructor parameter.

@Injectable({
  providedIn: 'root'
})
export class LoggerService {
  log(message: string): void {
    console.log(message);
  }
}

@Injectable({
  providedIn: 'root'
})
export class DataService {
  constructor(private logger: LoggerService) {}

  getData(): any[] {
    this.logger.log('Getting data...');
    return [];
  }
}

Angular reads the parameter type, finds the provider for LoggerService, and passes the instance in when it creates DataService. Both services are root-provided, so the whole app shares one logger.

The style guide now prefers the inject() function, which reads better when a class has many dependencies. You write private logger = inject(LoggerService); in a field initializer or call it in the constructor.

Avoid circular dependencies, where service A depends on service B and service B depends on A as well. Angular cannot create either one and throws an error.