Standalone components are Angular’s modern approach to building applications without NgModules. Introduced in Angular 14 and becoming the default in Angular 17+, they simplify the mental model and improve tree-shaking.If you have ever been confused about why you had to declare a component in one module, import that module into another module, and then export the component from the first module just to use it — standalone components are the answer. With the traditional NgModule system, the dependency graph lived in module files that were often hundreds of lines long and hard to reason about. Standalone components make each component self-describing: open the file, and the imports array tells you exactly what that component depends on. No more hunting through module files to figure out why something is or is not available.
The provide*() function pattern is how Angular’s own APIs are structured (provideRouter, provideHttpClient, etc.) and it is the recommended way to package your own application-wide configuration. Instead of scattering provider arrays across your codebase, you create a single function that encapsulates all the pieces a feature needs — services, tokens, initializers — and returns them as a unit.
Lazy loading was possible with NgModules, but it required wrapping components in a module just to make them lazy-loadable. With standalone components, any component can be lazy loaded directly via loadComponent. This is one of the biggest practical wins of the standalone architecture — you no longer need to create a module for the sole purpose of enabling lazy loading.
loadComponent vs loadChildren: Use loadComponent when you want to lazy-load a single component (a page, a dialog). Use loadChildren when you want to lazy-load an entire route tree with nested child routes. Both use the same dynamic import() mechanism under the hood.
┌─────────────────────────────────────────────────────────────────────────┐│ NgModule to Standalone Migration Strategy │├─────────────────────────────────────────────────────────────────────────┤│ ││ Phase 1: Prepare ││ ───────────────── ││ 1. Update to Angular 17+ ││ 2. Identify leaf components (no other components depend on them) ││ 3. Create migration plan (bottom-up approach) ││ ││ Phase 2: Convert Shared Module ││ ───────────────────────────── ││ 1. Mark all pipes, directives, components as standalone ││ 2. Update imports in each standalone item ││ 3. Export individual items instead of module ││ ││ Phase 3: Convert Feature Modules ││ ─────────────────────────────── ││ 1. Convert components bottom-up ││ 2. Replace module routing with route files ││ 3. Update lazy loading to loadComponent/loadChildren ││ ││ Phase 4: Remove AppModule ││ ────────────────────────── ││ 1. Move providers to bootstrapApplication ││ 2. Convert AppComponent to standalone ││ 3. Update main.ts to use bootstrapApplication ││ 4. Delete AppModule ││ │└─────────────────────────────────────────────────────────────────────────┘
Migration pitfall: The most common issue during NgModule-to-standalone migration is missing imports. In an NgModule world, a component might use NgIf without explicitly importing it because the parent module imported CommonModule. When you make that component standalone, you must add CommonModule (or the individual NgIf directive) to its own imports array. The automated migration schematic handles most cases, but always run your tests after each phase to catch what it misses.
// BEFORE: NgModule-based// shared.module.ts@NgModule({ declarations: [ ButtonComponent, CardComponent, HighlightDirective, TimeAgoPipe ], imports: [CommonModule], exports: [ ButtonComponent, CardComponent, HighlightDirective, TimeAgoPipe ]})export class SharedModule {}// AFTER: Standalone components// Each component is now self-contained:// button.component.ts@Component({ selector: 'app-button', standalone: true, imports: [CommonModule], template: `...`})export class ButtonComponent {}// card.component.ts@Component({ selector: 'app-card', standalone: true, imports: [CommonModule], template: `...`})export class CardComponent {}// Create an index for convenient imports// shared/index.tsexport { ButtonComponent } from './button/button.component';export { CardComponent } from './card/card.component';export { HighlightDirective } from './directives/highlight.directive';export { TimeAgoPipe } from './pipes/time-ago.pipe';// Optional: Create a convenience array for bulk imports.// This lets consuming components write `imports: [...SHARED_COMPONENTS]`// instead of listing each one individually. Use sparingly -- it defeats// tree-shaking if the array includes components the consumer does not use.export const SHARED_COMPONENTS = [ ButtonComponent, CardComponent] as const;export const SHARED_DIRECTIVES = [ HighlightDirective] as const;export const SHARED_PIPES = [ TimeAgoPipe] as const;
Should you use convenience arrays or individual imports? For small teams and small shared libraries, convenience arrays are fine — the tree-shaking impact is negligible. For published libraries or monorepos with many consumers, prefer individual imports so that unused components are eliminated from the bundle. The rule of thumb: if every consumer uses most of the shared components, arrays are convenient. If consumers cherry-pick one or two items, individual imports are better.
