DEV Community: Manish Boge

OOP Applied in Angular: From Theory to Practice

Manish Boge — Sun, 08 Feb 2026 17:19:41 +0000

Beyond the Basics: Building Scalable Angular Architecture

In Part 1: OOP Fundamentals, we explored Object-Oriented Programming (OOP) as a design mindset, not just a set of keywords. We looked at how Abstraction, Encapsulation, Inheritance, Polymorphism, and Composition help software survive change over time using TypeScript as Programming Language.

In this part , we bring those ideas to life by applying them directly to Angular applications.

Angular is deeply aligned with OOP principles — especially when you design your architecture intentionally.

Today, we move past “basic classes” and look at how to use modern Angular features to enforce professional design patterns.

Let us dive in.

Why OOP Matters in Angular Applications

Angular applications don’t stay small for long. As features multiply and teams grow, codebases naturally move toward entropy. Without strong design boundaries, you end up with:

God Services: Single files managing 5,000 lines of unrelated logic.
Leaky State: Components reaching into services to mutate data directly.
Fragile Hierarchies: Deep inheritance trees where a change in the base class breaks ten children.

So OOP helps Angular apps by:

Isolating responsibilities
Protecting state
Enforcing contracts
Enabling extensibility through DI

OOP isn’t about writing more code; it’s about isolating responsibilities.

Let us now understand applying OOP principles one by one in Angular.

1. Abstraction: Contracts Over Concretes

The Concept

Abstraction in Angular means depending on contracts, not concrete implementations.

In simple terms, Abstraction means depending on what a service does, not how it does it.

In Angular, abstraction is most commonly achieved using:

Interfaces
Abstract classes
Dependency Injection (DI)

The Problem: Tightly Coupled Services

Many developers try to use TypeScript interfaces for DI. However, interfaces are kind of "ghosts"—they disappear at compile-time , leaving Angular with no runtime token to inject.

In TypeScript, Interfaces are metadata. They are used for type-checking during development but are completely stripped away (erased) during the transpilation process to JavaScript.

@Injectable()
export class OrderService {
  placeOrder(amount: number) {
    console.log('Paying via GooglePay');
  }
}

Issues:

Business logic depends on a concrete payment provider
Hard to replace or mock
Hard to test

The Solution: Abstract the Behavior

export interface PaymentGateway {
  charge(amount: number): void;
}

@Injectable()
export class GooglePay implements PaymentGateway {
  charge(amount: number): void {
    console.log('Charging via GooglePay');
  }
}

@Injectable()
export class OrderService {
  constructor(private paymentGateway: PaymentGateway) {}

  placeOrder(amount: number) {
    this.paymentGateway.charge(amount);
  }
}

Angular DI Wiring

providers: [
  { provide: PaymentGateway, useClass: GooglePay}
]

Wait … Here we made a mistake. The above code throws error at RunTime.

It will not find the token for the provider PaymentGateway.

But Why? — We have defined an interface right. Yes. But there is a problem with interface that we defined.

Let us understand more about it and solve this issue.

The Problem: In TypeScript, Interfaces are metadata. They are used for type-checking during development but are completely stripped away (erased) during the transpilation process to JavaScript.

The Result: When Angular’s Dependency Injection (DI) engine tries to run your code in the browser, it looks for a token named PaymentGateway. Because it was an interface, that token does not exist in the JavaScript bundle.

Angular will throw a NullInjectorError or an error stating it cannot find a provider for PaymentGateway.

Solution: Using Abstract Classes

Unlike interfaces, abstract classes exist in the JavaScript runtime and can serve as unique DI tokens.

So, we define an abstract class. It acts as both the interface (contract) and the runtime DI token. Derived classes can extend it.

// 1. Use an Abstract Class instead of an Interface
export abstract class PaymentGateway {
  abstract charge(amount: number): void;
}

@Injectable({ providedIn: 'root' })
export class GooglePay extends PaymentGateway { // Use 'extends'
  charge(amount: number): void {
    console.log('Charging via GooglePay');
  }
}

@Injectable({ providedIn: 'root' })
export class OrderService {
  // 2. Modern Angular 'inject' function is preferred over constructor injection
  private paymentGateway = inject(PaymentGateway);

  placeOrder(amount: number) {
    this.paymentGateway.charge(amount);
  }
}

// 3. DI Wiring (in AppModule or AppConfig)
// Now PaymentGateway is a valid runtime token!
providers: [
  { provide: PaymentGateway, useClass: GooglePay }
]

What we achieved:

OrderService depends on what a payment gateway does
Not how it does it
Switching providers requires zero business logic change

Abstraction defines capability , not the implementation.

Interface vs Abstract Classes

We are extending the PaymentGateway. B ut isn’t extends bad ? Like if we change PaymentGateway class, will it not force child classes to change ?

Let us understand these aspects to clear the difference between abstract class with and a standard class in the context of inheritance.

When you use a standard class inheritance, you are inheriting behavior (code).

When you use an abstract class with abstract methods, you are only inheriting a contract.

Does it force children to change?

If you add a new abstract method to the PaymentGateway base class, yes , every child (GooglePay, Stripe, PayPal) class will “ break” and force you to implement that method.

However, this is actually a good thing. Abstraction is a contract. If your “Payment” contract changes to require a refund() method, we want the compiler to tell us that GooglePay is now missing that capability. It prevents runtime errors where the OrderService tries to call a method that doesn't exist.

Why not just use an interface?

An interface is the purest form of a contract. But as we discussed, TypeScript interfaces don't exist in JavaScript. If we strictly want to avoid the extends keyword but still want the safety of DI, you use an InjectionToken.

No worries — we will cover more about Injection Token in another article.

2. Encapsulation: Protecting State

The Concept

Encapsulation protects an object’s internal state and ensures rules are enforced.

In Angular, encapsulation applies strongly to:

Services
State management logic
Domain models

The Problem: Leaky State

@Injectable()
export class CartService {
  products: Product[] = [];
}

this.cartService.products.push({ price: -100 }); // Invalid state

Nothing prevents misuse. Any componet which consumes CartService can modify the *products * array.

The Solution: Encapsulated State

@Injectable()
export class CartService {
  private items: CartItem[] = [];

  addItem(item: CartItem) {
    if (item.price <= 0) {
      throw new Error('Invalid price');
    }
    this.items.push(item);
  }

  getItems(): readonly CartItem[] {
    return this.items;
  }
}

Why This Matters in Angular

Prevents accidental mutations
Enforces business rules centrally
Makes debugging predictable

Encapsulation keeps Angular apps stable under change.

3. Inheritance in Angular (Use Carefully)

The Concept

Inheritance models an Is-A relationship.

Angular supports inheritance well but it’s also where many designs go wrong.

Let us understand now.

Valid Use Case: Base Components

export abstract class BaseComponent {
  isLoading = false;
  protected startLoading() {
    this.isLoading = true;
  }
  protected stopLoading() {
    this.isLoading = false;
  }
}

@Component({ /* ... */ })
export class UserComponent extends BaseComponent {
  loadUsers() {
    this.startLoading();
  }
}

When Inheritance Hurts

Deep component hierarchies
Hidden side effects
Tight coupling to base class changes

Inheritance increases coupling — hence hard to manage the derived calss in accordance with base class changes.

Rule of Thumb:

Use inheritance only when the relationship is undeniably Is-A_._

4. Polymorphism in Angular

The Concept

Polymorphism allows different implementations to be used interchangeably.

Angular’s DI system is a polymorphism engine.

The Problem: Conditional Services

Let us understand a scenario where we need to use the Console for logs in development mode only.

if (env === 'dev') {
  this.logger.logToConsole();
} else {
  this.logger.logToServer();
}

If more environments like stage, uat , qa then it will be:

Hard to modify and read
Easy to break
We loose code extendability

The Polymorphic Solution

We create a contract Logger . Implement the Contract based on the requirement.

export abstract class Logger {
  abstract log(message: string): void;
}

@Injectable()
export class ConsoleLogger extends Logger {
  log(message: string) {
    console.log(message);
  }
}

@Injectable()
export class ServerLogger extends Logger {
  log(message: string) {
    // send to API
  }
}

Environment-Based Injection

providers: [
  {
    provide: Logger,
    useClass: environment.production ? ServerLogger : ConsoleLogger
  }
]

Result:

No conditionals
Behavior changes at runtime
Open for extension, closed for modification

Polymorphism eliminates branching logic.

Abstraction + Polymorphism in Angular DI

// Service
@Injectable()
export class ConsoleLogger implements Logger {
  log(message: string) {
    console.log(message);
  }
}

// In a component
constructor(private logger: Logger) {}

Logger → Abstraction
ConsoleLogger / ServerLogger → Polymorphism

Angular resolves the concrete class at runtime.

5. Composition Over Inheritance in Angular

The Problem with Inheritance-Based Reuse

export class LoggingComponent {
  log(msg: string) {}
}

export class OrderComponent extends LoggingComponent {}

Components now inherit behavior they may not always need.

Solution: Composition with Services

@Injectable()
export class LoggerService {
  log(message: string) {
    console.log(message);
  }
}

@Component({ /* ... */ })
export class OrderComponent {
  constructor(private logger: LoggerService) {} // You can use inject function as well.

  createOrder() {
    this.logger.log('Order created');
  }
}

Why Angular Loves Composition

DI makes composition effortless
Services are swappable
Testing becomes trivial

Composition creates horizontal flexibility .

Mapping OOP Principles to Angular Concepts

Abstraction → Interfaces, DI Tokens
Encapsulation → Services, Private State
Inheritance → Base Components / Classes
Polymorphism → Dependency Injection
Composition → Service Injection

Angular is not anti-OOP it’s OOP done pragmatically.

Summary

OOP in Angular is not about classes. It’s about designing systems that evolve safely.

Depend on abstractions to keep your services swappable.
Protect state aggressively using access modifiers.
Prefer composition over deep inheritance trees.

Check List:

What You Should Do Next

Refactor one fat component using services
Replace conditionals with polymorphic providers
Use abstract classes over interfaces

Once you start seeing OOP in Angular, you can’t unsee it.

Source Code & Resources

If you’d like to dive deeper or try the examples yourself, all source code including those discussed in this series is available on my GitHub repository: Oop-Applied-Angular

Don’t forget to give this Repository a star ⭐ — not only does it help you stay updated when code changes, but it also shows appreciation for the content and motivates continued development.

Beyond Classes: The OOP Fundamentals Every Developer Must Know

Manish Boge — Thu, 22 Jan 2026 04:32:58 +0000

Moving beyond syntax: A design-first guide to the four pillars of OOP in TypeScript

OOP Fundamentals

Object-Oriented Programming (OOP) is more than a set of keywords; it is a strategy for managing software complexity. While most developers can define its pillars, a few apply them to build systems that survive change over time.

This guide explores the four pillars of OOP — and the essential rule of Composition — as architectural solutions to real-world problems.

We’ll use TypeScript programming language as code examples for clarity, but the ideas apply to any programming language or framework that you work with.

This is Part 1/2 of the series.

In Part 2, we will focus on applying these concepts in Angular applications.

So, let’s understand the essentials of OOP.

Why Do We Need Object-Oriented Programming?

The real-world problem in software engineering is complexity over time. Software fails when it becomes too tangled to change.

OOP addresses this by:

Isolating changes: Fix a bug in one place without breaking the whole system.
Reducing side effects: Preventing data corruption through controlled access.
Modeling intent: Mapping code logic directly to business requirements.

OOP is not about writing classes.

It’s about designing code that can change safely.

The Four Pillars of OOP

Abstraction, Encapsulation, Inheritance, and Polymorphism.

1. Abstraction

The Concept: Abstraction is about focusing on what an object does instead of how it does it. It provides a simple “interface” to a complex internal process.

The Problem: You shouldn’t need to understand bank API protocols just to process a payment.

The Solution: Create a “contract” (Interface) that hides the internal details.

Abstraction exposes intent while hiding complexity.

Let’s see the code examples

Without Abstraction:

class Order {

  processOrder(amount: number) {
    console.log("Connecting to payment gateway...");
    console.log(`Charging ${amount} via Razorpay`);
  }

}

Problems with above code:

Business logic depends on payment details
Switching payment providers is hard
Testing becomes difficult

With Abstraction:

// The Abstraction (The Contract)
interface PaymentGateway {
  charge(amount: number): void;
}

// The Implementation (The Detail)
class RazorpayGateway implements PaymentGateway {
  charge(amount: number): void {
    console.log(`Charging ${amount} via Razorpay`);
  }
}

class Order {
  // We depend on the abstraction, not the specific tool.
  constructor(private paymentGateway: PaymentGateway) {}

  processOrder(amount: number) {
    // business logic delegated respectively
    this.paymentGateway.charge(amount);
  }
}

Now:

Order class depends on behavior , not implementation
Payment logic can change independently
Code becomes loosely coupled hence testable and flexible

2. Encapsulation

The Concept: Encapsulation keeps an object’s data (state) private and only allows access through strictly defined methods.

The Problem: If any piece of code can change a balance variable directly, you will eventually end up with negative balances or corrupted data.

The Solution: Protect the data so the object can enforce its own rules.

Let us see with an example.

Poor Encapsulation:

class BankAccount {
  balance: number = 0;
}

const account = new BankAccount();
account.balance = -500; // mutable and incorrect

Nothing prevents incorrect usage / modification in the above code.

Proper Encapsulation:

class BankAccount {
  private _balance: number = 0;

  deposit(amount: number): void {
    if (amount <= 0) throw new Error("Deposit must be positive");
    this._balance += amount;
  }

  withdraw(amount: number): void {
    if (amount > this._balance) throw new Error("Insufficient funds");
    this._balance -= amount;
  }
}

// usage
const account = new BankAccount();
account.balance = 500; // Not Allowed, throws error

Encapsulation is to protect the state of the Object.

3. Inheritance

The Concept: Inheritance allows a class to derive features from another class. It models an “Is-A” relationship.

The Problem: Writing the same login() or logout() logic for Admin, Customer, and Guest leads to code duplication.

The Solution: Move common logic to a base "Parent" class.

Code snippet:

class User {
  constructor(public email: string) {}

  logout() {
    console.log(`${this.email} logged out safely.`);
  }
}

class Admin extends User {
  deleteUser(userId: string) {
    console.log(`Admin deleted user ${userId}`);
  }
}

Admin is a User— this relationship makes sense.

Inheritance Pitfalls:

Deep inheritance trees
Overriding base behavior unexpectedly
Changes in parent classes breaking children

Inheritance increases coupling. Use it intentionally, not by default.

4. Polymorphism

The Concept: Polymorphism allows you to treat different objects as the same type. It allows a single function to work with different classes interchangeably.

The Problem: Massive if/else blocks that check types (e.g., if (type === 'sms') ... else if (type === 'email')).

The Solution: Use a common interface so the code doesn't care about the specific type.

Polymorphism replaces conditionals with interchangeable behavior.

Conditional Logic:

function sendNotification(type: string, message: string) {
  if (type === "email") {
    console.log("Sending Email:", message);
  } else if (type === "sms") {
    console.log("Sending SMS:", message);
  }
}

Proper Polymorphism usage:

interface Notification {
  send(message: string): void;
}

class EmailNotification implements Notification {
  send(message: string) {
    console.log("Sending Email:", message);
  }
}

class SmsNotification implements Notification {
  send(message: string) {
    console.log("Sending SMS:", message);
  }
}

// This function doesn't care WHAT service it is, as long as it can call .send()
function notifyAll(services: Notification[], message: string) {
  services.forEach(s => s.send(message));
}

Now:

No conditionals
New behaviors don’t modify existing code
The system stays extensible

Polymorphism removes conditional complexity.

Abstraction vs Polymorphism (A Commonly Confused Pair)

Abstraction and Polymorphism are often explained together — and that’s exactly why many of us may confuse the two.

They work together , but they solve different problems.

Abstraction defines what a system can do , its like a contract .

Polymorphism defines how that behavior can vary at _ **_runtime** .

Let’s clarify this using a real-world payment example.

Abstraction:

In a payment system, the business doesn’t care how a payment is processed.

It only cares that a payment can be processed or refunded.

Example:

export interface PaymentGateway {
  processPayment(amount: number): boolean;
  refundPayment(transactionId: string): boolean;
}

What this tells us:

These operations exist
Consumers can rely on them
No implementation details are exposed

At this level:

No Razorpay logic
No Stripe logic
Only business capability

This interface is pure abstraction.

Polymorphism:

Polymorphism allows different implementations of the same abstraction to be used interchangeably.

Each payment provider follows the same contract — but behaves differently.

Example:

class RazorPay implements PaymentGateway {
  processPayment(amount: number): boolean {
    // RazorPay-specific logic
    return true;
  }

  refundPayment(transactionId: string): boolean {
    // RazorPay-specific logic
    return true;
  }
}

class Stripe implements PaymentGateway {
  processPayment(amount: number): boolean {
    // Stripe-specific logic
    return true;
  }

  refundPayment(transactionId: string): boolean {
    // Stripe-specific logic
    return true;
  }
}

Here both classes:

Implement the same abstraction
Provide different internal behavior
Can be swapped without changing usage code

This is polymorphism in action.

Where Abstraction and Polymorphism Meet

Now look at this line carefully:

const paymentGateway: PaymentGateway = new RazorPay();

So what is happening here?

The variable type is PaymentGateway → Abstraction
The actual object is RazorPay → Polymorphism

At runtime:

The system calls the RazorPay implementation

Switching providers becomes trivial:

const paymentGateway: PaymentGateway = new Stripe();

The calling code doesn’t change — only the _behavior _ does.

Why This Design Matters in Real Systems?

This approach gives you:

Loose coupling
Easy extensibility
Cleaner code
Better testability

Adding a new provider will be easy in future:

class PayPal implements PaymentGateway {
  processPayment(amount: number): boolean {
    return true;
  }

  refundPayment(transactionId: string): boolean {
    return true;
  }
}

Composition Over Inheritance (A Modern OOP Rule)

Concept: Composition is the practice of combining simple objects to create complex ones.

Inheritance for Code Reuse:

class Logger {
  log(message: string) {
    console.log(message);
  }
}

class Order extends Logger {
  createOrder() {
    this.log("Order created");
  }
}

Here, Logger and Order classes are tightly coupled.

Let us see the code example how we can solve this issue.

Composition:

class Logger {
  log(message: string) {
    console.log(message);
  }
}

class Order {
  // inject dependency
  constructor(private logger: Logger) {}

  createOrder() {
    this.logger.log("Order created");
  }
}

Now this:

Reduces coupling
Improves testability
Increases flexibility

Inheritance is a “Vertical” relationship (Is-A). Composition is a “Horizontal” relationship (Has-A). In modern engineering, we prefer Composition because it is easier to swap parts at runtime.

Summary

Abstraction hides implementation details
Encapsulation protects state and rules
Inheritance models true hierarchies
Polymorphism removes conditional logic
Composition enables flexible design

OOP is about designing systems that can change without breaking.

What’s Next?

This article focused on learning OOP as a design mindset.

In Part 2 , we’ll apply these concepts directly to:

Angular components
Services and Dependency Injection
Real Angular architecture patterns

Source Code & Resources

If you’d like to dive deeper or try the examples yourself, all source code including those discussed in this series is available on my GitHub repository: Oop-Typescript-Angular

Connect with Me!

Hi there! I’m Manish , a Senior Engineer, passionate about building robust web applications and exploring the ever-evolving world of tech. I believe in learning and growing together.

If this article sparked your interest in modern Angular, software architecture, or just a tech discussion, I’d love to connect with you!

🔗 Let’s connect on LinkedInfor more tech insights and discussions.

📧 Follow me on Mediumto catch Part 2 when it drops!

💻 *Explore my work on * GitHub

Mastering Dependency Injection — Part 1: The Essentials Every Developer Must Know

Manish Boge — Sat, 15 Nov 2025 13:05:17 +0000

Mastering Dependency Injection — Part 1: The Essentials Every Developer Must Know

Unlock the design principle that powers modern frameworks powerful, testable, and scalable.

Introduction

Before diving into any framework’s DI system, whether it’s Angular, Spring, or .NET Core, it’s essential to understand the core design principle that powers them all.

Dependency Injection (DI) isn’t just a buzzword; it’s the architectural glue that enables loose coupling, modularity, and testability in modern applications.

In this two-part series of Understanding DI Concepts, we’ll break down DI from the ground up:

Part 1 (this article): The core concepts, principles, and mental models
Part 2: Practical patterns, testing strategies, and framework integration

Since the main goal of this series is to fully understand Angular’s Dependency Injection system , we must first build a solid foundation by understanding DI fundamentals, independent of any framework.

Let us start with the essentials.

Why Dependency Injection Matters

Dependency Injection (DI) is a fundamental software design pattern that improves code quality by promoting l oose coupling, enhanced testability, and cleaner architecture.

Whether you’re building a small app or a large-scale enterprise system, understanding DI is key to writing maintainable and scalable code.

Every time your class creates its own dependencies, it quietly takes on responsibilities it shouldn’t have.

That leads to:

Rigid, tightly coupled code
Hard-to-test components
Painful refactors
Code that breaks when business logic changes

DI solves all of these problems by enforcing one simple principle:

Classes should not create their dependencies — they should receive them.

This unlocks flexibility, composability, and maintainability in real-world applications.

This article breaks down DI basics, explaining what it is , why it’s important , and how it changes the way dependencies are managed in software.

What Is Dependency Injection?

Let us begin with a simple definition:

Dependency Injection is a technique where a class receives the objects it depends on — its dependencies — instead of creating them internally.

Technical Definition

Dependency Injection (DI) is a software design pattern in which an object’s dependencies are supplied by an external entity rather than being constructed within the object itself.

This pattern is a practical implementation of the Inversion of Control (IoC) principle, where the responsibility of creating and managing dependencies is delegated to an external system (such as a framework, a container, or even custom code).

A Simple Way to Think About It

Instead of a class saying:

“I’ll create everything I need.”

It says:

“Give me what I need to do my job.”

This inversion of responsibility provides major advantages:

Better maintainability
Easier testing
More flexible and modular systems

Here is the important part:

You don’t need a framework to understand DI. The concept exists independently of Angular, Spring, .NET, or any other DI container.

Inversion of Control (IoC): The Principle Behind DI

Inversion of Control (IoC) is the broader principle that underpins DI.

It means that the control of object creation and lifecycle is inverted - moved away from the dependent class to an external entity (like an injector or framework).

Without IoC: The class controls its dependencies.
With IoC: An external system (like Angular, Spring, or your own injector) controls them.

Think of IoC as the philosophy, and Dependency Injection as one practical way to implement it.

Note: DI isn’t the only way to achieve IoC. Other patterns include Service Locator, Factory patterns, and Event-driven architectures . Each has different trade-offs in terms of explicitness and discoverability. DI is favored because it makes dependencies explicit and easier to track.

Practical Analogy

Think of dependencies as services in our daily life.

We need a ride to work. We could:

Buy a car
Handle fuel
Pay for maintenance
Replace parts
Take responsibility for everything

Or…

We can use Uber.

We delegate the responsibility to someone else, and we just use the service.

DI works the same way:

Instead of creating and managing dependencies, your class simply uses what’s provided to it.

So that’s how DI improves scalability and flexibility in your projects.

The Problem DI Solves: Tight Coupling

In traditional object-oriented code, classes often create their own dependencies:

Example:

// Logger Class
class Logger {
  log(message: string): void {
    console.log('Log:', message);
  }
}

// User Class (tightly coupled)
class User {
  private logger = new Logger(); // hard-coded dependency

  createUser(name: string): void {
    this.logger.log(`User ${name} created.`);
  }
}

Consequence:

Here, User is tightly coupled to Logger.

If you want to replace Logger with a new one (DatabaseLogger or FileLogger), you must edit User’s source code.

This violates a core software design rule:

“High-level modules should not depend on low-level modules; both should depend on abstractions.” — Dependency Inversion Principle, the “D” in SOLID

Important Clarification:

Not all uses of the new keyword indicates bad design. Value objects, DTOs, and data structures should be created directly.

For example:

const date = new Date();
const email = new EmailAddress(userInput);

DI applies to behavioral dependencies such as services, repositories, and components that have side effects or external interactions like logging, database access, or API calls.

The Solution: Dependency Injection

With DI, dependencies are supplied (injected) from the outside — typically through the constructor:

Example:

// Logger (Dependency)
class Logger {
  log(message: string): void {
    console.log('Log:', message);
  }
}

// User (Dependent)
class User {
  constructor(private logger: Logger) {} // Constructor Injection (Recommended)

  createUser(name: string): void {
    this.logger.log(`User ${name} created.`);
  }
}

// Usage
const logger = new Logger();
const user = new User(logger);
user.createUser('Alice');

Now User doesn’t know how logging is done — it only knows that something logs.

So Now,

User doesn’t create Logger
Any logger can be provided
Testing is trivial
Different implementations(FileLogger, MockLogger, or DatabaseLogger without touching User) can be plugged in without touching User

This is DI in its simplest form — clean, elegant, and extensible.

A dependency is any object another class relies on. Dependency Injection is the technique of supplying those dependencies, instead of creating them inside the class.

Using Abstractions with Interfaces

To fully leverage the Dependency Inversion Principle, it’s best to depend on abstractions instead of concrete classes.

Example:

// ILogger interface as abstraction
interface ILogger {
  log(message: string): void;
}

// ConsoleLogger implements ILogger
class ConsoleLogger implements ILogger {
  log(message: string): void {
    console.log('Log:', message);
  }
}

// User depends on the ILogger abstraction
class User {
  constructor(private logger: ILogger) {}

  createUser(name: string): void {
    this.logger.log(`User ${name} created.`);
  }
}

// Usage
const logger = new ConsoleLogger();
const user = new User(logger);
user.createUser('Alice');

Now User depends only on the contract , never the concrete class.

Using an interface like ILogger decouples User from specific implementations, enabling seamless swapping and better scalability.

This is the essence of the Dependency Inversion Principle : both high-level and low-level modules depend on abstractions, not on each other.

A Preview: Types of Dependency Injection

There are several ways to inject dependencies into a class:

Constructor Injection — Dependencies passed through the constructor (most common and recommended)
Setter Injection — Dependencies set via setter methods (for optional dependencies)
Method Injection — Dependencies passed as method parameters (for transient needs)
Interface-Based Injection — Injection enforced through interface contracts

Each pattern serves different use cases, and we’ll explore all of them in detail in Part 2 of this series.

For now, just know that Constructor based Injection is the recommended default because it makes dependencies explicit and ensures objects are fully initialized.

When to Use Dependency Injection

DI is particularly valuable when:

Your application has complex dependencies across components or services
Unit testing and mocking are priorities
You want a modular, scalable architecture that supports future change
You expect multiple implementations of the same abstraction
Your team is working on a medium-to-large codebase

When NOT to Use Dependency Injection

DI isn’t always the right choice. Consider simpler alternatives when:

Building small scripts or utilities (< 3 dependencies)
Writing pure functions with no external dependencies
Working in performance-critical paths where indirection matters
Prototyping or writing throwaway code
The complexity of DI setup outweighs the benefits

Remember: Every pattern has trade-offs. DI adds indirection and configuration overhead. For simple scenarios, direct instantiation is perfectly fine.

The Mental Model: Thinking in Dependencies

The key mindset shift with DI is this:

Before DI thinking: “What do I need? Let me go create it.”

After DI thinking: “What do I need? Let me declare it, and someone else will provide it.”

This shift enables:

Flexibility — Swap implementations without code changes
Testability — Replace real dependencies with mocks
Maintainability — Changes localized to one place
Scalability — New features don’t break existing code

Once you internalize this mental model, writing loosely coupled code becomes natural.

Real-World Impact: Why This Matters

Let me share a quick example from a fintech project point of view.

We needed to support multiple payment gateways (Stripe, PayPal, internal processing). Initially, payment logic was scattered across 200+ transaction-handling classes, each directly instantiating the payment gateway they needed.

Without DI:

When business requirements changed and we needed to switch providers, it would have required modifying every single class.

The DI solution:

We created an IPaymentGateway interface and used Constructor Injection. Suddenly:

Switching providers became a single configuration change
Testing payment logic used mock gateways (no real transactions)
Adding new providers didn’t touch existing code

This is the power of DI: change becomes configuration, not code modification.

What’s Coming in Part 2

Now that you understand the core philosophy of Dependency Injection, you’re ready to see it in action.

In Part 2: Dependency Injection in Practice , we’ll explore:

The 4 injection patterns in detail (Constructor, Setter, Method, Interface-based)
Dependency lifecycles : Singleton vs Transient vs Scoped
Testing strategies with real DI examples and mocks
How frameworks automate DI (Angular, Spring, .NET Core)
Common pitfalls that trip up even experienced developers
Real-world case studies

Part 2 will be published next week — follow me so you don’t miss it!

Conclusion

Dependency Injection isn’t just a pattern, it’s a mindset that leads to cleaner, more robust code.

Understanding the essentials of DI is the first step toward mastering frameworks like Angular, where these principles are automated and extended.

These concepts form the mental model you need to understand how modern frameworks work.

But we’re just getting started.

Let’s Talk DI!

Dependency Injection isn’t just some fancy design pattern — it’s the backbone of clean, flexible, and testable code.

Now I’m curious…

What DI pattern do you usually rely on in your projects?
Have you ever struggled with tight coupling , and how did DI help you untangle it?

Drop your thoughts in the comments — I’d love to hear how other developers approach this!

And if you found these examples helpful, give it a clap and share it with your team.

Source Code & Resources

If you’d like to dive deeper or try the examples yourself, all source code including those discussed in this series is available on my GitHub repository: Angular DI Series

Connect with Me!

Hi there! I’m Manish , a Senior Engineer, passionate about building robust web applications and exploring the ever-evolving world of tech. I believe in learning and growing together.

If this article sparked your interest in modern Angular, software architecture, or just a tech discussion, I’d love to connect with you!

🔗 Let’s connect on LinkedInfor more tech insights and discussions.

📧 Follow me on Mediumto catch Part 2 when it drops next week!

💻 *Explore my work on * GitHub

Mastering Modern Angular: Functional Route Guards & Interceptors Explained

Manish Boge — Sat, 26 Jul 2025 13:09:17 +0000

Unlock the Power of Functional Route Guards & Interceptors

Angular has evolved rapidly, continuously striving for cleaner, more composable, and less verbose code. Among the most developer-friendly advancements in recent versions is the shift from traditional, class-based APIs to more concise Functional APIs , especially for Route Guards and HTTP interceptors.

In this article we will explore:

Why Route Guards and Interceptors Matter?
Traditional Angular: Class-Based APIs
Modern Angular: Functional APIs
Comparison Table: Traditional vs. Functional
When to Choose: Class-Based vs Functional ?

Note: Functional route guards and interceptors were introduced in Angular v15+. Ensure your project is on v15 or later to fully benefit. While Angular is now at v20.x.x, we’ll focus on these pivotal modern patterns introduced from v15+, which are important for Modern Angular Development.

Let’s dive in!

Why Route Guards and Interceptors Matter ?

Let’s understand with real-world examples.

Route Guards

These are your application’s security checkpoints. They protect routes based on authentication , roles , or permissions before a route even activates.

Use Case:

Let’s imagine a personal online banking application or a social media profile. When a user tries to access a protected page like /my-account or /settings, a route guard immediately checks: "Is this user currently logged in?" If not, it instantly redirects them to the /login page.

HTTP Interceptors

Think of these as a centralized control panel for all your HTTP traffic. They globally transform HTTP requests and responses — perfect for adding headers, handling network errors, logging, or showing loading indicators.

Use Case:

Let us imagine an Angular application needs to communicate with a secured backend API , for instance, to fetch a user’s profile details or submit a form. Every single request to this API requires an authentication token to prove the user’s identity. Instead of manually adding Authorization: Bearer to every single HTTP call in various services throughout your application, an HTTP Interceptor can do this automatically for you. It's like having a dedicated assistant who makes sure your secret key is attached to every letter you send out, without you ever having to remember it. This keeps your service code clean and focused on business logic, not authentication details.

Now that we understand the role of Route Guards and Interceptors , let us now see the Traditional(class-based) and Functional way of creating each.

Traditional Angular

Before the functional revolution, Angular developers relied on a more verbose, class-oriented approach for route guards and interceptors. While these patterns were standard for years, the class-based guard interfaces are now officially deprecated, and functional guards, interceptors are the recommended modern alternative. Understanding this foundation helps appreciate the simplicity and power of the new functional paradigms.

Class-Based Route Guard

Lets see the code snippet for canActivate guard:

// auth.guard.ts
import { Injectable } from '@angular/core';
import { CanActivate, ActivatedRouteSnapshot, RouterStateSnapshot, Router, UrlTree } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable({ providedIn: 'root' })
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}

  canActivate(
    route: ActivatedRouteSnapshot,
    state: RouterStateSnapshot
  ): boolean | UrlTree {
    if (this.authService.isLoggedIn()) {
      return true; // User is logged in, allow access
    }
    // If User is not logged in, redirect to login page
    return this.router.createUrlTree(['/login']);
  }
}

Usage in Router Config:

{
  path: 'dashboard',
  component: DashboardComponent,
  canActivate: [AuthGuard] // Reference the class
}

Class Based HTTP Interceptor

Let us assume we have an AuthInterceptor that adds an authorization token to outgoing http requests.

// auth.interceptor.ts
import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent } from '@angular/common/http';
import { Observable } from 'rxjs';
import { AuthService } from './auth.service';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
  constructor(private authService: AuthService) {}

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const token = this.authService.getToken();
    // clone request due to immutability
    const authReq = req.clone({
      setHeaders: { Authorization: `Bearer ${token}` } // Add token to headers
    });
    return next.handle(authReq);
  }
}

Usage in Standalone Angular Application:

// app.config.ts
providers: [
    // This is crucial for class-based interceptors in standalone apps
    provideHttpClient(withInterceptorsFromDi()),
    {
      provide: HTTP_INTERCEPTORS,
      useClass: AuthInterceptor, // Register the class
      multi: true,
    },
  ],

Usage in Module based Angular application:

@NgModule({
  providers: [
    { 
      provide: HTTP_INTERCEPTORS, 
      useClass: AuthInterceptor, // Register the class 
      multi: true 
    } 
  ]
})
export class AppModule {}

Modern Angular

Angular v15+ ushered in a new era of conciseness and expressiveness. Discover how pure functions now simplify the critical tasks of route protection and HTTP request manipulation, making your code cleaner and more efficient.

Since Angular v15+ , we can leverage the Functional APIs such as Functional Route Guards, Interceptors.

Functional Route Guards

Here’s a roleGuard that checks for a specific user role.

// role.guard.ts
import { inject } from '@angular/core';
import { ActivatedRouteSnapshot, CanActivateFn, Router, RouterStateSnapshot } from '@angular/router';
import { AuthService } from './auth.service';

export const roleGuard: CanActivateFn = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
  const authService = inject(AuthService); // Inject services directly (New API)
  const router = inject(Router);
  const requiredRole = route.data['requiredRole']; // Access route data

  if (authService.isLoggedIn() && authService.getUserRole() === requiredRole) {
    return true; // User has required role, allow access
  } else {
    // User doesn't have the role or isn't logged in, redirect
    return router.createUrlTree(['/login']);
  }
};

Note: Here we have used inject() Function API instead of a constructor for dependency injection. The inject() function was introduced in Angular v14.

Usage in Module-Based Router Config ( app-routing.module.ts ) or Standalone Application Router Config( app.route.ts ):

{
  path: 'admin',
  component: AdminComponent,
  canActivate: [roleGuard], // Reference the function directly
  data: { requiredRole: 'admin' } // Pass required role via route data
}

Note: There are other route guard and resolver functions like canActivateChildFn, canDeactivateFn, canLoadFn, canMatchFn, and ResolveFn. I will cover a deep dive of these in another article.

Functional HTTP Interceptor

This functional authInterceptor does the same job as its class-based counterpart, but with less code.

// auth-fn.interceptor.ts
import { HttpEvent, HttpHandlerFn, HttpInterceptorFn, HttpRequest } from '@angular/common/http';
import { Observable } from 'rxjs';
import { inject } from '@angular/core';
import { AuthService } from './auth.service';

export const authFnInterceptor: HttpInterceptorFn = (req: HttpRequest<unknown>, next: HttpHandlerFn): Observable<HttpEvent<unknown>> => {
  const authService = inject(AuthService); // Inject services directly
  const token = authService.getToken();

  // Clone the request to add the authorization header
  const authReq = req.clone({
    setHeaders: { Authorization: `Bearer ${token}` }
  });

  return next(authReq); // Pass the modified request to the next handler
};

Usage in Standalone Angular Application:

// app.config.ts
import { authFnInterceptor } from './interceptors/functional/auth-fn.interceptor';
import { ApplicationConfig} from '@angular/core';
import { provideHttpClient, withInterceptors } from '@angular/common/http';export const appConfig: ApplicationConfig = {

providers: [
    provideHttpClient(withInterceptors([authFnInterceptor])),

  ]
};

Usage in Module based Angular Application:

// app.module.ts
import { authFnInterceptor } from './interceptors/functional/auth-fn.interceptor';
import { provideHttpClient, withInterceptors } from "@angular/common/http";

@NgModule({
  providers: [
    provideHttpClient(withInterceptors([authFnInterceptor]))
  ]
})
export class AppModule {}

With functional interceptors, you can chain these small, focused functions in withInterceptors([]), making your HTTP layer highly modular, readable, and maintainable.

Note: There are certain use cases of interceptors like to catch network errors like 401, 500 and to handle loading state while API requests are ongoing. I will cover a deep dive of these like handling multiple interceptors in Angular with another article.

Comparison Table: Traditional vs. Functional

This comparison table outlines the key differences between the two styles across critical aspects such as boilerplate, dependency injection, readability, and testability. While class-based APIs have been the cornerstone of Angular since its early versions, function-based APIs bring a more concise and expressive syntax that aligns with modern frontend development trends

When to Choose: Functional vs. Class-Based ?

Given the significant benefits of functional APIs we’ve already explored, and their future-forward nature, the decision in modern Angular development is largely straightforward.

Crucially, class-based guard interfaces (CanActivate, ** CanDeactivate, etc.) were deprecated in Angular v16. While they still function for backward compatibility, new development should strongly favor their functional counterparts. Similarly, for HTTP interceptors, functional HTTP interceptors** are now the recommended modern approach to handle HTTP logic for modern Angular development, effectively superseding the class-based approach for new code.

For any new development in Angular v15+, the choice is clear: always default to functional APIs for Route Guards and HTTP Interceptors

Why Functional is the Way Forward:

Less Boilerplate: Write more logic, less framework code.
Enhanced DX & Readability: Concise, pure functions are easier to understand and maintain.
Optimal Performance: Better tree-shaking for smaller bundle sizes.
Simplified Testing: Isolated logic makes unit testing a breeze.

When to Consider Class-Based:

Legacy Codebases: Primarily for maintaining existing class-based implementations or when a full refactor isn’t immediately feasible.
Specific Compatibility: Extremely rare cases involving older third-party libraries that explicitly require class-based patterns.

In short, leverage functional APIs for a modern, efficient, and developer-friendly Angular experience. Class-based remains primarily for backward compatibility.

How Functional APIs Facilitate Tree-Shaking ?

Functional guards and interceptors are pure functions with explicit dependencies via inject(). This enables bundlers (like Webpack or Rollup) to perform more aggressive and precise dead code elimination. Unused logic (and their associated dependencies) is more easily identified and removed from production builds, leading to smaller bundle sizes and faster load times—a direct win for user experience.

Conclusion

Functional APIs for route guards and interceptors mark a major leap in Angular’s Developer Experience (DX). By shedding verbose classes and embracing modern TypeScript patterns, Angular continues to evolve toward a cleaner, faster, and more testable future. This isn’t just a stylistic change; it’s a fundamental improvement that empowers you to build more robust, maintainable, and performant applications.

Ready to modernize your Angular apps? Refactor your route guards and HTTP interceptors into functions — your future self (and your teammates) will thank you!

Source Code & Resources

Want to dive deeper or run these examples yourself?

You can find the complete source code , including all the examples and demos discussed in this article, on our GitHub repository: Angular 17 Series GitHub Repository

Love what you see? Don’t forget to give the repository a star ⭐ on GitHub! It helps us know you appreciate the content and encourages more updates and examples. The README.md file within the repo provides all the guidance you'll need to get the project up and running.

Continue Your Modern Angular Journey

This article is part of our Modern Angular Development Series. Explore other articles to continue your learning journey:

Connect with Me!

Hi there! I’m Manish, a Senior Engineer, passionate about building robust web applications and exploring the ever-evolving world of tech. I believe in learning and growing together.

If this article sparked your interest in modern Angular, software architecture, or just a tech discussion, I’d love to connect with you!

🔗Follow me on LinkedInfor more discussions or contributing or just to chat tech.

Thank you for reading — and happy 🅰️ ngularing!

Modern Angular Development: The Angular 17 Revolution

Manish Boge — Wed, 23 Jul 2025 13:43:36 +0000

Before We Begin

Welcome to my very first article on Dev.to!

As an experienced Angular developer, I’ve seen the framework evolve through many versions — but Angular 17 marks a true turning point. This release isn’t just a version bump; it redefines how we build, optimize, and think about Angular applications.

With powerful features like the new built-in control flow syntax @if, @for, @switch, deferrable views , and a blazing-fast Vite + esbuild build system, Angular 17 modernizes the development experience while delivering major performance gains.

Whether you’re a seasoned Angular veteran or just starting out, this article will walk you through the key highlights of Angular 17 — how they simplify, accelerate, and transform the way we build web apps.

And yes, Angular 20 is already out — but before jumping ahead, let’s take a moment to appreciate the solid foundation Angular 17 laid. It’s this release that sparked the momentum behind today’s Angular renaissance.

Let’s dive in!

🔥The Angular Renaissance

Angular 17 represents more than an incremental update — it fundamentally redefines how developers build Angular applications. The release focuses on three core areas: performance optimization, development simplicity, and enhanced developer experience.

Performance improvements are remarkable, with up to 90% faster execution compared to previous versions. Build times have been reduced by up to 87% for hybrid rendering and 67% for client-side rendering, transforming the entire development workflow.

✨Major Features Overview

Built-in Control Flow Syntax

New @if, @for, and @switch syntax replacing verbose structural directives
Cleaner, more readable templates with JavaScript-like syntax
Better type checking and reduced bundle size

Deferrable Views

@defer blocks for intelligent component lazy loading
Multiple trigger options (viewport, interaction, hover, timer)
Declarative loading, error, and placeholder states

Enhanced Server-Side Rendering

Simplified SSR setup with @angular/ssr package
Seamless hydration for better performance
Improved SEO capabilities

Developer Productivity Tools

Vite + esbuild build system for faster development
New lifecycle hooks for DOM interaction
Enhanced debugging with improved DevTools

🎛️Streamlined Control Flow Syntax

❌The Challenge with Traditional Directives

Previous Angular versions required verbose syntax for common template operations.

The *ngIf directive necessitated external templates for else conditions:

<div *ngIf="loggedIn; else anonymousUser">
  <p>The user is logged in</p>
</div>
<ng-template #anonymousUser>
  <p>The user is not logged in</p>
</ng-template>

Many developers reported having to constantly look up *ngFor and trackBy syntax, even after years of experience.

<div *ngFor="let item of items; trackBy: trackByFn">
 {{ item.name }}
</div>

The trackBy function in component.ts file would like below:

trackByFn(index: number, item: any) {
 return item.id; // or any unique identifier
}

Similarly, *ngSwitch demanded complex nested syntax:

<div [ngSwitch]="accessLevel"> 
  <admin-dashboard *ngSwitchCase="'admin'"/>
  <moderator-dashboard *ngSwitchCase="'moderator'"/>
  <user-dashboard *ngSwitchDefault/>
</div>

✅ Modern Block-Based Syntax

Angular 17 introduces intuitive control flow that resembles JavaScript:

@if (status === 'active') {
  <p>Active</p>
} @else if (status === 'inactive') {
  <p>Inactive</p>
} @else {
  <p>Pending</p>
}

The @switch syntax is equally straightforward:

@switch (accessLevel) {
  @case ('admin') {
    <admin-dashboard/>
  }
  @case ('moderator') {
    <moderator-dashboard/>
  }
  @default {
    <user-dashboard/>
  }
}

The @for loop requires explicit tracking for optimal performance:

@for (user of users; track user.id) {
  {{ user.name }}
} @empty {
  <p>No users available</p>
}

🎯Technical Benefits

The new control flow delivers significant advantages:

Better Type Checking : Improved type-narrowing in conditional branches
Reduced Bundle Size : Up to 30KB reduction since control flow is compiler-built
Enhanced Performance : Up to 90% faster execution in framework benchmarks
Automatic Availability : No imports required, automatically available in all templates

⚡Deferrable Views: Intelligent Lazy Loading

❌Previous Lazy Loading Complexity

Before Angular 17, component lazy loading required manual ViewContainerRef management:

@ViewChild('viewContainer', { read: ViewContainerRef }) 
viewContainerRef!: ViewContainerRef;

async ngAfterViewInit() {
  const { LazyComponent } = await import('./lazy/lazy.component');
  this.viewContainerRef.createComponent(LazyComponent);
}

✅ Declarative Lazy Loading with @defer

The @defer block simplifies lazy loading to a single template declaration:

@defer {
  <heavy-component />
}

Multiple trigger options provide precise control:

@defer (on viewport; prefetch on hover) {
  <comments-section />
} @loading (minimum 500ms) {
  <loading-spinner />
} @placeholder {
  <p>Comments will appear here</p>
} @error {
  <p>Failed to load comments</p>
}

Available triggers include:

on idle: Loads when browser becomes idle (default)
on viewport: Loads when element enters viewport
on interaction: Loads after user interaction
on hover: Loads on mouse hover
on timer(duration): Loads after specified time
when condition: Loads based on custom conditions

💡 Note: The new control flow, defer features are in developer preview in Angular 17, will become stable in Angular v18.

📡Signal APIs: Simplified Reactivity

Angular 17 introduces Signal APIs for managing reactive state without heavy RxJS dependencies:

// Creating reactive values
const count = signal(0);
const name = signal('Angular');

// Updating values
count.set(5);
count.update(current => current + 1);

// Computed values
const displayText = computed(() => `${name()} count: ${count()}`);

Key Signal APIs include:

signal(): Creates reactive values
set(): Sets new values
update(): Updates based on current value
computed(): Derives values from other signals

💡 Note: This article only introduces the basics of Angular Signals. I’ll be publishing a dedicated series of articles exploring these APIs in depth — with real-world examples, best practices, and migration guidelines.

🖥️Simplified Server-Side Rendering

Streamlined SSR Setup

Angular 17 replaces Angular Universal with the @angular/ssr package, dramatically simplifying server-side rendering setup.

Create SSR-enabled projects:

ng new app-name --ssr

Add SSR to existing projects:

ng add @angular/ssr

Performance and SEO Benefits

The new SSR implementation provides:

Up to 87% faster builds for hybrid rendering
Intelligent hydration without DOM flickering
Improved Core Web Vitals scores
Better search engine indexing
Automatic HTTP request caching

🛠️Developer Productivity Enhancements

🔄New Lifecycle Hooks

Angular 17 adds browser-specific lifecycle hooks:

constructor() {
  afterNextRender(() => {
    this.chart = new MyChart(this.chartRef.nativeElement);
  }, {phase: AfterRenderPhase.Write});
}

afterRender: Runs after each change detection cycle
afterNextRender: Executes once after the next render cycle

⚡Vite + esbuild Build System

The new build system delivers remarkable performance improvements:

Over 67% faster builds in most applications
Near-instant hot module replacement
Component-level HMR
Efficient dependency pre-bundling

Enable for existing projects by updating angular.json:

{
  "builder": "@angular-devkit/build-angular:browser-esbuild"
}

🧩Standalone APIs

Standalone components eliminate module dependencies:

@Component({
  selector: 'app-example',
  standalone: true,
  imports: [CommonModule, RouterModule],
  template: `<p>Standalone component</p>`
})
export class ExampleComponent {}

Generate standalone components:

ng generate component componentName --standalone

⬆️Migration Considerations

When upgrading to Angular 17:

Control Flow : New syntax is opt-in; existing *ngIf, *ngFor continue working
Defer Blocks : Currently in developer preview, stable in Angular 18
Signal APIs : Core APIs are stable; input/output signals in preview
Build System : Vite + esbuild enabled by default for new projects

📈Performance Impact

Real-world measurements show:

30% average speed improvement in Angular Material applications
Significant reduction in bundle sizes
Improved Core Web Vitals scores
Faster development server startup times

🎯Conclusion

Angular 17 establishes a solid foundation for modern web development. The combination of intuitive syntax, intelligent lazy loading, simplified SSR, and powerful build tools creates a development experience that balances productivity with performance.

The framework’s evolution toward declarative patterns, reduced boilerplate, and enhanced developer experience positions Angular as a leading choice for enterprise and consumer applications alike.

These improvements represent Angular’s commitment to developer productivity while maintaining the robustness and scalability that enterprise applications require.

I encourage you to explore these new features and discover their transformative potential firsthand. While features like Angular Standalone API, Angular Core Signals APIs ( set, update, computed, effect ), Functional Guards/Resolvers, Functional Interceptors, and Global Error Handling are production-ready, don’t miss trying the developer preview features like the new control flow and defer blocks — they showcase Angular’s innovative direction. Over the coming weeks, I’ll be publishing dedicated in-detailed articles every Week, exploring each feature which I mentioned above with step-by-step implementations and practical examples.

💻 Source Code & Resources

🔗 Find the complete source code for this Angular 17 series at the angular-17-series repository.

📌 Don’t forget to ⭐ star the repo to stay updated with new examples and improvements!

All code examples, demos, and additional resources referenced in this article are available for hands-on practice and learning.

🚀 What’s Coming Next: Mastering Angular’s Standalone APIs

In our next article, we’ll dive deep into Angular’s Standalone APIs — a modern way to build lightweight, modular applications without relying on NgModules. Learn how to create standalone components, directives, and pipes, and see how they can streamline your architecture and boost performance.

Stay tuned — the future of Angular is leaner, cleaner and powerful!

Thank you — and happy Angularing! 🅰️

🤝 Let's Connect

Follow me on Dev.to for deep dives, tutorials, and hands-on Angular content.
Read more of my technical articles on Medium, where I cover Angular, TypeScript, and modern web development.
Follow or Connect with me on LinkedIn to stay updated on my latest Angular posts or just to chat tech .

💬 Got any Questions or Feedback?

I’d love to hear from you! Drop a comment below or reach out — let’s keep the conversation going.

Catching Those Leaks: A Deep Dive into Angular RxJS Subscription Management Strategies

Manish Boge — Sat, 12 Jul 2025 17:06:44 +0000

From Manual Cleanup to Modern Auto-Unsubscribe

As an Angular developer, you wield the mighty power of RxJS Observables — a truly transformative tool for handling asynchronous data. But with great power comes great responsibility! Unmanaged subscriptions are notorious for causing subtle, insidious memory leaks and performance bottlenecks in your applications.

Imagine a component making an API call, getting destroyed, but its subscription is still alive, trying to update a part of the DOM that no longer exists. Not pretty, right?

Fear not! Today, we’ll dive deep into different strategies to gracefully manage your RxJS subscriptions, ensuring your Angular apps remain lean, fast, and robust. From the classic manual approach to the modern, elegant solutions, let’s explore how to keep those memory leaks at bay!

The Foundation

For all our examples, let’s assume we have a simple UserService and ProductServicethat provides Observables for fetching data.

Our Service Code Snippets

First, let’s define our two distinct services, one for users and one for products, using Angular’s HttpClient.

Lets assume we have Models for user and product:

// src/app/models/user.ts
export interface User {
  id: number;
  name: string;
  username: string;
  email: string;
  // ... other user properties
}

// src/app/models/products.ts
export interface Product {
  id: number;
  title: string;
  price: number;
  description: string;
  category: string;
  image: string;
  rating: {
    rate: number;
    count: number;
  };
}

User Service:

// src/app/services/user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { User } from '../models/user'; // Ensure this path is correct
@Injectable({
  providedIn: 'root'
})
export class UserService {
  private #apiUrl = 'https://jsonplaceholder.typicode.com/users'; // Public API for users
  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    console.log('UserService: Fetching users...');
    return this.http.get<User[]>(this.#apiUrl);
  }

  getUser(id: number): Observable<User | undefined> {
    console.log(`DataService: Fetching user with ID: ${id}...`);
    return of(this.users.find(u => u.id === id)).pipe(delay(300)); // Simulate network delay
  }  

  // A long-lived observable, for demonstration purposes
  getPollingData(): Observable<number> {
    console.log('DataService: Starting polling...');
    return timer(0, 1000); // Emits every second
  }
}

Product Service:

// src/app/services/product.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { Product } from '../models/product'; // Ensure this path is correct@Injectable({
  providedIn: 'root'
})
export class ProductService {
  private #apiUrl = 'https://fakestoreapi.com/products'; // Public API for products
  constructor(private http: HttpClient) {}

  getProducts(): Observable<Product[]> {
    console.log('ProductService: Fetching products...');
    return this.http.get<Product[]>(this.#apiUrl);
  }
}

Note: using the modern private field syntax (private #fieldName) for better encapsulation.

1. The Classic Approach: Manual Subscription Management

This is where many Angular developers start. It’s explicit, straightforward, but can quickly lead to boilerplate if not managed well. You create Subscription objects, add them together, and then unsubscribe a single "master" subscription.

How it Works:

You declare a Subscription instance (or an array of them) in your component. Each time you subscribe, you add the returned Subscription object to your master subscription. In ngOnDestroy(), you call unsubscribe() on the master, which then unsubscribes from all added child subscriptions.

Pros:

Explicit and easy to understand for beginners.
Native RxJS functionality.

Cons:

Boilerplate: Requires creating a Subscription object and manually adding each new subscription.
Forgetfulness: Easy to forget to add a subscription, leading to leaks.
Can get messy if you have many conditional subscriptions.

Component Code Snippet:

// src/app/classic/user-list-classic/user-list-classic.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs'; // Import Subscription
import { User } from '../../models/user';
import { UserService } from '../../services/user.service';

@Component({
  selector: 'app-user-list-classic',
  templateUrl: './user-list-classic.component.html',
  styleUrl: './user-list-classic.component'
  `
})
export class UserListClassicComponent implements OnInit, OnDestroy {
  users: User[] = [];
  pollingValue: number = 0;

  // 1. Declare a master Subscription object
  private #subscriptions = new Subscription(); // Using private field syntax

  constructor(private #dataService: UserService) {}

  ngOnInit(): void {
    // 2. Add each subscription to the master subscription
    this.#subscriptions.add(
      this.#dataService.getUsers().subscribe(users => {
        this.users = users;
      })
    );

    this.#subscriptions.add(
      this.#dataService.getPollingData().subscribe(value => {
        this.pollingValue = value;
      })
    );
  }

  // 3. Unsubscribe from the master subscription on destroy
  ngOnDestroy(): void {
    console.log('UserListClassicComponent: Unsubscribing all classic subscriptions.');
    this.#subscriptions.unsubscribe();
  }
}

2. The Organizer: Using the SubSink Package

SubSink is a fantastic third-party library that simplifies the management of multiple subscriptions, making your ngOnDestroy() much cleaner. It's essentially a convenience wrapper around the classic Subscription.add() method.

How it Works:

You install subsink (npm install subsink). You then create an instance of SubSink and assign your subscriptions to its sink property or use its add() method. When you call unsubscribe() on the SubSink instance, it unsubscribes all managed subscriptions.

Pros:

Significantly reduces boilerplate compared to manual Subscription.add().
Provides a clean, single point of control for multiple subscriptions.
Offers type safety if you use the .add() method.

Cons:

Introduces a third-party dependency.
Still requires you to explicitly call unsubscribe() in ngOnDestroy().

Component Code Snippet:

// src/app/subsink/user-profile-subsink/user-profile-subsink.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { SubSink } from 'subsink'; // 1. Import SubSink
import { User } from '../../models/user';
import { UserService } from '../../services/user.service';
import { switchMap } from 'rxjs/operators';

@Component({
  selector: 'app-user-profile-subsink',
  templateUrl: './user-profile-subsink.component.html',
  styleUrl: './user-profile-subsink.component.scss'
  `
})

export class UserProfileSubsinkComponent implements OnInit, OnDestroy {
  user: User | undefined;
  pollingValue: number = 0; 

  // 2. Create a new SubSink instance
  private #subs = new SubSink();
  constructor(
    private #dataService: DataService,
    private #route: ActivatedRoute
  ) {}

  ngOnInit(): void {
    // 3. Assign subscriptions to subs.sink 
    this.#subs.sink = this.#route.paramMap.pipe(
      switchMap(params => this.#dataService.getUser(Number(params.get('id'))))
    ).subscribe(user => {
      this.user = user;
    });

    // or use subs.add()
    this.#subs.add(
      this.#dataService.getPollingData().subscribe(value => {
        this.pollingValue = value;
      })
    );
  }

  // 4. Unsubscribe all managed subscriptions on destroy
  ngOnDestroy(): void {
    console.log('UserProfileSubsinkComponent: Unsubscribing all SubSink subscriptions.');
    this.#subs.unsubscribe();
  }
}

3. The Guardian: Leveraging takeUntil()

This is where the magic of RxJS operators truly shines for subscription management. takeUntil() is an RxJS operator that allows an Observable stream to continue until another "notifier" Observable emits a value.

How it Works:

You declare a Subject (typically named destroy$ or unSubscribe$). In ngOnDestroy(), you make this Subject emit a value (.next()) and then complete it (.complete()). You then pipe(takeUntil(this.destroy$)) before subscribing to any Observable. When destroy$ emits, takeUntil automatically completes the piped Observable, unsubscribing from it.

Pros:

RxJS-native: No external dependencies.
Declarative: Clearly expresses intent in the Observable chain.
Elegant: Eliminates manual unsubscribe() calls and Subscription objects in component logic.
Highly readable once you understand the pattern.

Cons:

Still requires the boilerplate of declaring the Subject and implementing ngOnDestroy() in every component.
Requires remembering to pipe takeUntil to every subscription.

Component Code Snippet:

// src/app/takeuntil/user-list-takeuntil.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs'; // 1. Import Subject
import { takeUntil } from 'rxjs/operators'; // 2. Import takeUntil
import { User } from '../../models/user';
import { UserService } from '../../services/user.service';

@Component({
  selector: 'app-user-list-takeuntil',
  templateUrl: './user-list-takeuntil.component.html',
  styleUrl: './user-list-takeuntil.component.scss'
})
export class UserListTakeUntilComponent implements OnInit, OnDestroy {
  users: User[] = [];
  pollingValue: number = 0;

  // 3. Declare a private Subject to act as the notifier
  private #destroy$ = new Subject<void>(); // Using # for private field

  constructor(private #dataService: DataService) {}

  ngOnInit(): void {
    this.#dataService.getUsers().pipe(
      map(users => users.filter(user => user.isActive)), // Example transformation
      takeUntil(this.#destroy$) // 4. Pipe takeUntil before subscribing and keep at last after other operators
    ).subscribe(users => {
      this.users = users;
    });

    this.#dataService.getPollingData().pipe(
      takeUntil(this.#destroy$) // For long-lived observables, this is crucial
    ).subscribe(value => {
      this.pollingValue = value;
    });
  }

  // 5. Emit a value and complete the Subject on destroy
  ngOnDestroy(): void {
    console.log('UserListTakeUntilComponent: Notifying takeUntil subscriptions.');
    this.#destroy$.next(); // Signal to all takeUntil operators
    this.#destroy$.complete(); // Complete the Subject itself
  }
}

4. The Game Changer: takeUntilDestroyed() (Angular v16+)

This is the newest, most elegant, and arguably the most idiomatic way to manage subscriptions in modern Angular applications (v16 and later). It removes almost all the boilerplate associated with subscription management.

How it Works:

takeUntilDestoryed() is a function from @angular/core/rxjs-interop that leverages Angular’s internal DestroyRef. When called, it implicitly hooks into the destruction of the current component, directive, or service. It creates an internal mechanism (similar to the Subject pattern) to signal completion to the Observable.

Pros:

Minimal Boilerplate: No need to declare a Subject, no need to implement ngOnDestroy() yourself.
Angular-native: Integrates seamlessly with Angular’s lifecycle and injection system.
Highly Concise: Makes your code incredibly clean and focused on the business logic.
Robust and less prone to errors due to developer oversight.

Cons:

Only available in Angular v16 and later.
Tied to Angular’s injection context; cannot be used in plain TypeScript classes not managed by Angular’s DI.

Component Code Snippet:

// src/app/take-untildestroyed/user-list-auto-unsubscribe/user-list-auto-unsubscribe.component.ts
import { Component, OnInit, inject, DestroyRef } from '@angular/core'; // 1. Import 'inject'
import { takeUntilDestroyed } from '@angular/core/rxjs-interop'; // 2. Import takeUntilDestroyed
import { User } from '../../models/user';
import { UserService } from '../../services/user.service';

@Component({
  selector: 'app-user-list-auto-unsubscribe',
  templateUrl: './user-list-auto-unsubscribe.component.html',
  styleUrl: './user-list-auto-unsubscribe.component.scss'
})

export class UserListAutoUnsubscribeComponent implements OnInit {
  users: User[] = [];
  private destroyRef = inject(DestroyRef); // 3. Inject at class field place

  // 4. Inject the UserService (can also be done in constructor)
  private #userService = inject(UserService);

  ngOnInit(): void {
    this.#userService.getUsers().pipe(
      takeUntilDestroyed(this.destroyRef) //5. Pass DestroyRef manually
    ).subscribe(users => {
      this.users = users;
    });
  }
  // No ngOnDestroy() needed for subscription cleanup! Angular handles it.
  // Unless you have other non-RxJS cleanup logic.
}

Injection Context

takeUntilDestroyed() must be called within an injection context :

Let us understand a bit about Injection context in Angular.

Injection Context is when Angular’s dependency injection system is “active” and can resolve dependencies using inject().

For Example, A place where Class Fields reside, Constructor and Some Factory Functions

Note: An in-detailed article about Injection Context with examples will be covered as a part of this series.

Now let us see how we can use takeUntilDestoroyed for managing Subscriptions considering Injection Context.

import { Component, OnInit, inject, DestroyRef } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({
 selector: 'app-my-component',
 templateUrl: './my-component.component.html',
 styleUrls: ['./my-component.component.css']
})
export class MyComponent implements OnInit {
 private destroyRef = inject(DestroyRef); // Inject at class field place

 ngOnInit() {
   this.service.getData().pipe(
     takeUntilDestroyed(this.destroyRef) // Pass DestroyRef manually
   ).subscribe()
 }
}

Let us now understand a few important scenarios that we should be cautious about:

Using takeUntilDestoryed within ngOnInit / any Life Cycle Hooks

// injection context is not available)
// THIS WILL THROW AN ERROR: "inject() must be called in an injection context"
// because ngOnInit is a method, not a constructor or field initializer.
ngOnInit(): void {
  this.service.getData().pipe(
    takeUntilDestroyed()
  ).subscribe();
}

Using in any Method

// Won't work - called outside injection context
private setupSubscription(): void {
  this.service.getData().pipe(
    takeUntilDestroyed() // Error: Not in injection context
  ).subscribe();
}

The Fix: inject DestroyRef and pass it explicitly

private destroyRef = inject(DestroyRef);

private setupSubscription(): void {
  this.service.getData().pipe(
    takeUntilDestroyed(this.destroyRef) // Works
  ).subscribe();
}

Note: takeUntilDestroyed () needs to be called within an injection context where it can implicitly resolve DestroyRef , such as directly in the constructor or a class field initializer of the component/service, or by explicitly passing the injected DestroyRef instance.

Having established foundational strategies for subscription cleanup, we now turn our attention to a more advanced, yet equally important, consideration: handling nested subscriptions. This can present a unique set of challenges, but I’m here to guide you through a comprehensive, step-by-step methodology to effectively resolve them..

How do we use takeUntil / takeUntilDestroyed with Nested Subscriptions ?

You’re right, the idea of “nested subscriptions” might initially sound like it necessitates multiple takeUntil or takeUntilDestroyed applications. However, with RxJS's powerful flattening operators, the solution is elegantly straightforward.

Let’s tackle this step-by-step, focusing on a common use case: subscribing to Observables in parallel.

Imagine we need to display data from two independent API endpoints — say, a list of users and a list of products. We want to present this information to the user only once both API calls have successfully returned their data. This is a perfect job for RxJS’s forkJoin operator.

forkJoin takes a dictionary or array of Observables and waits for all of them to complete. Once they all complete, it emits a single value containing the last emitted value from each of the source Observables.

The Key Insight for Cleanup:

When using forkJoin (or switchMap, mergeMap, concatMap), takeUntil() or takeUntilDestroyed() is applied only once, on the outermost Observable pipe. The flattening operator (forkJoin in this case) is responsible for managing the lifecycle of the inner Observables it initiates. If the outer Observable completes (due to takeUntil/takeUntilDestroyed), forkJoin will cease its operation, effectively stopping any pending inner subscriptions it manages.

Generic Syntax:

forkJoin(
 { 
  outer: outerObservable$,
  inner: innerObservable$
 }
).pipe(takeUntilDestroyed()) // OR takeUntil(this.destroy$)
.subscribe({ 
 next: (data) => {
 // you data handling goes here
 }
})

takeUntil() usage for Nested Subscriptions:

This approach is suitable for all Angular versions and relies on the manual management of a Subject for the destroy signal.

Component Code Snippet:

// src/app/components/advanced/user-products-with-takeuntil.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject, forkJoin} from 'rxjs'; // Import forkJoin and EMPTY
import { takeUntil} from 'rxjs/operators'; // Import operators
import { UserService } from '../../services/user.service';
import { ProductService } from '../../services/product.service';
import { User } from '../../models/users';
import { Product } from '../../models/product';
@Component({
  selector: 'app-user-products-with-takeuntil',
  templateUrl: './user-products-with-takeuntil.component.html',
  styleUrl: './user-products-with-takeuntil.component.scss'
  `
})
export class UserProductsWithTakeUntilComponent implements OnInit, OnDestroy {
  users: User[] = [];
  products: Product[] = [];

  // The Subject used for the takeUntil cleanup pattern
  private #destroy$ = new Subject<void>();

  constructor(
    private #userService: UserService,
    private #productService: ProductService
  ) {}

  ngOnInit(): void {
    // 1. Use forkJoin to combine the Observables
    forkJoin({
      users: this.#userService.getUsers(),
      products: this.#productService.getProducts()
    }).pipe(
      // 2. Apply takeUntil ONLY HERE, on the outermost forkJoin Observable
      takeUntil(this.#destroy$), 
     ).subscribe({
      next: data => {
        this.users = data.users; 
        this.products = data.products;
        console.log('Combined data loaded successfully!');
      },
      error: err => {         
        console.error('Subscription error in forkJoin:', err);         
      },
      complete: () => {
        console.log('ForkJoin subscription completed.');
      }
    });
  }

  // 3. Signal the #destroy$ Subject on component destruction
  ngOnDestroy(): void {
    this.#destroy$.next();
    this.#destroy$.complete();
    console.log('UserProductsWithTakeUntilComponent: #destroy$ signaled for cleanup.');
  }
}

takeUntilDestroyed() usage for Nested Subscriptions:

This modern approach (Angular v16+) eliminates the Subject and ngOnDestroy() boilerplate, making your components even cleaner.

Component Code Snippet:

import { Component, OnInit, inject, DestroyRef } from '@angular/core'; // Import 'inject'
import { forkJoin, } from 'rxjs';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop'; // Import takeUntilDestroyed
import { UserService } from '../../services/user.service';
import { ProductService } from '../../services/product.service';
import { User } from '../../models/users';
import { Product } from '../../models/product';

@Component({
  selector: 'app-user-products-auto-unsubscribe',
   templateUrl: './user-products-auto-unsubscribe.component.html',
   styleUrl: './user-products-auto-unsubscribe.component.scss'
  `
})
export class UserProductsAutoDestroyComponent implements OnInit {
  private destroyRef = inject(DestroyRef); //1 Inject at class field place

   // 2. Inject services using the modern 'inject' function
  private #userService = inject(UserService);
  private #productService = inject(ProductService);

  ngOnInit(): void {
    forkJoin({
      users: this.#userService.getUsers(),
      products: this.#productService.getProducts()
    }).pipe(
      // 2. Apply takeUntilDestroyed ONLY HERE, on the outermost forkJoin Observable
      takeUntilDestroyed(this.destroyRef) // use destroyRef in takeUntilDestroyed
     ).subscribe({
      next: data => {   
        this.users = data.users; 
        this.products = data.products;
        console.log('Combined data loaded successfully!');
      },
      error: err => {
        console.error('Subscription error in forkJoin:', err);         
      },
      complete: () => {
        console.log('ForkJoin subscription completed.');
      }
    });
  }

  // No ngOnDestroy() or Subject needed! takeUntilDestroyed handles it implicitly.
}

As you can see, the elegance of RxJS operators like forkJoin combined with the power of takeUntil or takeUntilDestroyed() means you never have to manually manage nested subscriptions. The rule of "apply once, at the top" simplifies your code and dramatically reduces the risk of memory leaks in complex Observable chains.

Note: Always keep the takeUntil or takeUntilDestroyed after all the operators in a RxJS pipeline to avoid early unsubscriptions.

Why takeUntil / takeUntilDestroyed Should Be the Last Operator in Your RxJS Pipe ?

When working with RxJS in Angular, managing subscriptions is critical for preventing memory leaks. A common pattern for automatic unsubscription is using takeUntil or takeUntilDestroyed.

But here’s a subtle (and crucial) best practice:

Why Does It Matter?

If you place takeUntil too early in the pipeline, it may unsubscribe before other operators (like map, filter, or switchMap) get a chance to execute. This can lead to missed emissions or unexpected behavior.

Correct Usage

this.userService.getUsers().pipe(
  map(users => users.filter(u => u.active)),
  delay(500),
  takeUntilDestroyed() // Always at the end
).subscribe(users => {
  this.activeUsers = users;
});

Incorrect Usage

this.userService.getUsers().pipe(
  takeUntilDestroyed(), // Early exit from pipeline
  map(users => users.filter(u => u.active)),
  delay(500)
).subscribe();

From the above code snippet, we can say thatmap and delay might never receive emissions, or the stream could complete before these transformations are applied to all intended data.

Placing takeUntilDestroyed() early can cut off your stream before transformations or side-effects are complete — especially in async scenarios.

Generic Syntax Example:

forkJoin(
 { 
  outer: outerObservable$,
  inner: innerObservable$
 }
).pipe(
   map(resp => resp.isActive) 
  map(resp => resp.id > 20)
  takeUntilDestroyed() // <--- ALWAYS place at the END
)  
.subscribe({ 
 next: (data) => {
 // you data handling goes here
 }
})

Choosing Your Champion: Which Strategy is Best?

The “best” way depends on your Angular version and project context:

For Angular v16+ projects: takeUntilDestroyed() is the clear winner for its unparalleled conciseness and native integration. It's the most recommended approach.
For Angular projects before v16: takeUntil() with a Subject is the most robust and idiomatic RxJS solution. It offers a great balance of clarity and efficiency.
SubSink: A strong contender, especially for pre-v16 projects, providing a good balance of boilerplate reduction and explicit control without relying solely on RxJS operators.
Manual Subscription management: While fundamental, it's generally not recommended for most component-level subscriptions due to its verbosity and potential for errors. It might still be useful for very specific, tightly controlled scenarios or when dealing with highly dynamic, programmatic subscriptions outside of component lifecycles.

By understanding and applying these strategies, you’re not just preventing memory leaks; you’re writing cleaner, more resilient Angular applications that truly leverage the power of RxJS.

Source Code & Resources

🔗 Find the complete source code for this Angular Performance Series _, including all examples and demos from this article, on [_GitHub](https://github.com/Manishh09/ng-performance-insights/tree/master/projects/01-subscription-management)

📌 Love what you see? Don’t forget to give the repo a ⭐ star to stay updated with new examples and improvements! The README.md file will guide you on running the project.

Connect with Me!

Hi there! I’m Manish, a Senior Engineer passionate about building robust web applications and exploring the ever-evolving world of tech. I believe in learning and growing together.

If this article sparked your interest in modern Angular, software architecture, or just a tech chat, I’d love to connect with you!

🔗Follow me on LinkedInfor more discussions or contributing or just chat tech

Thank you for reading — and happy 🅰️ ngularing!

From NgModules to Standalone APIs: Unlocking the Future of Angular

Manish Boge — Fri, 27 Jun 2025 12:27:48 +0000

Unlocking the Module-Free Future of Angular with Standalone APIs

Introduction

Angular has consistently evolved, striving for simpler and more efficient ways to build robust applications. While NgModules have been the cornerstone of Angular’s architecture for years, the introduction of Standalone APIs marks a significant shift towards a more streamlined, module-free development experience.

This article will guide you through understanding, implementing, and leveraging these powerful new APIs.

The Rise of Standalone APIs in Angular

For years, NgModules were central to Angular’s architecture, organizing components, directives, pipes, and services. While effective, they eventually presented challenges: excessive boilerplate , hurdles for efficient tree-shaking , and a steep learning curve for new developers.

Standalone APIs emerged to address these issues. By allowing Angular artifacts (Components, Directives, Pipes) to be used independently of NgModules, standalone APIs offer:

Reduced boilerplate : Less code for declarations.
Improved tree-shaking : Clearer dependency graphs for better optimization.
Simplified learning : Easier to grasp Angular’s core concepts.
Enhanced developer experience : More intuitive organization and direct imports.

Here’s what we will deep dive into:

Standalone Components
Standalone Directives
Standalone Pipes
Bootstrapping Standalone App
Standalone App Structure
Providing Services in Standalone Components
Routing with Standalone Components
Lazy Loading with Standalone Components

Let’s dive into the world of Standalone APIs in Angular.

Understanding Standalone Components, Directives, and Pipes

The core of Standalone APIs lies in a new property: standalone: true.

This tells Angular: “This component doesn’t need a module.”

📌 Standalone Components

Standalone components are Angular components that can exist independently without being declared in any NgModule.

A typical component.ts file, which is a standalone, would be like below:

// src/app/components/hero-card.component.ts

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

@Component({
  selector: 'app-hero-card',
  standalone: true,
  imports: [],
  templateUrl: './hero-card.component.html',
  styleUrl: './hero-card.component.scss'
})
export class HeroCardComponent {
  name = 'Batman'
}

Generate with Angular CLI:

ng generate component hero-card --standalone

# or shorthand

ng g c hero-card --standalone

# generic command

ng g c your-component-name --standalone

Importing Dependencies

Standalone components must explicitly import other components, directives, modules, or pipes they use:

// src/app/components/hero-list.component.ts

import { Component } from '@angular/core';
import { NgIf } from '@angular/common';
import { NgFor } from '@angular/common';

@Component({
  selector: 'app-hero-list',
  standalone: true,
  template: `
    <section class="hero-list" aria-labelledby="hero-list-heading">
      <h2 id="hero-list-heading">Hero List</h2>      
      <ul *ngIf="heros.length">
          <li *ngFor="let hero of heroes" class="hero-item">
              <span class="hero-name">{{ hero.name }}</span>
              <span class="hero-separator" aria-hidden="true">-</span>
              <span class="hero-power">{{ hero.power }}</span>
          </li>
      </ul>
    </section>
  `,
  imports: [NgIf, NgFor]
})
export class HeroListComponent {

  // sample hero data
  heroes = [
    { id: 1, name: 'Superman', power: 'Flight' },
    { id: 2, name: 'Batman', power: 'Intellect' },
    { id: 3, name: 'WonderWoman', power: 'Strength' },
    { id: 4, name: 'Flash', power: 'Speed' }
  ];
}

We will specify the dependencies explicitly using _imports_array in component’s metadata section.

imports: [NgIf, NgFor]

💡Note : In this example, we’ve used the *ngIf , *ngFor directives to demonstrate how dependencies are imported in a standalone component. While Angular 17 does not have stable support for the new control flow syntax , we’ll continue with *ngIf , *ngFor for now. We’ll adapt it accordingly in Angular 18. This example focuses primarily on illustrating the import mechanism in standalone components.

Key takeaways for Standalone Components:

standalone: true: Marks it as a standalone component.
imports: Replaces the imports array of an NgModule. You directly import other standalone components, directives, pipes, or even entire NgModules that your component needs.
No declarations needed in any NgModule.

📌 Standalone Directives

Directives can also be created as standalone units, making it easy to encapsulate and share behavior.

A typical directive.ts file, which is a standalone, would be like below:

// src/app/directives/click-logger.directive.ts

import { Directive, HostListener } from '@angular/core';

@Directive({
  selector: '[appClickLogger]',
  standalone: true,
})
export class ClickLoggerDirective {
  @HostListener('click')
  logClick() {
    console.log('Element clicked!');
  }
}

Usage in Standalone Components

// src/app/components/hero-card.component.ts

import { Component, Input } from '@angular/core';
import { ClickLoggerDirective } from '../../directives/click-logger.directive';
import { NgIf } from '@angular/common';

@Component({
  selector: 'app-hero-card',
  standalone: true,
  imports: [NgIf, ClickLoggerDirective],
  template: `
    <div class="hero-card" *ngIf="hero" appClickLogger>
        <h3 class="hero-name">Name: {{ hero.name}}</h3>
        <p class="hero-power">Power: {{ hero.power }}</p>
    </div>
  `,
  styleUrl: './hero-card.component.scss'
})
export class HeroCardComponent { 
  hero = {
    id: 1, // Add comma here
    name: 'Batman',
    power: 'Intellect',
  }
}

Generate with Angular CLI

ng generate directive click-logger --standalone

# or shorthand

ng g d click-logger --standalone

# generic

ng g d your-directive-name --standalone

🧠 Use Case: Reusable UI Behavior

Think of tooltips, hover effects, click tracking — all perfect for sharing via standalone directives.

📌 Standalone Pipes

Pipes can also be defined as standalone. This makes it easy to share pure formatting logic without any module overhead.

A typical pipe.ts file, which is a standalone, would be like below:

// src/app/pipes/capitalize.pipe.ts

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'capitalize',
  standalone: true,
})
export class CapitalizePipe implements PipeTransform {
  transform(value: string): string {
    return value.charAt(0).toUpperCase() + value.slice(1);
  }
}

🧠 Using the Pipe in Templates

// src/app/components/hero-card.component.ts

import { Component, Input } from '@angular/core';
import { CapitalizePipe } from "../../pipes/capitalize.pipe";
import { NgIf } from '@angular/common';

@Component({
  selector: 'app-hero-card',
  standalone: true,
  imports: [NgIf, CapitalizePipe],
  template: `
    <div class="hero-card" *ngIf="hero">
        <h3 class="hero-name">Name: {{ hero.name | capitalize }}</h3>
        <p class="hero-power">Power: {{ hero.power }}</p>
    </div>
  `,
  styleUrl: './hero-card.component.scss'
})
export class HeroCardComponent { 
  hero = {
    id: 1
    name: 'Batman',
    power: 'Intellect',
  }
}

🛠 Generate with Angular CLI

ng generate pipe capitalize --standalone

# or shorthand

ng g p capitalize --standalone

# generic

ng g p your-pipe-name --standalone

🔁 Use Case: Shared Utility Logic

Whether it’s currency formatting, text transformation, or date manipulation — standalone pipes make code cleaner and easier to reuse.

🚀 Bootstrapping a Standalone App

With standalone components, the traditional AppModule is no longer strictly necessary for bootstrapping your application.

// src/main.ts

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient() // Provide HttpClient if your app uses it
    // Add other root-level services or providers here like provideRouter
  ]
})
.catch(err => console.error(err));

✅ No need for AppModule anymore!

📁 Standalone App Structure

One of the immediate benefits of embracing Standalone APIs is a significantly streamlined application structure. In a new standalone Angular project, you’ll notice the absence of traditional NgModule files, particularly the root app.module.ts.

Instead, your application’s entry point (main.ts) directly bootstraps a standalone root component, leveraging app.config.ts for its root-level configurations and providers. Your features are then organized with their own standalone components, directives, pipes, and services.

Here’s a typical simplified structure you might see:

src/
├── main.ts # Application entry point, bootstraps the app
└── app/
    ├── app.config.ts # Central place for root-level providers and configurations (e.g., routing)
    ├── app.component.ts # Your root standalone component
    ├── app.component.html
    ├── app.component.css
    ├── app.routes.ts # If you define your application routes separately, often imported by app.config.ts
    ├── services/ # Application-wide services (often provided via app.config.ts or providedIn: 'root')
    │ └── ...
    └── features/ # Folder for your feature-specific standalone components
        ├── feature-a/
        │ ├── feature-a.component.ts
        │ └── ...
        └── shared/ # Common standalone components/directives/pipes
            └── ...

Providing Services with Standalone APIs

In the module-less world, how do you provide services?

✅ providedIn: 'root' (recommended for singletons): This remains the primary way to provide application-wide singleton services.

// src/app/services/hero.service.ts
import { inject, Injectable } from '@angular/core'; 

@Injectable({
  providedIn: 'root' // This service is a singleton available throughout the app
})
export class HeroService { 
  name = 'Hero Service';
  private apiUrl = 'https://jsonplaceholder.typicode.com/users/1'; // Example API

  #http = inject(HttpClient);

  getUser(): Observable<any> {
    return this.http.get(this.apiUrl);
  }
}

✅ Component-level providers: You can still provide services at the component level using the providers array in the @Component decorator, which will make the service instance unique to that component and its children.

Lets visualize like for a feature, you have created a feature-component and a feature-service.

// src/app/some-feature/some-feature.component.ts
import { Component } from '@angular/core';
import { FeatureService } from './feature.service'; // A service specific to this feature

@Component({
  selector: 'app-some-feature',
  standalone: true,
  providers: [FeatureService], // Provided at component level
  template: `<p>Feature component works!</p>`
})
export class SomeFeatureComponent {
  constructor(private featureService: FeatureService) {}
}

// In service file
import { inject, Injectable } from '@angular/core';

@Injectable() // No providedIn:'root'
export class SomeFeatureComponent {
  constructor(private featureService: FeatureService) {}
}

💡Note : The @Injectable() decorator itself doesn't inherently define scope unless providedIn: 'root' or providedIn: 'platform' is used. When an @Injectable() service (without providedIn: 'root') is listed in a component's providers array (e.g., FeatureComponent), that service instance will be scoped to that component's injector only. This means a new instance of the FeatureService will be created specifically for FeatureComponent (and its children) each time FeatureComponent is instantiated, ensuring it's not a global singleton.

✅ Root-level providers via bootstrapApplication: As seen in main.ts, you can provide services directly when bootstrapping the application(Refer Bootstrapping Standalone App section above). This is ideal for global services like HttpClient.

Routing with Standalone Components

Routing also adapts gracefully to standalone APIs. You use new functions like provideRouter and importProvidersFrom to configure routing without relying on RouterModule.forRoot() in a traditional NgModule.

app.routes.ts structure:

// src/app/routes.ts

import { Routes } from '@angular/router';
import { UserProfileComponent } from './user-profile/user-profile.component';
import { HomeComponent } from './home/home.component'; // Assuming standalone
import { ContactComponent } from './contact/contact.component'; // Assuming standalone

export const APP_ROUTES: Routes = [
  { path: '', component: HomeComponent },
  { path: 'profile', component: UserProfileComponent },
  { path: 'contact', component: ContactComponent },
  { path: '**', redirectTo: '' } // Wildcard route
];

app.config.ts structure:

// src/app.config.ts

import { ApplicationConfig } from '@angular/core'; // New import
import { APP_ROUTES} from './app.routes'; // Your defined routes
import { provideRouter } from '@angular/router'; // New import
import { provideHttpClient } from '@angular/common/http'; // New import

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    provideRouter(APP_ROUTES) // Configure routing directly,
    provideHttpClient()
  ]
};

main.ts structure:

// src/main.ts (updated)

import { appConfig } from './app/app.config';
import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';
import { provideRouter } from '@angular/router'; // New import
import { UserProfileComponent } from './app/user-profile/user-profile.component';
import { APP_ROUTES } from './app/routes'; // Your defined routes

bootstrapApplication(UserProfileComponent, appConfig)
.catch(err => console.error(err));

Lazy-Loading With Standalone Components

We used to lazy load the feature modules using loadChildren in module based apps, but how can we do so in a standalone app ?

✅_loadComponet_comes into rescue here.

// src/app/app.routes.ts

{
  path: 'hero-list',
  loadComponent: () => import('./hero-list.component').then(c => c.HeroListComponent)
}

✅No loadChildren, no feature modules — just pure components.

🛡️Best Practices

To truly harness the power and benefits of Angular Standalone APIs, consider adopting these best practices:

📦 Prefer Granular Imports

With Standalone Components, Directives, and Pipes, you gain fine-grained control over your dependencies. Instead of importing entire NgModules, embrace the ability to import only what’s specifically needed for a particular standalone artifact.

For example:

// In your standalone component
imports: [
  CommonModule, // For NgIf, NgFor, etc. (if needed, or import them individually)
  MyStandaloneComponent,
  MyStandaloneDirective,
  MyStandalonePipe
]

This practice directly leads to:

✅ Smaller Bundles: Your final application package only includes the code it strictly requires.
✅ Superior Tree-Shaking: Build tools can more effectively identify and eliminate unused code, resulting in leaner, faster applications.
✅ Clearer Dependencies: It becomes immediately obvious what a component, directive, or pipe relies on, improving maintainability.

Embracing granular imports is a core philosophy of the standalone approach, reducing unnecessary boilerplate and optimizing performance.

🏁 Conclusion

Standalone APIs are the future of Angular. They:

✅ Remove unnecessary complexity

✅ Encourage better separation of concerns

✅ Make apps easier to test, lazy-load, and scale

As Angular continues to modernize, NgModules are no longer mandatory. You don’t need to refactor everything overnight — but embracing Standalone Components, Directives, and Pipes will lead to cleaner and more maintainable codebases.

✨ If you haven’t tried Angular’s Standalone APIs yet — now is the time.

Start with a small feature or a new component and experience the simplicity and clarity that Standalone APIs bring to Angular development.

💻 Source Code & Resources

🔗 Find the complete source code for this Angular 17 series , including all examples and demos from this article, on GitHub: angular-17-series repository.

📌 Love what you see? Don’t forget to give the repo a ⭐ star to stay updated with new examples and improvements! The README.md file will guide you on running the project.

All additional resources referenced in this article are readily available for hands-on practice and learning in the repository.

🚀 Up Next: Bridging the Gap — Migrating to Standalone APIs

We’ve learnt the ‘what’ of Standalone APIs. Now, let’s tackle the ‘how.’ The upcoming article will be an essential guide to seamlessly transitioning your existing Angular applications from NgModules to the cleaner, more efficient standalone architecture. Let’s say goodbye to NgModules and get ready to modernize your codebase!!

🤝Connect with Me!

Hi there! I’m Manish, a Senior Engineer passionate about building robust web applications and exploring the ever-evolving world of tech. I believe in learning and growing together.

If this article sparked your interest in modern Angular, software architecture, or just a tech chat, I’d love to connect with you!

🔗Follow me on LinkedIn for more discussions: Manish Boge

Thank you for reading — and happy 🅰️ ngularing!