A complete modern Angular guide, from the CLI and components to signals, standalone APIs, SSR, state management, performance, testing, and production architecture.
The previous chapter covered standalone components, and this chapter covers the bootstrap that goes with them. Before the standalone API, every Angular application started with an NgModule — the AppModule — and the platformBrowserDynamic().bootstrapModule(AppModule) call. The standalone API replaced the root module with the bootstrapApplication function and the ApplicationConfig object, and it made the providers…
Change detection is the mechanism that keeps the DOM synchronized with the application’s state. Every time a user clicks a button, a timer fires, or a signal updates, Angular needs to know which parts of the view are stale and need to be re-rendered. The strategy that determines this is set per-component, and it is…
The previous chapter covered the two strategies — the Default (Eager) and the OnPush. This chapter covers the tools that give the developer direct control over the change detection: the ChangeDetectorRef‘s methods, the signal-driven change detection, the effect‘s scheduling, the markForCheck‘s mechanics, the detectChanges‘s and the ApplicationRef.tick()‘s manual invocations, the NgZone‘s and the runOutsideAngular‘s, the…
The previous chapter covered the developer-facing tools for change detection: the ChangeDetectorRef, the signals, and the markForCheck(). This chapter goes underneath those tools to the machinery that drives them. For most of Angular’s history, that machinery has been Zone.js — a library that patches the browser’s asynchronous APIs and tells Angular when something might have…
Zone.js has been the engine of Angular’s change detection for most of the framework’s life. It works by monkey-patching nearly every asynchronous API in the browser, and when the microtask queue empties, it fires a change detection cycle. That approach made Angular’s “just mutate a property and the view updates” ergonomics possible, but it came…
Angular’s animation system gives you programmatic control over how elements transition between states. Unlike pure CSS animations, the @angular/animations package lets you define animations directly in component metadata, coordinate parent-child animations, trigger changes based on data state, and hook into lifecycle callbacks when motion starts and finishes. The package provides a complete state-machine model: you…
In the previous chapter, you learned the foundational building blocks of Angular animations: triggers, states, transitions, and the enter/leave lifecycle. Those primitives handle single elements with simple state changes. Real applications, however, need far more: cascading lists that animate in sequence, parent-child animations that coordinate without blocking, and seamless transitions between routed views. This chapter…
Static templates work beautifully until the component you need to render isn’t known until runtime. A dashboard widget, a modal dialog configured by a service, or an ad banner that cycles through different layouts — these scenarios demand that Angular create components on the fly, after the application has already booted. Angular provides two primary…
Content projection is how Angular lets a parent component pass markup into a child component, and the child decides where that markup appears in its own template. It is the mechanism behind every reusable card, modal, tab, and layout component you have ever used. Without it, a component like <app-card> would be a black box…
Angular components rarely live in isolation. A parent component often needs to reach into its own template and grab a reference to a child element, a directive instance, or a component. It may also need to inspect or manipulate content that a caller has projected into it via <ng-content>. Angular’s query system provides four tools…