React is deliberately a library: it renders UI, and everything else — routing, forms, HTTP, state management — is a separate choice (React Router, Zustand, fetch/React Query, all covered as add-ons across the React course). Angular is a full framework: routing, forms, dependency injection, and an HTTP client are all built in from day one, with one official, opinionated way to do each. It's also written in and built around TypeScript — JavaScript with optional type annotations — rather than plain JavaScript.

Just Enough TypeScript to Get Started

: type annotations are the core addition — declaring what a variable, parameter, or return value is allowed to be, checked while writing code rather than only discovered when it crashes at runtime. An interface describes the shape an object must have; greet's parameter being typed as Person means passing an object missing name or age is flagged immediately by the editor, before the code ever runs. Classes already exist in plain JavaScript (JS Intermediate Chapter 3) — TypeScript just lets a class's properties and methods carry the same type annotations.

Installing the Angular CLI and Creating a Project

ng new my-app asks a few setup questions (routing, stylesheet format) and scaffolds a complete starter project — Angular's CLI does considerably more for you upfront than Vite's React template did. ng serve starts a local dev server (usually http://localhost:4200) with live reload, the same role npm run dev played throughout the React course.

A Generated Project's Anatomy

• src/main.ts — the entry point; bootstraps the root component into the page.
• src/app/app.component.ts — the root component's logic (a TypeScript class).
• src/app/app.component.html — that same component's template (its markup) — Angular keeps logic and markup in separate files by default, unlike JSX combining both.
• src/app/app.component.css — styles scoped to just this component.
• src/app/app.component.spec.ts — a test file, generated automatically alongside every component (covered properly in Chapter 14).

A First Component

@Component({...}) is a decorator — metadata attached to the class right above it, telling Angular how to treat GreetingComponent: selector is the HTML tag name (<app-greeting>) used to place it elsewhere, and templateUrl points to its separate HTML file. {{ name }} in the template is interpolation — Angular's equivalent of JSX's {name}, inserting the class property's current value directly into the rendered output.

Coding Challenges

Chapter 1's GreetingComponent used a separate template file. This chapter covers the rest of a component's anatomy — inline templates and styles as an alternative, how Angular keeps one component's CSS from leaking into another's, and nesting components together to build an actual page, the direct equivalent of composing JSX components in React (Fundamentals Chapter 9).

Inline Template and Styles

template (a backtick string, allowing multiple lines) and styles (an array of strings) are direct alternatives to templateUrl/styleUrl — fine for a small enough component that separate files would be overkill. Larger components generally still use separate .html/.css files, which most editors syntax-highlight more usefully than a string embedded in TypeScript.

Style Encapsulation — Styles Don't Leak Between Components

Both components use a class called .box, with completely different styling — and both render correctly, with no collision. By default, Angular scopes each component's styles so they only ever apply to that component's own template, achieved by attaching unique generated attributes behind the scenes. This is functionally similar to what CSS Modules or styled-components give a React project deliberately — Angular does it automatically, with no extra setup, for every component.

Composing Components Together

Every standalone component used inside another's template must be listed in that component's own imports array — the explicit step Chapter 1's third challenge already required. <app-header></app-header> and <app-footer></app-footer> in the template then place those components exactly where written, the same nesting idea as composing <Header /> and <Footer /> in a React JSX tree.

Coding Challenges

Interpolation ({{ value }}, Chapter 2) only inserts text content. Angular has three more binding forms covering everything else — setting a DOM property directly, responding to events, and the special case of keeping a form field and a class property in sync automatically.

Property Binding — [property]="expression"

Square brackets around an attribute name — [disabled], [src] — bind that DOM property directly to a class property or expression, evaluated as real TypeScript/JavaScript rather than treated as a plain string. [disabled]="isSaving" sets the button's actual disabled property to whatever isSaving currently is (a real boolean) — the same underlying need as React's curly-brace rule for non-string prop values (Fundamentals Chapter 2), just expressed with brackets instead.

Event Binding — (event)="handler()"

Parentheses around an event name — (click) — call the given expression whenever that event fires, the direct equivalent of React's onClick={handler}. increment() is a regular method on the class; this.count++ updates the property directly — there's no separate setter function the way useState requires, since Angular's change detection automatically re-renders the template after any event handler runs.

Accessing the Event Object — $event

$event is a special template variable holding the actual DOM event object — passing it explicitly to the handler is the same idea as React's automatic event-object argument (Fundamentals Chapter 4), just opted into rather than implicit. The as HTMLInputElement cast is TypeScript-specific: event.target is typed generically as EventTarget, so accessing its .value property requires telling the compiler exactly what kind of element it actually is.

Two-Way Binding — [(ngModel)]

[(ngModel)]="name" — sometimes called "banana in a box," combining property binding's square brackets with event binding's parentheses — keeps the input's value and the name property synchronized automatically in both directions: typing updates name, and changing name elsewhere in code updates the input. This is the same end result as React's controlled input pattern (value + onChange, Fundamentals Chapter 7), collapsed into one directive instead of two explicit bindings.

Class and Style Bindings

[class.active] toggles a single CSS class on or off based on a boolean expression, and [style.color] binds one specific inline style property directly — the same conditional-styling need React handles with a template literal or object passed to className/style (Fundamentals Chapter 5).

Coding Challenges

React handles conditionals and lists with plain JavaScript embedded in JSX — ternaries, &&, and .map() (Fundamentals Chapters 5 and 6). Angular instead provides directives: special attributes recognized by the template compiler that add, remove, or repeat elements. This chapter covers the modern built-in control-flow syntax (@if, @for) plus the attribute directives for classes and styles.

@if — Conditional Rendering

The @if block (introduced in Angular 17 as the modern built-in control flow) renders its contents only when the condition is true, with an optional @else block — the direct equivalent of React's ternary or &&, but reading more like the if/else statement it actually is. Unlike React's conditional rendering, which keeps the element in the JSX expression, @if genuinely adds or removes the element from the DOM entirely based on the condition.

@for — Rendering a List

@for repeats its block once per array item — the equivalent of React's .map(). The track item.id clause is required, and serves exactly the same purpose as React's key prop (Fundamentals Chapter 6): it tells Angular how to identify each item across re-renders so it can update the DOM efficiently when the list changes, rather than rebuilding everything. Where React's key is optional-but-warned, Angular's track is mandatory.

@empty and the Loop Variables

An optional @empty block renders when the array has no items — neatly handling the "empty list" case that React's Todo project (Project 1) had to write as a separate conditional. Inside a @for, contextual variables like $index, $first, $last, and $even are also available for free — {{ $index }} gives the current item's position, for instance.

@switch — Multiple Cases

@switch handles three-or-more named cases cleanly — the same job React's lookup-object pattern did (Fundamentals Chapter 5), expressed as template-level branching. This is a natural fit for the loading/error/success status pattern that ran throughout the React projects.

ngClass and ngStyle — Multiple Classes or Styles at Once

Chapter 3's [class.active] toggles one class; [ngClass] takes an object toggling several at once, each key a class name and each value a boolean deciding whether it applies. [ngStyle] does the same for multiple inline styles. Both require NgClass/NgStyle (or CommonModule) in the component's imports — unlike the new @ control-flow blocks, these attribute directives still need importing.

Coding Challenges

React passes data down through props and back up by passing functions down as props (Fundamentals Chapters 2 and 4). Angular splits these into two explicit, separately-named mechanisms: @Input for data flowing into a child, and @Output (with an EventEmitter) for events flowing out of a child back to its parent.

@Input — Passing Data Into a Child

The @Input() decorator marks a property as one the parent is allowed to set — the equivalent of declaring a prop in React. The parent passes it using property binding from Chapter 3: [name]="'Philip'". Note the binding evaluates as an expression, so a literal string needs inner quotes ("'Philip'"), whereas [age]="35" passes a real number — the same string-vs-expression distinction as React's quotes-vs-curly-braces rule for props.

@Output and EventEmitter — Emitting an Event Up

An @Output() property is an EventEmitter — the child calls .emit(value) on it to send data upward, and the parent listens with event binding (parentheses) exactly like a DOM event: (deleted)="onDelete($event)", where $event holds whatever value was emitted. This is the structural equivalent of React's "pass a function down, child calls it" pattern (Project 1's todo delete), but Angular models it as a custom event the child raises rather than a callback function it receives. The <number> on EventEmitter<number> is a TypeScript generic, declaring the type of value this event carries.

A Two-Way Binding Output Convention

If a component has an @Input() called value and an @Output() called valueChange (the input name plus Change), Angular lets a parent use the same [(banana-in-a-box)] two-way syntax from Chapter 3 on it — [(value)]="something". This is exactly how the built-in [(ngModel)] works under the hood, and it's the standard way to build a custom component that supports two-way binding, rather than anything special baked into the framework.

Coding Challenges

The React course needed Context (Intermediate Chapter 2) and eventually Zustand/Redux (Advanced Chapter 1) to share state across distant components without prop drilling. Angular has a single, built-in answer baked into the framework from the start: a service — an ordinary class holding shared logic or state — combined with dependency injection (DI), which hands that service to any component that asks for it. This is arguably Angular's defining feature.

A Service Is Just a Class

The @Injectable({ providedIn: 'root' }) decorator marks this class as something Angular's DI system can provide, and 'root' means a single shared instance exists for the entire app — every component that asks for CounterService gets that same one instance, making it a natural place to hold shared state. (A service can also be provided at a narrower scope, but app-wide 'root' is the common default.)

Injecting a Service Into a Component

inject(CounterService) asks Angular's DI system for the service — the component never creates it with new CounterService() itself. That distinction is the whole point of dependency injection: the component declares what it needs, and the framework supplies it, automatically handing over the same shared 'root' instance. Any other component injecting CounterService shares the exact same count, with no props, no Context provider, and nothing passed between them.

Why This Replaces Prop Drilling and Context

In React, sharing one piece of state between a header badge and a distant cart page required lifting state up and then either prop drilling or wrapping the tree in a Context provider (the exact journey the Shopping Cart project took). In Angular, both components simply inject() the same service — there's no provider to wrap anything in, no value object to memoize (Intermediate Chapter 7's concern), and no tree structure that the shared state has to flow through. The service exists independently of the component tree entirely.

Services for Logic, Not Just State

A service doesn't have to hold state — it's equally the home for shared behavior: logging, formatting, calculations, and (most importantly) talking to a backend API, which the HTTP client chapter builds on directly. Keeping that logic in an injectable service rather than inside components is a core Angular convention: components handle the view, services handle everything else.

Coding Challenges

In React, formatting a value for display means calling a function in the JSX — {formatPrice(amount)}, {date.toLocaleDateString()}. Angular has a dedicated template feature for this: a pipe, applied with the | symbol, transforming a value purely for display while leaving the original data untouched. Several common transformations ship built in, and writing custom ones is straightforward.

Built-in Pipes

A pipe takes the value on its left and transforms it for display. Arguments come after a colon — currency:'EUR' sets the currency code, date:'fullDate' picks a format. The original name, price, and today properties are never modified; only what appears on screen is transformed. The json pipe is especially handy while learning — it's the quickest way to dump an object's contents into the template to see its shape.

Chaining Pipes

Multiple pipes can be chained with successive | symbols, each receiving the output of the one before it — applied left to right, the same direction as reading. Here uppercase runs first, then slice takes the first three characters of the result.

Writing a Custom Pipe

A custom pipe is a class implementing PipeTransform — a single transform(value, ...args) method returning the transformed result. The @Pipe decorator's name is what's used in the template (| truncate), and any extra parameters after the value become the pipe's arguments (truncate:50 passes 50 as limit). It's a standalone pipe, imported into a component's imports array exactly like a standalone component.

The async Pipe — A Preview

One built-in pipe deserves a special mention now: async. It subscribes to an Observable (or Promise) and renders its latest emitted value, automatically — directly addressing the async-state limitation flagged in Chapter 6's warning. It comes into its own with the HTTP client and RxJS in Chapter 11, but it's worth recognizing here as a pipe, since that's exactly what it is.

Coding Challenges

Angular has two distinct, official approaches to forms — template-driven (this chapter) and reactive (next chapter). Template-driven forms keep most of the form's setup in the HTML template itself, built on the ngModel two-way binding from Chapter 3. They're the quicker option for simpler forms, and the closer fit to how React's controlled inputs felt.

The Setup — ngForm and ngModel Together

Three pieces work together here. #signupForm="ngForm" is a template reference variable — it captures the form's auto-created NgForm object, giving access to its overall validity (signupForm.invalid). (ngSubmit) fires the handler on submit, already preventing the native page reload that React needed preventDefault() for (Fundamentals Chapter 4). Each [(ngModel)] input needs a name attribute so the form can track it as a named control.

Validation Through Directives

Validation is declared as plain attributes on the inputs — required, email, minlength, maxlength, pattern. Angular wires these standard-looking HTML attributes into its own validation system, tracking each control's validity and the overall form's. [disabled]="signupForm.invalid" then disables the submit button until every validator passes — declarative validation with no JavaScript validation code written at all.

Showing Validation Messages

A per-input reference variable — #email="ngModel" — captures that single control's state, exposing flags like invalid, valid, touched (the user has focused then left it), and dirty (the value has changed). Combining invalid && touched with the @if from Chapter 4 shows an error message only after the user has actually interacted with the field — not immediately on an untouched, empty form.

Coding Challenges

Template-driven forms (Chapter 8) put the form's structure in the HTML, with Angular inferring the model behind the scenes. Reactive forms invert that: the form is defined explicitly in the component class as an object you build and control directly, with the template just connecting to it. More setup, but the form becomes a real, inspectable, programmatically-controllable object — the better fit for complex forms, dynamic fields, and custom validation.

Building a FormGroup

A FormGroup is the whole form; each field is a FormControl with its initial value and an array of validators. Crucially, this entire structure is a plain object in the class — readable and writable from code. The validators come from Validators (required, email, minLength(8), pattern(...)) rather than being template attributes, and uses ReactiveFormsModule instead of FormsModule.

Connecting the Template

[formGroup]="loginForm" binds the template's form to the object built in the class, and each input declares which control it represents with formControlName="email". Notice there's no [(ngModel)] anywhere — the form object is the single source of truth, and the inputs simply attach to its existing controls by name. loginForm.invalid works exactly as before for the submit button.

FormBuilder — Less Boilerplate

FormBuilder — injected as a service (Chapter 6) — is a shorthand for building the same structure with less new FormGroup/new FormControl repetition: each field becomes a terse [initialValue, validators] array. It produces an identical FormGroup; it's purely the more concise and conventional way to write one, and what most real reactive-forms code uses.

Reacting to Value Changes

Every control (and the form itself) exposes a valueChanges Observable that emits each time its value changes — the core reason these are called reactive forms. This is what makes things like live-filtering, dependent fields, or debounced validation natural, in a way template-driven forms can't match cleanly. Observables are covered properly in Chapter 11; this is a first glimpse of why reactive forms unlock so much.

Programmatic Control

Because the form is a real object, it can be manipulated from code — setValue/patchValue to fill it (e.g. loading an existing record into an edit form), reset() to clear it. This programmatic control is the practical payoff of reactive forms, and the main reason they're preferred for anything beyond a simple contact form.

Coding Challenges

Routing was a separate library install in React (React Router, Intermediate Chapter 5). In Angular it's part of the framework — the same single-page navigation concepts apply directly, just with Angular's own API. This chapter covers defining routes, linking and navigating, reading URL parameters, and protecting routes with guards.

Defining Routes

Routes are an array of objects mapping a path to a component — the direct equivalent of React Router's <Route> elements. :id marks a dynamic segment (matching /product/anything), and '**' is the catch-all for any unmatched URL — both familiar from React Router, just expressed as data rather than JSX. This array is wired into the app's configuration once, in main.ts, via provideRouter(routes).

RouterOutlet and RouterLink

<router-outlet> is the placeholder where the matched route's component renders — the equivalent of React Router's <Outlet /> (or the <Routes> block itself). routerLink="/about" navigates without a full page reload, exactly like React's <Link to> — and the same warning applies: a plain <a href> would trigger a real reload and defeat the point.

Reading Route Parameters

ActivatedRoute — injected like any service (Chapter 6) — exposes the current route's parameters. snapshot.paramMap.get('id') reads the :id segment from the URL, the equivalent of React Router's useParams(). The snapshot form is the simplest; for a route that the same component stays on while only the parameter changes, subscribing to route.paramMap (an Observable, Chapter 11) reacts to those changes — but snapshot suffices for most cases.

Programmatic Navigation

Injecting the Router service gives navigate([...]) for navigating from code — after a form submits, a login succeeds, an action completes — the equivalent of React Router's useNavigate(). The path is passed as an array of segments, which Angular joins into the URL.

Route Guards — Protecting a Route

A guard is a function that runs before a route activates, returning true to allow it or redirecting otherwise — there's no built-in equivalent in React Router itself (it's typically hand-rolled with a wrapper component). Added to a route via canActivate: [authGuard], this is the standard way to keep an unauthenticated user out of a protected page, redirecting them to login instead. Guards inject services freely, since they run inside Angular's DI context.

Coding Challenges

React used fetch returning a Promise, awaited in a useEffect (Intermediate Chapter 6). Angular's HttpClient instead returns an Observable — a stream of values from RxJS, the reactive library Angular is built on. The same Observable already appeared as valueChanges (Chapter 9) and route.paramMap (Chapter 10); this chapter covers it properly, alongside the HTTP client that produces them most often.

Observable vs Promise — The Core Difference

A Promise resolves once with a single value. An Observable is a stream that can emit many values over time (or just one, like an HTTP response) — and crucially, it does nothing at all until something subscribes to it. Where await kicks off a Promise immediately, an Observable is lazy: no subscription, no work. That laziness is what makes operators like cancellation, retrying, and debouncing possible in ways Promises can't match.

Setting Up HttpClient

provideHttpClient() registers the HTTP client with Angular's DI system once, the same pattern as provideRouter (Chapter 10). After that, any service can inject HttpClient and make requests.

An API Call Inside a Service

Per the Chapter 6 convention, API calls live in a service, not a component. http.get<User[]>(url) returns an Observable<User[]> — the <User[]> generic tells TypeScript what shape the response data will be, giving full type safety on the result. Note the service just returns the Observable without subscribing; the component decides when to do that.

Consuming It — Subscribe, or the async Pipe

The async pipe (Chapter 7) subscribes to the Observable, hands its emitted value to the template, and — critically — unsubscribes automatically when the component is destroyed. This is the preferred approach: it avoids manual subscription bookkeeping entirely, and the ; as users syntax captures the emitted array into a template variable to loop over. The naming convention users$ (trailing $) marks a property as an Observable at a glance.

RxJS Operators with pipe()

An Observable's .pipe(...) applies operators — functions that transform the stream — much like chaining array methods, but for values arriving over time. map transforms each emitted value (here filtering the user list), and catchError handles failures, returning a fallback Observable (of([]) emits a single empty array). This is RxJS's equivalent of the try/catch error handling from React's Intermediate Chapter 6, expressed as a pipeline.

Coding Challenges

React's useEffect (Fundamentals Chapter 8) collapsed "run on mount," "run on update," and "clean up on unmount" into one hook differentiated by its dependency array. Angular splits these into separate, explicitly-named lifecycle hook methods — each a method with a fixed name that Angular calls at a specific moment. A component opts into one by implementing the matching interface and writing the method.

ngOnInit — Setup After Creation

ngOnInit runs once, right after Angular has created the component and set its initial @Input values — the standard place for setup work like an initial data fetch (used already in Chapter 11). It's the direct equivalent of React's useEffect(() => {...}, []) with an empty dependency array. Implementing OnInit isn't strictly required for the method to run, but doing so lets TypeScript catch a misspelled ngOnInit — strongly recommended.

Why Not the Constructor?

A natural question: why not just do setup in the class constructor? The constructor runs when the object is first created, before Angular has finished wiring it up — specifically before @Input properties have their values. Putting data fetching or any logic depending on inputs in ngOnInit guarantees those inputs are ready. The convention: the constructor is for dependency injection only (or just use inject()); ngOnInit is for actual initialization logic.

ngOnChanges — Responding to Input Changes

ngOnChanges runs whenever an @Input value changes (and once initially, before ngOnInit) — the rough equivalent of useEffect with a specific prop in its dependency array. The SimpleChanges argument is an object keyed by which inputs changed, each entry holding previousValue and currentValue — useful when a component needs to react to which input changed and by how much, like recomputing a chart only when its data prop actually changes.

ngOnDestroy — Cleanup Before Removal

ngOnDestroy runs just before Angular removes the component — the place for cleanup, exactly mirroring the cleanup function returned from a React useEffect. This is where the manual subscriptions flagged in Chapter 11's warning get unsubscribed, timers cleared, and listeners removed. The same rule from React applies: anything that "starts" something ongoing needs a matching "stop" here, or it leaks.

Coding Challenges

This whole course has quietly used the modern direction already — every component has been standalone: true, and Chapters 10–11 used provideRouter/provideHttpClient rather than the older module setup. This chapter names those choices explicitly, then introduces signals — Angular's newer reactivity primitive, the closest thing in Angular to React's useState.

Standalone Components, Recapped

Historically, Angular grouped components into NgModules — separate files declaring which components, directives, and pipes belonged together and what they could use. Standalone components (now the default) drop that layer: each component declares its own imports directly, as seen in every example so far. The result is less boilerplate, no app.module.ts to maintain, and an import list that lives right next to the component using it.

Signals — A Reactive Value

signal(0) creates a reactive value holding 0. Reading it is a function call — count(), both in the template and in code. Writing is done with .set(value) (a new value) or .update(fn) (based on the current one) — directly parallel to React's setCount(5) and setCount(n => n + 1). When a signal changes, Angular knows precisely which parts of the template depend on it and updates only those, more surgically than the older change-detection mechanism.

computed — Derived Signals

computed derives a new signal from others — its value automatically recalculates whenever any signal it reads changes, and (importantly) is cached until then, so it only recomputes when genuinely needed. This is the signals version of React's useMemo (Intermediate Chapter 7), but the dependency tracking is automatic: there's no dependency array to maintain — Angular knows total depends on price and quantity simply because it read them.

effect — Reacting to Signal Changes

effect runs a side effect whenever any signal it reads changes — automatically tracked, the same way computed works. It's the rough equivalent of React's useEffect with the relevant value in its dependency array, again with no manual dependency list. Effects are for genuine side effects (logging, syncing to localStorage); deriving a value should use computed instead.

Why Signals Matter

Signals are Angular's strategic direction for reactivity — gradually offering a simpler, more explicit, and more performant alternative to the change-detection-plus-RxJS model that came before. They don't replace RxJS (Observables are still the right tool for streams of events and HTTP, Chapter 11), but for component-local state, signals are increasingly the recommended default. Inputs can even be signals now (input() instead of @Input()), and the async pipe has a signal counterpart in toSignal() — the ecosystem is steadily building around them.

Coding Challenges

Every ng generate component has quietly created a .spec.ts file alongside each component (Chapter 1) — those are tests, and this chapter finally puts them to use. Angular's testing stack uses Jasmine (the test framework: describe/it/expect) run by Karma (the test runner, executing tests in a real browser), with TestBed as Angular's own utility for creating components in a test environment.

A Test for a Service — The Simplest Case

describe groups related tests; it defines one; beforeEach runs before each test for fresh setup; expect(...).toBe(...) asserts. TestBed.inject(CounterService) retrieves the service through the same DI system the real app uses (Chapter 6), rather than constructing it manually — so the test exercises it exactly as it'd be used in practice.

Testing a Component with TestBed

TestBed.createComponent returns a fixture — a handle to the live component plus its rendered DOM (fixture.nativeElement). The key Angular-specific detail is fixture.detectChanges(): unlike React Testing Library, which re-renders automatically, an Angular test must explicitly trigger change detection to render the initial view and to update it after a state change. Forgetting it is the most common reason an Angular test sees stale, un-updated DOM.

Mocking a Dependency

Dependency injection makes testing easier: a component asks for UserService, and the test simply provides a fake one instead via { provide: UserService, useValue: fakeUserService }. The component is none the wiser — it gets whatever DI supplies. This means a component can be tested in isolation, with a fake service returning fixed data, without ever hitting a real API — the same goal as React's mock functions (Advanced Chapter 4), achieved through DI rather than passing mocks as props.

Running the Tests

ng test runs the whole suite, opening a browser Karma controls to execute the tests in, and re-running automatically as files change — the equivalent of a test runner's watch mode. The default starter project already passes its one generated AppComponent test, so ng test works from the very first ng new.

Coding Challenges