Angular / Basic / Lesson 1

Toolchain and the component model

Separate TypeScript checking, Angular template compilation, and browser execution, then describe a component with an explicit supported baseline.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Identify a component class, template, selector, and host.
Explain standalone imports and application bootstrap.
Distinguish verified local models from browser-dependent fragments.

Pin compatible tools instead of guessing the latest

This course uses Angular 20.3.0, TypeScript 5.9.3, RxJS 7.8.2, and Node.js 22.23.3 for isolated verification. The official compatibility table allows this combination. It is a pinned teaching baseline, not a claim that version 20 is the latest Angular. Use the versioned Angular 20 documentation for framework behavior and review support separately when choosing a real deployment version. Node runs build tools and local examples; a browser renders the application. TypeScript declarations describe APIs but do not install a DOM or make a Node process a browser.

A component joins behavior to a view

A component has a TypeScript class, Angular metadata, and a template that describes its view. A selector identifies where another template can use it, and Angular associates a component instance with a host element. Keep the class focused on a coherent feature rather than every page operation. The first complete TypeScript model verifies a simple presentation calculation without pretending to render a component. Such pure calculations are easy to test independently. A framework component additionally needs Angular compilation, dependency context, and a browser or supported rendering environment. These are distinct forms of evidence.

typescript A complete local presentation model

export {};
function courseTitle(name: string): string { return `Course: ${name}`; }
console.log(courseTitle("Angular"));

Expected output

Course: Angular

The program prints Course: Angular. It verifies string construction only and makes no claim about DOM rendering or Angular bootstrap.

Declare the component dependencies explicitly

The contextual component below uses explicit standalone: true for clarity at this baseline. Standalone components declare template dependencies in their imports array rather than requiring a declaring NgModule. They still need imported components, directives, and pipes when the template uses them. Plain HTML and interpolation need no additional feature import here. The class supplies the title property used by the template. The fragment is not a complete application: it needs application bootstrap and an HTML host. Its expected display is stated as a contextual observation, not fabricated browser-test evidence.

typescript Contextual standalone component definition

import { Component } from "@angular/core";
@Component({
  selector: "app-course-card",
  standalone: true,
  template: `<h1>{{ title }}</h1>`
})
export class CourseCard { title = "Angular foundations"; }

In a correctly bootstrapped host, the heading text would be Angular foundations. This fragment alone neither starts an application nor verifies a browser display.

Each build stage has a different responsibility

TypeScript checks ordinary class code, Angular compiles and checks template expressions, and the browser executes emitted code. A syntax transformer that removes types is not the full Angular compiler. A standalone application commonly bootstraps a root component through bootstrapApplication, with application providers supplied at that boundary. Keep routing, HTTP, and environment configuration visible instead of relying on an unexplained global setup. A generated workspace also contains package scripts and build configuration; preserve their versions when reproducing an error. The course does not launch development servers or modify a configured project to demonstrate these concepts.

Keep a reproducible component fixture

Record framework, compiler, runtime, package lock, bootstrap configuration, and the smallest template that reproduces a problem. An editor diagnostic and a successful local model do not prove that the application imports or template are correct. Use component naming, stable selectors, and small templates that make ownership clear. Keep synthetic data separate from credentials and production endpoints. Start by predicting the visible text and interaction, then test it in an isolated component environment when available. Report exactly whether code checking, template parsing, component execution, or browser behavior was performed; those checks should never be described as interchangeable.

Common errors and fixes

A selector is unknown in a consuming template.

Why it happens: The standalone component is missing from that component’s imports.
How to fix it: Import the intended component at the actual template owner.
Prevent it next time: Track template dependencies independently of TypeScript imports.

A Node model is described as a browser test.

Why it happens: Local computation was confused with rendering infrastructure.
How to fix it: State the actual verification level and add a component fixture.
Prevent it next time: Keep model, template, and browser checks distinct.

A project combines unsupported compiler versions.

Why it happens: Compatibility was assumed from independent latest packages.
How to fix it: Choose a combination in the official version table.
Prevent it next time: Pin and review toolchain changes together.

Check your understanding

1. Change the model input to Forms. Give its output and identify the extra evidence needed to claim the component heading changed.

Show worked solution

The model prints Course: Forms. To claim a component heading changed, update the component state or input, compile its actual template, and inspect the rendered heading in a suitable isolated fixture. Running the string function alone cannot verify imports, bootstrap, change detection, or DOM text. Keep both tests when the application depends on both contracts.

2. A component class checks successfully but its template uses a missing child component. Explain which stage should reveal the defect and the correct repair boundary.