Lesson 3 of 30

Standalone Components

Q: What problem do standalone components actually solve compared to the old NgModule-based approach, and what's the real tradeoff?

A strong answer covers: Explains the old NgModule model: dependencies declared/exported centrally in a module file, not where they're used; Explains standalone's fix: each component declares its own dependencies locally via the imports array on @Component; Names the resulting tradeoff honestly — smaller, more local errors when something's missing from imports, versus module-wide confusing failures before; Mentions that NgModules and standalone components can coexist/interop during migration, not an all-or-nothing rewrite.

A standalone component declares its own dependencies right there in the decorator — no NgModule required. This has been the default since Angular v17, and it changes how you read every component.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Standalone Components

What interviewers actually ask about this, and what a strong answer has to cover.

What problem do standalone components actually solve compared to the old NgModule-based approach, and what's the real tradeoff?

A strong answer covers

Explains the old NgModule model: dependencies declared/exported centrally in a module file, not where they're used
Explains standalone's fix: each component declares its own dependencies locally via the imports array on @Component
Names the resulting tradeoff honestly — smaller, more local errors when something's missing from imports, versus module-wide confusing failures before
Mentions that NgModules and standalone components can coexist/interop during migration, not an all-or-nothing rewrite

Likely follow-ups

If standalone components declare dependencies locally, doesn't that mean more repetition across components that all need the same handful of imports? How would you deal with that in a real codebase?
Walk me through what bootstrapApplication does differently with a standalone root component compared to the old platformBrowserDynamic().bootstrapModule() approach.
You called this similar to how React imports components. Is that comparison exact, or does Angular's imports array do something React's import statements don't?

The plain-language idea

For most of Angular's history, every component had to belong to an NgModule — a separate file whose job was declaring which components existed, which other modules' features they could use (CommonModule for *ngIf, FormsModule for ngModel, and so on), and which components were exported for use elsewhere. To use a directive, you didn't import it where you used it — you imported the module that declared it, somewhere else entirely, and hoped someone had remembered to add it.

Standalone components remove that indirection. A component lists exactly what it needs — other components, directives, pipes — in an imports array on its own @Component decorator. No module file, no separate declarations list, no hunting through the app to figure out why a directive isn't working. This has been the default for new components since Angular v17, and as of today it's simply how you build an Angular app; NgModules still exist and you'll run into them in older codebases, but they're legacy structure now, not the thing to reach for.

See it in a real thing: a component that imports what it uses

// product-card.component.ts
import { Component, input } from '@angular/core';
import { RouterLink } from '@angular/router';
import { NgOptimizedImage } from '@angular/common';
import { PriceTagComponent } from '../price-tag/price-tag.component';

@Component({
  selector: 'app-product-card',
  standalone: true,
  imports: [RouterLink, NgOptimizedImage, PriceTagComponent],
  template: `
    <a [routerLink]="['/products', product().id]">
      <img [ngSrc]="product().imageUrl" width="240" height="240" alt={{ product().name }} />
      <h3>{{ product().name }}</h3>
      <app-price-tag [amount]="product().price" />
    </a>
  `,
})
export class ProductCardComponent {
  product = input.required<{ id: string; name: string; imageUrl: string; price: number }>();
}

Read the imports array and you know exactly what this template can use: routerLink because RouterLink is imported, ngSrc because NgOptimizedImage is imported, <app-price-tag> because PriceTagComponent is imported directly — a component importing another component, the way you'd import anything else. There's no module file anywhere that secretly makes RouterLink available; if you deleted it from this array, the template would fail to compile with a clear "unknown property" error pointing right at this file.

And bootstrapping reflects the same shift — from the CLI lesson, bootstrapApplication(AppComponent, appConfig) takes a standalone component directly, no root AppModule wrapping it.

What people usually miss

Watch out

"Standalone" doesn't mean "has no dependencies." It means dependencies are declared locally, per component, in that component's own imports array — rather than globally, in a shared NgModule. A standalone component can still import a dozen things; it just says so, right there.
You can mix standalone and NgModule-based code during a migration. Angular supports interop — a standalone component can be used inside an NgModule-based app and vice versa. You don't have to rewrite an entire legacy app in one pass to start using standalone components in new features.
Forgetting an import is still a real failure mode — it's just smaller now. In the NgModule era, forgetting to import a module could break things app-wide or in confusing, distant ways. Now, forgetting RouterLink in one component's imports array only breaks that one component's template — worse locally-visible errors, but a much smaller blast radius to debug.

The genealogy: this is Angular converging on a React-shaped idea

React developers already do this without thinking about it: import Button from './Button' at the top of the file that uses it, nowhere else. Standalone components are Angular arriving at the same idea — a component's dependency list lives with the component, not in some separate registration file you have to go find. The component-anatomy lesson picks up right where this one leaves off, looking at everything else the @Component decorator controls.