All topics
Componentsintermediate

ContentChild and ContentChildren

Explain how @ContentChild and @ContentChildren access projected content rather than a component's own template.

While @ViewChild looks inside a component's own template, @ContentChild and @ContentChildren look at content that was projected into the component from its parent via ng-content — the markup that lives between a component's opening and closing tags when it's used. This distinction is one of the most commonly confused pairs in Angular interviews, and clearly separating "my own template" from "content given to me by my consumer" is exactly what demonstrates real understanding.

A wedding planner (the component) doesn't just manage their own equipment (view children) — they also need a headcount of the guests the couple invited (content children) before the ceremony can properly begin.

Key Concepts

1
Because projected content is compiled against the parent's context, @ContentChild gives the component a way to still inspect or interact with what was handed to it — for example, a TabsComponent might use @ContentChildren(TabComponent) to gather all <app-tab> elements a consumer placed inside it, so it can coordinate which one is active.
@ContentChildTabsComponent@ContentChildren(TabComponent)<app-tab>
2
The timing rule mirrors view queries but fires earlier: content children are available by ngAfterContentInit, since projected content is resolved before the component's own view finishes initializing. Mixing this up — expecting a @ContentChild in ngOnInit — is a classic bug.
ngAfterContentInit@ContentChildngOnInit
3
Just like view queries, @ContentChildren returns a QueryList with a .changes Observable, which matters for components like a tab group or accordion where the set of projected children can change dynamically as the consumer adds or removes items.
@ContentChildrenQueryList.changes