Angular: Dynamic Component Loading

WHY IT EXISTS: Static HTML templates are rigid. They define a fixed structure at compile time. Dynamic component loading solves the problem of building UIs where parts of the view are unknown until runtime, such as a dashboard with user-configurable widgets or a CMS rendering a page from an array of different content blocks.

THE MENTAL MODEL: Imagine your template has a designated, empty placeholder. Dynamic loading lets you get a programmatic handle to this placeholder and then, on command, create a new component instance and insert it there. You are manually performing the steps that Angular's compiler usually does automatically when it finds a component selector in a template.

HOW IT WORKS: First, you define an anchor point in a template, typically an <ng-container> with a template reference variable, like <ng-container #dynamicHost></ng-container>. In your component class, you get access to this anchor using @ViewChild('dynamicHost', { read: ViewContainerRef }). The ViewContainerRef is the programmatic handle to that placeholder. To add a component, you call viewContainerRef.createComponent(MyDynamicComponent). This returns a ComponentRef, which represents the live instance of the component. You can use this reference to pass data to its inputs or subscribe to its outputs. Crucially, you must call componentRef.destroy() when the component is no longer needed to remove it from the DOM and avoid memory leaks. This is often done in the ngOnDestroy lifecycle hook of the host component.

WHEN TO USE IT: Use this for highly dynamic UIs. Three common cases are: first, building a dashboard where users can add, remove, and reorder different widgets; second, creating a generic modal service that can display any component inside a dialog box; third, rendering pages from a JSON structure, where each object in the JSON maps to a different component type.

WHEN NOT TO USE IT: Do not use it for simple conditional rendering; @if (or ngIf) is far simpler and more efficient. Don't use it for rendering a list of the *same component; @for (or *ngFor) is the correct tool for that. It adds complexity, so avoid it unless the content is truly determined at runtime and cannot be handled declaratively.

ONE CANONICAL EXAMPLE: A tabbed interface where each tab's content is a different, complex component. When a user clicks a new tab, the host component clears its ViewContainerRef (destroying the old component) and then creates and injects the component corresponding to the newly selected tab.