View & Content Queries

## Two places a node can come from An Angular component sees nodes from two sources, and its queries are split the same way. - The **view** is the component's own template: whatever is written in its `template` or `templateUrl`. - The **content** is what a *parent* writes between the component's tags when it uses it, for example `<app-card><h2>Title</h2></app-card>`. The `<h2>` is declared in the parent's template. The card can render it through `<ng-content>`, but it does not own it. A **query** is a declaration on a component or directive class that asks Angular to find matching nodes and keep the results current. The locator is usually a component or directive class, a template reference variable name as a string, or a provider token. CSS selectors are not supported as locators. ## The four signal functions and their decorator twins | Looks in | One result | Many results | Decorator equivalents | |---|---|---|---| | the view (own template) | `viewChild()` | `viewChildren()` | `@ViewChild`, `@ViewChildren` | | the content (parent-supplied nodes) | `contentChild()` | `contentChildren()` | `@ContentChild`, `@ContentChildren` | The signal-based functions, imported from `@angular/core`, are the recommended form for new code in Angular 22.2 and have been public API since 19.0. The decorators remain fully supported and are what most existing codebases use. ## What the results look like - `viewChild()` and `contentChild()` return a `Signal` whose value is the first match, or `undefined` when nothing matches, for example because the element sits inside an `@if` that is false. - `viewChildren()` and `contentChildren()` return a `Signal` of a `ReadonlyArray`, empty when nothing matches. - `viewChild.required()` and `contentChild.required()` drop `undefined` from the type and throw a runtime error if read when there is no result. - The decorator forms instead assign plain properties: a single instance, or a `QueryList` for the plural decorators. Because signal query results are signals, you can use them in the template, in `computed()` and in `effect()`, and Angular keeps them current as `@if` and `@for` blocks add or remove matching nodes. ## The boundary rule **Queries never pierce component boundaries.** A view query sees only the component's template, not the templates of child components rendered in it. A content query sees only the nodes in the parent's template that sit inside this component's tags; it does not look into the templates of components used there. This keeps each template a black box to its ancestors. A useful consequence: if a card projects `<app-button>` supplied by its parent, the card finds it with `contentChild(Button)`, while the parent that wrote it could find the same button with its own `viewChild(Button)`, because to the parent it is part of its view. ## A side-by-side example ```ts import {Component, contentChild, viewChild, ElementRef} from '@angular/core'; @Component({selector: 'app-card-title', template: `<ng-content />`}) export class CardTitle {} @Component({ selector: 'app-card', template: ` <header #head><ng-content select="app-card-title" /></header> <section><ng-content /></section> `, }) export class Card { head = viewChild.required<ElementRef<HTMLElement>>('head'); // own template title = contentChild(CardTitle); // projected by the parent } ``` Used as `<app-card><app-card-title>Plan</app-card-title>...</app-card>`, `head` resolves to the `<header>` element and `title` to the `CardTitle` instance. `viewChild(CardTitle)` would stay `undefined`, because the title was declared in the parent's template. ## The same card with decorators In a codebase that predates signal queries, the card would read: - `@ViewChild('head') head!: ElementRef<HTMLElement>;` for the header element in its own template; - `@ContentChild(CardTitle) title?: CardTitle;` for the projected title. The split between view and content is identical. What changes is the shape of the result: a plain property that Angular assigns, rather than a signal you call. Because nothing notifies you when a decorator property is reassigned, older code reads these properties in lifecycle hooks, while signal queries can be read from a template or `computed()` and simply update. Either way, moving the title from the parent's markup into the card's own template would turn it from a content child into a view child, and the query would have to change with it. ## How interviewers use this question 1. They check that you can say where each query looks without mixing up "inside on screen" with "declared in my template". 2. They follow up on timing: content results exist before view results, which is why the decorator hooks come in the order `ngAfterContentInit` then `ngAfterViewInit`. 3. They probe the modern API: returning signals, the `.required` variants, and that the decorator forms still work. The exact moment results become available, and the options that change what a query returns, are separate questions; this one is about which template each family searches.