Dependency Injection in Angular

Explore dependency injection in Angular—a design pattern that allows an object to receive its dependencies from an external source rather than creating them itself.

Angular, a powerful and opinionated framework for building dynamic single-page applications, provides developers with a structured environment to create maintainable and scalable frontend code. Its architecture encourages concepts like component-driven development, enabling expressive template control, reactive state tracking and efficient data management, among other benefits.

In this article, we’ll explore dependency injection—a core concept that simplifies dependency management, enhances modularity and improves the testability of Angular applications.

The Problem: Managing Dependencies Without DI

Imagine a scenario where we’re building a large web application with multiple components that rely on shared logic. For example, consider a receipt component that needs to calculate total costs by reusing an existing calculator utility. Without a formal mechanism like dependency injection, we might write code like this:

class ReceiptComponent {
  private calculator: Calculator;
  totalCost: number;

  constructor() {
    this.calculator = new Calculator();
    this.totalCost = this.calculator.add(50, 25);
  }
}

class Calculator {
  add(x: number, y: number): number {
    return x + y;
  }
}

In the above code example, the ReceiptComponent directly instantiates the Calculator class within its constructor. This approach hardwires the dependency, meaning the component is responsible for creating and managing the Calculator, rather than simply relying on it to perform its function.

While this works for small-scale applications, some issues can arise as the codebase grows:

1. Tight coupling – The ReceiptComponent is tightly coupled to the Calculator class, making it difficult to replace or extend the calculator’s functionality without modifying the component.
2. Lack of testability – Testing the ReceiptComponent in isolation becomes challenging because we cannot easily mock the Calculator class. Mocking or replacing it with a test double isn’t straightforward since the ReceiptComponent handles instantiation directly.
3. Code duplication – If multiple components require the Calculator, each will create its own instance, wasting resources and making maintenance more cumbersome.

Ideally, we would decouple the ReceiptComponent from the Calculator, allowing the component to declare its need for a calculator without managing its creation. This is where dependency injection comes into play.

Understanding Dependency Injection

Dependency injection (DI) is a design pattern that allows an object to receive its dependencies from an external source rather than creating them itself. The central idea is to separate object construction from its behavior, promoting flexibility, testability and reusability.

In the context of DI, there are three key roles:

• Dependency provider – Supplies the dependencies (e.g., a service class or factory function)
• Dependency consumer – The object that requires the dependency (e.g., a component)
• Injector – The mechanism that connects providers and consumers by delivering dependencies where they’re needed

Using DI, our earlier example can be refactored to decouple the ReceiptComponent from the Calculator:

class ReceiptComponent {
  totalCost: number;

  constructor(private calculator: Calculator) {
    this.totalCost = this.calculator.add(50, 25);
  }
}

class Calculator {
  add(x: number, y: number): number {
    return x + y;
  }
}

In this setup, the Calculator is no longer instantiated directly within the ReceiptComponent. Instead, it is provided externally via the constructor. The constructor(private calculator: Calculator) syntax declares the dependency and allows an external injector to supply the appropriate Calculator instance. This approach brings several advantages:

• Flexibility – The ReceiptComponent can work with any object adhering to the Calculator interface, simplifying replacements or extensions.
• Testability – The Calculator can easily be mocked during testing, enabling the ReceiptComponent to be tested independently.
• Reusability – A single Calculator instance can be shared across multiple components, reducing redundancy and improving efficiency.

By offloading responsibility for providing dependencies, the ReceiptComponent focuses solely on its functionality, resulting in cleaner and more maintainable architecture.

Dependency Injection in Angular

Angular’s DI system builds on this concept, providing a robust framework for managing dependencies. This enables consistent modularity, efficiency and flexibility in application design.

Services in Angular

Services are at the heart of Angular’s DI system. They are reusable pieces of logic that can be injected into components, directives and other services. Angular provides the @Injectable decorator to mark a class as a service that can participate in the DI system.

Here’s an example of a simple service:

import { Injectable } from "@angular/core";

@Injectable({ providedIn: "root" })
export class CalculatorService {
  add(x: number, y: number): number {
    return x + y;
  }
}

The providedIn: 'root' metadata means that the service is available throughout the application as a singleton. So a single instance of the CalculatorService will be shared across all components and services that inject it.

Injecting Services into Components

To use a service in a component, we inject it via the component’s constructor. Angular automatically provides the required service instance:

import { Component } from "@angular/core";
import { CalculatorService } from "./calculator.service";

@Component({
  selector: "app-receipt",
  template: "<h1>The total is {{ totalCost }}</h1>",
})
export class ReceiptComponent {
  totalCost: number;

  constructor(private calculator: CalculatorService) {
    this.totalCost = this.calculator.add(50, 25);
  }
}

In the above example, Angular’s DI system resolves the dependency and injects the shared instance of CalculatorService into the ReceiptComponent. This approach keeps the component focused on its functionality while delegating logic like calculations to the service.

Component-Level Dependency Injection

Alternatively, Angular allows us to scope services to specific components by using the providers field in the @Component decorator. This approach means that a new instance of the service is created for each instance of the component:

import { Component } from "@angular/core";
import { CalculatorService } from "./calculator.service";

@Component({
  selector: "app-receipt",
  template: "<h1>The total is {{ totalCost }}</h1>",
  providers: [CalculatorService],
})
export class ReceiptComponent {
  totalCost: number;

  constructor(private calculator: CalculatorService) {
    this.totalCost = this.calculator.add(50, 25);
  }
}

When provided at the component level, the CalculatorService is limited to the ReceiptComponent and its child components. Each new instance of ReceiptComponent will receive its own isolated instance of the service.

The choice between providedIn: 'root' and component-level providers depends on the use case:

• providedIn: 'root' is preferred for stateless or globally shared services, such as logging utilities or HTTP clients, as it reduces duplication and leverages tree-shaking for unused services.
• Component-level providers are ideal when the service needs to maintain state specific to a component instance or when isolation between components is required.

In general, using providedIn: 'root' is the default and most efficient approach for global services, while component-level providers offer flexibility for more specific use cases.

More Advanced Configuration

Angular’s DI system supports advanced configurations to address complex scenarios. For example, we can use factory providers to dynamically configure service behavior based on runtime data or other dependencies.

Here’s an example service, ConfigurableService, which accepts an API endpoint as a dependency via its constructor:

import { Injectable } from "@angular/core";

@Injectable()
export class ConfigurableService {
  constructor(private apiEndpoint: string) {}

  getData() {
    return `Fetching data from ${this.apiEndpoint}`;
  }
}

To provide the required API endpoint dynamically at runtime, we can use an InjectionToken and a factory provider to supply the value:

import { InjectionToken, NgModule } from "@angular/core";

const API_ENDPOINT = new InjectionToken<string>("API_ENDPOINT");
const configurableServiceFactory = (endpoint: string) =>
  new ConfigurableService(endpoint);

@NgModule({
  providers: [
    { provide: API_ENDPOINT, useValue: "https://api.example.com" },
    {
      provide: ConfigurableService,
      useFactory: configurableServiceFactory,
      deps: [API_ENDPOINT],
    },
  ],
})
export class AppModule {}

In the above code, Angular’s DI system demonstrates how to configure a service dynamically using an InjectionToken, a factory provider and runtime values. The ConfigurableService relies on the API_ENDPOINT token to receive its dependency. Angular resolves this token to the value https://api.example.com and passes it to the factory function, which constructs and provides the service instance.

This approach enables the service to adapt to runtime configurations, such as environment-specific settings while maintaining modular and maintainable code.

Factory providers are just one example of an advanced configuration in Angular’s DI system. Angular’s DI also supports other advanced configurations, such as hierarchical injectors for scoping services to specific modules or components, multi-providers to register multiple implementations of the same token, and injection contexts for creating services dynamically during specific lifecycle events. These configurations enable developers to fine-tune dependency management to suit complex application architectures and provide modularity and flexibility where needed.

Wrap-up

Angular’s dependency injection system is a cornerstone of its framework, enabling developers to build flexible, maintainable and testable applications. By understanding how DI works and leveraging Angular’s DI features, we can write cleaner code and create more scalable architectures.

For more detailed information on Angular’s DI system, refer to the official Angular documentation on dependency injection.