NgModules & Modular Architecture
5 questions found
What is an NgModule in Angular, and what was its traditional purpose?
Beginner
An NgModule is a class decorated with the NgModule decorator that groups together related components, directives, pipes, and services, declaring what belongs together and what that group of code depends on. Traditionally, every Angular app needed at least one root NgModule to bootstrap the application.
@NgModule({
declarations: [AppComponent, HeaderComponent],
imports: [BrowserModule, FormsModule],
bootstrap: [AppComponent]
})
export class AppModule {}
Real-world example
An older Angular project organizes its feature specific components, like everything related to orders, into a dedicated OrdersModule, keeping that feature's pieces logically grouped together in one place.
Common follow-ups: Why has the recommended approach shifted away from NgModules toward standalone components?;Can NgModules and standalone components be used together in the same project?
Standalone Components;Components & Templates
What is a feature module, and how does it help organize a larger Angular application?
Intermediate
A feature module groups together everything related to one specific area of functionality, such as an orders feature or a user settings feature, keeping that area's components, services, and routing logically separated from unrelated parts of the app, making the overall codebase easier to navigate and maintain.
@NgModule({
declarations: [OrderListComponent, OrderDetailComponent],
imports: [CommonModule, RouterModule.forChild(orderRoutes)]
})
export class OrdersModule {}
Real-world example
A large e commerce application organizes all order related components and routing logic into a dedicated OrdersModule, making it clear at a glance exactly which files belong to that specific feature area.
Common follow-ups: How does a feature module differ from simply organizing files into folders without an actual NgModule?;How would this same organizational goal be achieved using standalone components instead?
Performance & Lazy Loading;Standalone Components
How do you lazy load a feature module so its code is only downloaded when a user actually navigates to it?
Intermediate
You configure the router to load a module using loadChildren with a dynamic import statement, rather than directly importing and declaring the module upfront, telling Angular to only download that module's code the first time a user visits a route belonging to it.
const routes: Routes = [
{ path: 'orders', loadChildren: () => import('./orders/orders.module').then(m => m.OrdersModule) }
];
Real-world example
A large admin panel only downloads the code for its rarely visited reports section the first time a user actually navigates there, thanks to lazy loading that specific feature module instead of including it in the app's initial bundle.
Common follow-ups: How does lazy loading a module differ from lazy loading an individual standalone component?;What is a good rule of thumb for deciding which feature areas are worth lazy loading?
Performance & Lazy Loading;Routing
Why has Angular moved toward standalone components as the recommended default over NgModules?
Advanced
Standalone components remove a significant amount of boilerplate, since each component explicitly declares its own dependencies directly rather than needing to be registered inside a separate NgModule. This simplifies the mental model for new developers, reduces the files needed for a typical feature, and makes tree shaking unused code easier for Angular's build tools.
// Standalone component, no separate NgModule needed at all
@Component({
selector: 'app-order-list',
standalone: true,
imports: [CommonModule, RouterLink],
template: `<a [routerLink]="['/orders', order.id]">{{ order.name }}</a>`
})
export class OrderListComponent {
@Input() order!: Order;
}
Real-world example
A team building a brand new Angular app skips creating any NgModules entirely, using only standalone components throughout, resulting in noticeably fewer files and less boilerplate compared to how the same app would have been structured a few years earlier.
Common follow-ups: Is it necessary to migrate an existing large NgModule based app to standalone components right away?;What migration tools does Angular provide to help convert an existing app to standalone components?
Standalone Components;Angular Schematics & Custom Builders
What is the SharedModule pattern, and is it still relevant with standalone components?
Beginner
A SharedModule traditionally grouped together commonly reused components, directives, and pipes that many different feature modules needed, avoiding the need to import each one individually everywhere. With standalone components, this same idea is often achieved more simply by just importing the specific standalone pieces directly wherever they are actually needed.
// Traditional SharedModule pattern
@NgModule({
declarations: [ButtonComponent, LoadingSpinnerComponent],
exports: [ButtonComponent, LoadingSpinnerComponent]
})
export class SharedModule {}
// With standalone components, simply import what you need directly
@Component({ standalone: true, imports: [ButtonComponent, LoadingSpinnerComponent] })
Real-world example
An older Angular project keeps a SharedModule bundling their common button and spinner components together, while a newer project built with standalone components simply imports those exact same reusable components directly wherever they are needed.
Common follow-ups: Does the standalone approach reduce unnecessary code being included in a final bundle compared to a SharedModule?;How would you migrate an existing SharedModule's contents to standalone components?
Standalone Components;Angular Style Guide & Best Practices