How Angular Components Work: The Angular 22 Runtime In short: Every time you use a component, Angular creates three things — a host element, a class instance, and a view. Understanding those three is what lets you reason about a bug instead of guessing at it. Look at any large web application and it can feel overwhelming. Imagine building an entire dispatch dashboard as one thousand-line file. Updating it would be miserable. Testing it would be impossible. Angular's answer is to build screens out of small, independent blocks called components . Before we learn to share those blocks across applications, we need to know exactly what Angular does when it meets one. The blueprint and the reality You are building a dashboard that tracks daily milk collection across regional centres. You need a summary card for each centre. Rather than writing the same markup ten times, you write one blueprint. Two things to notice before we go on, because both are recent: There is no . Standalone is the default from Angular v20 onward. Angular's own best-practices guide is blunt about it: you must not set it inside the decorator. There is no . In Angular 22, is the default. Writing it explicitly is noise. When you drop into a template, Angular creates three distinct things: 1. The host element — an actual tag in the browser. Think of it as the plot of land your centre is built on. 2. The component instance — a live object built from your class. This is the local manager. Ten centres on screen means ten independent managers. If the North centre updates its litre count, the South centre is untouched. 3. The view — the rendered template inside the host element. The text, buttons, and colours the user actually touches. That isolation is the payoff. You get self-contained pieces of UI without wiring anything up yourself. The family tree Components sit inside other components, which automatically produces a tree. This tree is the chain of command. If fetches the daily totals, it passes them down to the individual centres. When a user clicks "Dispatch Truck" in a child, the event travels up so a parent can act on it. The practical benefit shows up during debugging. When the South region's menu closes unexpectedly, you do not search the whole codebase. You look at one branch. Packing your own toolbelt A component declares what it needs in its own array: By listing and , the component says: to render this card I need a status badge and a way to format currency. Any developer can open one file and see the full dependency list. No hunting through a module three directories up. "But I thought OnPush was an optimisation you turn on later" That belief was correct for years, and it is exactly why it is worth dismantling now. In older Angular, the default was : after almost any event anywhere in the app, Angular walked the entire component tree and re-checked every binding. It worked, and it was forgiving — you could mutate an object in place and the screen still updated. was the opt-in for teams who had measured a performance problem. In Angular 22, is what you get by default. That changes the contract. An component is re-checked when one of a small number of things happens: a signal it reads changes, an input reference changes, an event fires from its own template, or an async pipe it uses emits. Here is the bug this causes if you carry the old habit forward: The signal's value is the same array it already held, so nothing is notified and the card keeps showing 4500. Under the old default this often appeared to work, because something else on the page triggered a full re-check a moment later. The rule this leaves you with: treat state as replaced, never edited. Angular's own guidance says the same thing from the other direction — do not reach for on a signal; use or . What this costs and buys A realistic dispatch dashboard: 1 header, 1 region list, 40 centre cards, each with a badge and three metric rows — roughly 250 component instances. A manager types one character into a search box. Old default ( ) Angular 22 default ( ) --- --- --- Components checked per keystroke 250 3 (search box, list, host) Bindings evaluated 1,900 24 Mutating an object in place works Usually, by accident No — and it should not Extra code needed to get this on 250 components None You get the fast path for free. The price is that you have to be honest about when your data changed. Recap Components are blueprints. Each use creates a host element, a class instance, and a view. Applications are trees. The hierarchy decides how data flows down and events flow up, and it is where you start when hunting a bug. is the toolbelt. A standalone component declares its own dependencies — and you never write , because it is the default. is the default in Angular 22. Angular re-checks a component when a signal it reads changes, an input reference changes, or its own template fires an event. Replace state, do not edit it. and with fresh objects; never mutate in place. Next, the quest…