How would you let consumers of an Angular data-table component supply their own cell template, and whose data and providers does that template see?

## The shape of the problem A reusable `data-table` component owns the rows, the sorting and the layout, but each consumer wants to decide how a particular cell looks: a status badge, a link, a formatted amount with an action button. Content projection with `<ng-content>` cannot do this on its own, because projected content is rendered once by the parent and cannot receive the current row. The idiomatic Angular answer is to let the consumer hand the table a **template**, and let the table **stamp it once per row** with that row as context. ## Step 1: define the contract as a context type ```ts export interface CellContext<T> { $implicit: T; // the row column: string; index: number; } ``` Putting the row under **`$implicit`** means the consumer can write `let-row` without naming a key. ## Step 2: accept a `TemplateRef` in the table There are two common ways to receive it: - a signal **input**: `cellTemplate = input<TemplateRef<CellContext<T>>>()`; the consumer passes `[cellTemplate]="statusCell"`; - a **content query** for a template the consumer places *inside* the table tag, usually marked with a small directive so several named templates can be told apart. Either way the table ends up holding a `TemplateRef`, not rendered DOM, so nothing in the consumer's template runs until the table decides to render it. ## Step 3: render it per row with `NgTemplateOutlet` ```ts @Component({ selector: 'app-data-table', imports: [NgTemplateOutlet], template: ` @for (row of rows(); track row.id; let i = $index) { <tr> <td> @if (cellTemplate(); as tpl) { <ng-container [ngTemplateOutlet]="tpl" [ngTemplateOutletContext]="{ $implicit: row, column: 'status', index: i }" /> } @else { {{ row.status }} } </td> </tr> } `, }) export class DataTable<T extends { id: string; status: string }> { rows = input.required<T[]>(); cellTemplate = input<TemplateRef<CellContext<T>>>(); } ``` The `@else` branch gives a **default rendering** when no template is supplied, which is how most table libraries behave. ## Step 4: what the consumer writes ```html <app-data-table [rows]="orders()" [cellTemplate]="statusCell" /> <ng-template #statusCell let-order let-i="index"> <span [class]="order.status">{{ order.status }}</span> <button (click)="cancel(order)">Cancel</button> </ng-template> ``` ## Whose data, whose providers This is the part interviewers probe, because it surprises people: 1. **Expressions resolve against the declaring component.** `cancel(order)` calls the *consumer's* `cancel` method, even though the button renders inside the table. The table's own properties are **not** visible to the fragment; only what it passes through the context is. 2. **Dependency injection resolves from the declaration site by default.** A component inside the fragment injects from the consumer's injector tree, not from the table's providers. Since v21.2, `NgTemplateOutlet` accepts `ngTemplateOutletInjector` set to the string `'outlet'` to make the embedded view inherit the injector at the outlet's location instead, or an explicit `Injector`. 3. **Change detection follows the declaration too.** When the consumer's view is refreshed, Angular marks the views stamped from its templates for refresh at their insertion points, so the cell updates even if the table itself is `OnPush` and received no new input. | Question | Answer for a stamped template | |---|---| | Which `this` do bindings use? | The component that declared `<ng-template>` | | What does the table contribute? | Only the context object | | Which injector by default? | The declaration site's | | Where does the DOM go? | Next to the outlet, inside the table | ## Why not plain content projection `<ng-content>` projects nodes the parent has **already rendered once**. It cannot be repeated per row, and the table cannot hand those nodes a row. A template is the opposite: a recipe the table can run as many times as it has rows, each time with a different context. That is why reusable table, list and tab components commonly accept templates rather than projected markup for per-item rendering. ## Design choices a senior should raise - **Type the context.** A `TemplateRef<CellContext<T>>` input lets strict template checking reject a wrongly shaped context object in the table's own template. - **Keep the context small and stable.** Pass the row and the few values the table owns; do not pass the whole table instance, which couples consumers to its internals. - **Offer defaults.** A table that renders nothing without a template is hard to adopt. - **Name the slots.** For several columns, a map of column name to `TemplateRef`, or a marker directive per column queried with a content query, scales better than one input per column.