Angular Components, Modules, and Services: A Complete Developer Guide

Angular components (@Component) control UI sections using templates and TypeScript. Angular modules (@NgModule) group related code into functional blocks. Angular services (@Injectable) hold shared business logic accessed via dependency injection. Since Angular 17, standalone components are the default, making NgModule optional for most new apps.

Angular is one of the most widely used frameworks for building enterprise-grade web applications, and its power comes from three interconnected building blocks: components, modules, and services. Understanding how each one works, what it is responsible for, and how they connect to each other is the foundation of writing Angular code that is clean, scalable, and easy to maintain over time. Whether you are building a single feature or architecting an application with hundreds of screens, these three concepts govern everything Angular does.

This guide explains Angular components, Angular modules, and Angular services in precise technical terms, with real code examples for each. It also covers the shift that Angular 17 introduced by making standalone components the default architecture, what that means for NgModule going forward, and how to structure your Angular applications using modern best practices that work well in both small projects and large production codebases.

Angular Components: The Building Blocks of Every UI

What Is an Angular Component?

An Angular component is a TypeScript class decorated with @Component that controls a specific part of the user interface. Every visible element in an Angular application, whether it is a navigation bar, a product card, a login form, or a data table, is managed by a component. Angular components consist of three parts that always work together:

Template: the HTML that defines what the component renders on screen.
Class: the TypeScript file that holds the component’s data, methods, and logic.
Styles: the CSS or SCSS rules that apply exclusively to this component’s template.

Here is a minimal Angular component that displays a product name:

import { Component } from '@angular/core';

@Component({
selector: 'app-product-card',
standalone: true,
template: `
<div class="card">
<h2>{{ productName }}</h2>
<p>{{ productPrice | currency }}</p>
<button (click)="addToCart()">Add to Cart</button>
</div>
`,
styles: [`
.card { border: 1px solid #ddd; padding: 16px; border-radius: 8px; }
`]
})
export class ProductCardComponent {
productName = 'Wireless Headphones';
productPrice = 79.99;

addToCart() {
console.log(`${this.productName} added to cart`);
}
}

Notice standalone: true in the decorator. Since Angular 17, standalone is the default and recommended approach for new components. It means the component does not need to be declared inside a NgModule to be used.

Angular Component Lifecycle Hooks

Angular components go through a predictable sequence of lifecycle events from creation to destruction. Angular provides lifecycle hook interfaces that let you run code at specific moments in this sequence. The most commonly used hooks are:

• ngOnInit: runs once after Angular has set all the component’s input properties. This is where you load initial data, subscribe to observables, or call a service to fetch API data.
• ngOnChanges: runs whenever an @Input property value changes. Useful for reacting to parent-component updates.
• ngOnDestroy: runs just before Angular destroys the component. Use this to unsubscribe from observables and clean up timers to prevent memory leaks.
• ngAfterViewInit: runs once after Angular has fully initialized the component’s view, including its child components. Useful when you need to interact with DOM elements via ViewChild.

import { Component, OnInit, OnDestroy, Input, OnChanges, SimpleChanges } from '@angular/core';
import { Subscription } from 'rxjs';
import { ProductService } from './product.service';

@Component({
selector: 'app-product-list',
standalone: true,
templateUrl: './product-list.component.html'
})
export class ProductListComponent implements OnInit, OnChanges, OnDestroy {
@Input() categoryId!: string;
products: any[] = [];
private subscription!: Subscription;

constructor(private productService: ProductService) {}

ngOnInit(): void {
this.loadProducts();
}

ngOnChanges(changes: SimpleChanges): void {
if (changes['categoryId'] && !changes['categoryId'].firstChange) {
this.loadProducts(); // reload when category changes
}

Component Communication: @Input and @Output

Angular components frequently need to share data with each other. The two primary mechanisms for parent-to-child and child-to-parent communication are @Input and @Output decorators.

@Input allows a parent component to pass data down to a child component. @Output allows a child component to emit events that the parent can listen to and respond to.

// Child component
@Component({
selector: 'app-item',
standalone: true,
template: `
<div>
<span>{{ label }}</span>
<button (click)="select.emit(label)">Select</button>
</div>
`
})
export class ItemComponent {
@Input() label!: string;
@Output() select = new EventEmitter<string>();
}

// Parent component template
// <app-item [label]="item.name" (select)="onItemSelected($event)" />

Best Practice: Keep components focused on a single responsibility. If a component is managing both UI display and data fetching, split it: one presentational component handles the template and another container component handles data. This separation makes both components easier to test and reuse.

Angular Modules (NgModule): Organizing Your Application

What Is an Angular Module?

An Angular module is a class decorated with @NgModule that groups related components, directives, pipes, and services into a cohesive unit. Every Angular application has at least one module, the AppModule, which serves as the root and bootstraps the application. Additional feature modules organize the app into manageable sections.

Here is a complete feature module for a user authentication section:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { ReactiveFormsModule } from '@angular/forms';
import { RouterModule } from '@angular/router';

import { LoginComponent } from './login/login.component';
import { RegisterComponent } from './register/register.component';
import { AuthService } from './auth.service';

@NgModule({
declarations: [
LoginComponent,
RegisterComponent
],
imports: [
CommonModule,
ReactiveFormsModule,
RouterModule.forChild([
{ path: 'login', component: LoginComponent },
{ path: 'register', component: RegisterComponent }
])
],
providers: [AuthService]
})
export class AuthModule {}

Types of Angular Modules

• Root Module (AppModule): the entry point of your application. It bootstraps the root component and imports core Angular modules like BrowserModule and AppRoutingModule.
• Feature Modules: organize related functionality into self-contained blocks. Examples include UserModule, ProductModule, or AdminModule. Feature modules can be eagerly loaded at startup or lazily loaded on demand.
• Shared Modules: export commonly used components, directives, and pipes so that multiple feature modules can import them without duplicating declarations.
• Core Module: typically imported once in AppModule. It provides singleton services and exports common utilities that the app needs globally, such as an authentication interceptor or an HTTP error handler.

Lazy Loading with Angular Modules

One of the most important performance benefits of Angular modules is lazy loading. When you configure a route to use loadChildren instead of component, Angular only loads that module’s code when the user navigates to that route. This reduces the initial bundle size and speeds up the first page load.

// app-routing.module.ts
const routes: Routes = [
{
path: 'products',
loadChildren: () =>
import('./products/products.module').then(m => m.ProductsModule)
},
{
path: 'admin',
loadChildren: () =>
import('./admin/admin.module').then(m => m.AdminModule)
}
];

Standalone Components vs NgModule: What Changed in Angular 17

Angular 17 made standalone components, directives, and pipes the default when generating new code using the Angular CLI. This is one of the most significant architectural shifts in Angular’s history, and understanding what it means for NgModule is essential for any developer working with modern Angular.

What Are Standalone Components?

// Modern standalone approach (Angular 17+ default)
import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { ProductCardComponent } from '../product-card/product-card.component';

@Component({
selector: 'app-product-list',
standalone: true,
imports: [CommonModule, RouterModule, ProductCardComponent],
templateUrl: './product-list.component.html'
})
export class ProductListComponent {
// component logic here
}

A standalone component manages its own imports directly in the @Component decorator instead of relying on a module’s declarations array. This eliminates a layer of indirection and makes each component fully self-contained.

With standalone components, lazy loading also works directly on the component rather than requiring a module wrapper:

// Lazy loading a standalone component directly
const routes: Routes = [
{
path: 'products',
loadComponent: () =>
import('./products/product-list.component').then(m => m.ProductListComponent)
}
];

Should You Use Standalone Components or NgModule?

• New projects: use standalone components as the default. The Angular CLI generates standalone components by default since Angular 17, and Angular’s own documentation recommends this approach for new applications.
• Existing projects with NgModule: no immediate Angular migration is required. NgModule is still fully supported and is not being removed from Angular. You can migrate incrementally by making individual components standalone one at a time.
• Library authors: NgModule continues to be the standard for distributing Angular libraries, as it provides a clear public API surface for consumers of the library.

Key Difference

NgModule requires you to declare every component in a module before it can be used. Standalone components declare their own dependencies inside @Component. Standalone reduces boilerplate significantly in large apps and makes it clear exactly what each component depends on without opening a separate module file.

Angular Services: Shared Logic and Data Management

What Is an Angular Service?

An Angular service is a TypeScript class decorated with @Injectable that holds business logic, data access functions, state management, or utilities that multiple components need to use. Services keep components lean by moving data-fetching, transformation, and shared state out of the component class itself.

Here is a ProductService that fetches data from an API and provides it to components across the application:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, BehaviorSubject } from 'rxjs';
import { tap, catchError } from 'rxjs/operators';

@Injectable({
providedIn: 'root' // singleton available throughout the app
})
export class ProductService {
private apiUrl = 'https://api.example.com/products';
private productsSubject = new BehaviorSubject<any[]>([]);
products$ = this.productsSubject.asObservable();

constructor(private http: HttpClient) {}

getAll(): Observable<any[]> {
return this.http.get<any[]>(this.apiUrl).pipe(
tap(products => this.productsSubject.next(products)),
catchError(err => {
console.error('Failed to load products', err);
throw err;
})
);
}

getByCategory(categoryId: string): Observable<any[]> {
return this.http.get<any[]>(`${this.apiUrl}?category=${categoryId}`);
}

getById(id: number): Observable<any> {
return this.http.get<any>(`${this.apiUrl}/${id}`);
}
}

Dependency Injection in Angular

Angular’s dependency injection system (DI) is what makes services available to components without the component needing to instantiate them manually. When you list a service in a component’s constructor, Angular’s injector looks up the registered service and provides the existing instance automatically.

@Component({
selector: 'app-product-list',
standalone: true,
imports: [CommonModule],
template: `
<ul>
<li *ngFor="let p of products">{{ p.name }}</li>
</ul>
`
})
export class ProductListComponent implements OnInit {
products: any[] = [];

// Angular injects ProductService automatically
constructor(private productService: ProductService) {}

ngOnInit(): void {
this.productService.getAll().subscribe(data => this.products = data);
}
}

Service Scope and Provider Levels

Where you provide a service determines how many instances of it exist in the application. There are three main scopes:

• Root level (providedIn: ‘root’): Angular creates one singleton instance shared by the entire application. This is the standard choice for data services, authentication, and application-wide state.
• Module level (providers array in @NgModule): Angular creates a separate instance for each feature module that provides the service. Use this when different parts of the app need isolated service instances.
• Component level (providers array in @Component): Angular creates a new instance for each component instance and its children. This is useful when you need a fresh service state for each rendered component, such as a form-step wizard where each step manages its own state.

Angular Component vs Module vs Service: Side-by-Side Comparison

The table below summarizes the key technical differences between the three core Angular building blocks to help you quickly decide which one applies to a given situation.

// The flow in a standalone Angular 17+ app:

// 1. Route configuration loads the component lazily
{ path: 'products', loadComponent: () =>
import('./product-list.component').then(c => c.ProductListComponent) }

// 2. Component injects the service and fetches data on init
@Component({ standalone: true, ... })
export class ProductListComponent implements OnInit {
constructor(private productService: ProductService) {}
ngOnInit() { this.productService.getAll().subscribe(...); }
}

// 3. Service performs the actual HTTP request
@Injectable({ providedIn: 'root' })
export class ProductService {
getAll(): Observable<Product[]> {
return this.http.get<Product[]>('/api/products');
}
}