Angular DI: Lazy Module Singleton Duplicated

A team I consulted for spent three weeks hunting a memory leak that was crashing their Angular dashboard every four hours in production. Root cause: they were instantiating a new HttpClient inside a component instead of injecting a shared service, spinning up a fresh connection pool on every component mount and never releasing it. Four hours was exactly how long it took to exhaust the browser's connection limit. The fix was twelve characters. The three weeks were pure ignorance of how Angular's dependency injection actually works.

Angular's architecture — components, modules, services, guards, interceptors — isn't ceremony for ceremony's sake. It's a hard answer to a real problem: how do you build a 200-screen enterprise app with a team of 15 developers without it collapsing into a dependency nightmare? Without this structure you get components doing HTTP calls, state management, DOM manipulation, and business logic all in one file. I've seen it. It looks like someone let an intern rewrite jQuery in TypeScript. The separation isn't optional architecture philosophy — it's load-bearing.

After working through this, you'll be able to wire up a component that consumes a singleton service, register it correctly in a feature module or standalone component, know exactly why providedIn: 'root' exists and when NOT to use it, implement HTTP interceptors for auth and error handling, protect routes with guards, and spot the most common architectural mistakes before they hit your code review. You'll also understand why lazy-loaded modules break service singletons if you don't know what you're doing — which is the interview question that separates people who've actually shipped Angular from people who've done the Tour of Heroes.

Why Angular DI Duplicates Lazy Module Singletons

Angular's dependency injection (DI) creates a separate injector for each lazy-loaded module. When a service is provided in a lazy module, that module's injector instantiates its own copy of the service — even if the same service was already provided in the root injector. This breaks the singleton contract: two different instances of the same service class exist, one in the root and one in the lazy module. The core mechanic is that Angular's injector hierarchy is tree-shaped, and each lazy module gets its own child injector. Services provided in the module metadata are registered in that child injector, not the root. This means any component or service inside that lazy module receives the module-local instance, while the rest of the app uses the root instance. In practice, this leads to state inconsistency, duplicated HTTP requests, and memory leaks. For example, a shared auth service holding a user token will have two separate tokens — the app might log out on one route but stay logged in on another. The rule of thumb: always provide singleton services in the root injector using providedIn: 'root'. Only provide in a lazy module if you explicitly need a new instance scoped to that module (e.g., a per-module cache).

Components: The Unit of UI — and Why They Must Stay Dumb

A component's only job is to display data and capture user intent. That's it. The moment a component starts making HTTP calls directly, manipulating global state, or containing business logic, you've built a monolith inside a framework that was designed to stop you from doing exactly that.

Before Angular, teams building large SPAs with frameworks like Backbone or early AngularJS (v1) routinely ended up with controllers that were thousands of lines long. Testing was impossible without spinning up the entire app. Reuse was a joke. A component-based architecture forces a hard boundary: the component owns the template and the interaction logic wired to that template, nothing else.

Every Angular component is defined by three things: a TypeScript class (the brain), a template (the face), and styles (the skin). The @Component decorator is what tells Angular's compiler to treat this class as a UI unit. The selector is how you stamp it into other templates. Change detection is how Angular knows when to re-render — and this is where most intermediate developers are still fuzzy. Angular's default change detection strategy (CheckAlways) rerenders the component on every event cycle. Switch to OnPush for any component receiving data via @Input and you cut unnecessary renders dramatically. On a dashboard with 80 components, this is the difference between 60fps and a janky mess.

Lifecycle hooks matter more than most tutorials admit. ngOnInit fires once after the first ngOnChanges — use it for initialization. ngOnChanges fires every time an @Input reference changes — use it to react to parent data updates, but keep it fast. ngAfterViewInit fires after the component's view and all child views are initialized — this is where you can safely access @ViewChild references. ngOnDestroy fires before the component is destroyed — this is your last chance to clean up subscriptions, timers, and event listeners. I've seen teams skip ngOnDestroy entirely and wonder why their app leaks memory. The hook exists for a reason. Use it.

import { Component, Input, Output, EventEmitter, ChangeDetectionStrategy, OnInit, OnChanges, SimpleChanges, OnDestroy } from '@angular/core';
import { OrderService } from '../services/order.service';
import { Order, OrderStatus } from '../models/order.model';

@Component({
  selector: 'app-order-summary',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div class="order-card" [class.order-card--urgent]="isUrgent">
      <h3>Order #{{ order.id }}</h3>
      <p>{{ order.customerName }} — {{ order.totalAmount | currency }}</p>
      <p class="status" [attr.data-status]="order.status">
        {{ order.status }}
      </p>
      <button
        *ngIf="order.status === OrderStatus.PENDING"
        (click)="confirmOrder()"
      >
        Confirm
      </button>
    </div>
  `
})
export class OrderSummaryComponent implements OnInit, OnChanges, OnDestroy {
  readonly OrderStatus = OrderStatus;

  @Input() order!: Order;
  @Output() orderConfirmed = new EventEmitter<string>();

  isUrgent = false;

  constructor(private readonly orderService: OrderService) {}

  ngOnChanges(changes: SimpleChanges): void {
    if (changes['order']) {
      this.isUrgent = this.orderService.isOrderUrgent(this.order);
    }
  }

  ngOnInit(): void {
    this.isUrgent = this.orderService.isOrderUrgent(this.order);
  }

  ngOnDestroy(): void {
    // Nothing to clean up here, but if this component had
    // subscriptions or timers, this is where they die.
  }

  confirmOrder(): void {
    this.orderConfirmed.emit(this.order.id);
  }
}

Services and Dependency Injection: Where Your Architecture Actually Lives

Services are where your business logic lives. Not in components, not in utility files, not in a god-object store — in injectable services with a single, clear responsibility. The reason Angular's DI system exists is that it solves a problem that's invisible when your app is small and catastrophic when it isn't: how do you ensure that the same instance of a stateful object is shared across dozens of components without those components knowing about each other?

providedIn: 'root' is the correct default for most services. It registers the service with the root injector, making it a true singleton for the app's lifetime. Angular's tree-shaking will also remove it from the bundle if nothing actually injects it — something the old providers: [] module pattern doesn't give you. The one time you don't want providedIn: 'root' is when you need component-level or lazy-module-level isolation: a form state service that should reset when a component is destroyed, or a polling service that should stop when a feature module is unloaded.

The DI system is hierarchical. Root injector at the top, module injectors in the middle, component injectors at the bottom. When a component asks for a dependency, Angular walks up the injector tree until it finds a provider. If you provide a service at the component level (via the component's providers array), each instance of that component gets its own service instance. I've used this deliberately for a shopping cart draft service that needed to be isolated per product modal — each modal got its own state, destroyed with the modal.

The inject() function (available since Angular 14) is the modern alternative to constructor injection. It's more composable — you can call it inside functions, computed properties, and conditional blocks. I've fully switched to inject() in standalone components. Constructor injection still works, but inject() is cleaner and plays better with TypeScript's strict mode.

import { Injectable, OnDestroy, inject } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { BehaviorSubject, Observable, Subject, timer } from 'rxjs';
import { switchMap, catchError, takeUntil, tap, retry, distinctUntilChanged } from 'rxjs/operators';
import { Order, OrderStatus } from '../models/order.model';
import { environment } from '../../environments/environment';

export interface OrderPollState {
  orders: Order[];
  lastUpdated: Date | null;
  error: string | null;
  isLoading: boolean;
}

const INITIAL_STATE: OrderPollState = {
  orders: [],
  lastUpdated: null,
  error: null,
  isLoading: false
};

@Injectable({ providedIn: 'root' })
export class OrderPollingService implements OnDestroy {
  private readonly http = inject(HttpClient);

  private readonly stateSubject = new BehaviorSubject<OrderPollState>(INITIAL_STATE);
  readonly state$: Observable<OrderPollState> = this.stateSubject.asObservable();

  private readonly destroy$ = new Subject<void>();
  private readonly POLL_INTERVAL_MS = 15_000;
  private readonly MAX_RETRIES = 3;
  private isPolling = false;

  startPolling(statusFilter: OrderStatus): void {
    if (this.isPolling) return;
    this.isPolling = true;

    timer(0, this.POLL_INTERVAL_MS)
      .pipe(
        switchMap(() => {
          this.patchState({ isLoading: true, error: null });
          return this.http.get<Order[]>(`${environment.apiBase}/orders?status=${statusFilter}`).pipe(
            retry(this.MAX_RETRIES),
            catchError((err: HttpErrorResponse) => {
              this.patchState({
                isLoading: false,
                error: `Order fetch failed: ${err.status} ${err.statusText}`
              });
              return [this.stateSubject.getValue().orders];
            })
          );
        }),
        tap((orders: Order[]) => {
          this.patchState({ orders, isLoading: false, lastUpdated: new Date(), error: null });
        }),
        distinctUntilChanged((prev, curr) => JSON.stringify(prev) === JSON.stringify(curr)),
        takeUntil(this.destroy$)
      )
      .subscribe();
  }

  stopPolling(): void {
    this.isPolling = false;
    this.destroy$.next();
  }

  private patchState(partial: Partial<OrderPollState>): void {
    this.stateSubject.next({ ...this.stateSubject.getValue(), ...partial });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

What Is Angular, Really? The Framework That Eats Complexity for Breakfast

Angular is a TypeScript-based framework built by Google for constructing client-side applications that don't fall apart when you add a second developer. It's not a library you glue together with duct tape — it's a full platform with its own router, HTTP client, forms module, and dependency injection system.

What sets Angular apart from React or Vue is the architecture. Angular enforces a structure from day one: components, services, modules, and a clear separation of concerns. That sounds boring until you inherit a codebase where every component talks directly to the database. Angular's guardrails prevent that nonsense.

Angular handles change detection for you. It uses zones to track asynchronous operations and update the DOM only when necessary. You don't write useEffect or setState — you declare bindings in the template, and the framework does the rest. For enterprise apps with complex state, this means less boilerplate and fewer bugs.

The trade-off? Angular has a steeper learning curve. But you get a complete toolkit for routing, forms, HTTP, testing, and animations out of the box. No chasing npm packages that break on every major release.

// io.thecodeforge — javascript tutorial

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

@Component({
  selector: 'app-root',
  template: `<h2>{{ title }}</h2>
             <p>Count: {{ clickCount }}</p>
             <button (click)="increment()">Add One</button>`
})
export class AppComponent {
  title = 'Angular in Action';
  clickCount = 0;

  increment(): void {
    this.clickCount++;
  }
}

Angular Versions: Why You Should Care About the Migration Tax

Angular has gone through major changes since its 2.0 release in 2016. The AngularJS (1.x) to Angular 2+ migration was a complete rewrite — different architecture, different language, different templating. Teams that stayed on AngularJS got stuck with security holes and library rot.

Today, Angular follows semantic versioning with a predictable release cadence. Major versions come every six months. The good news: since Angular 2, the API has been stable. Upgrading from version 15 to 18 is straightforward — usually an afternoon's work with ng update.

But here's the trap: Angular's modules (NgModules) were deprecated in favor of standalone components starting in version 14. If you're starting a new project today, don't generate modules. Use --standalone flag on ng generate. Otherwise you're writing boilerplate that the framework doesn't need.

Version 17 introduced signals — a reactive primitive that replaces zones for change detection in many cases. Version 18 added @for loops and @if blocks to templates. The framework is moving toward a more functional, less magic-driven approach. Learn signals now, because zones are on the chopping block.

Version 19 introduced the inject function over constructor injection for services. More concise, less boilerplate. Adopt it.

// io.thecodeforge — javascript tutorial

import { Component, inject } from '@angular/core';
import { UserService } from './services/user.service';

@Component({
  selector: 'app-user-profile',
  standalone: true,  // No NgModule needed
  template: `<p>{{ user.name }}</p>`
})
export class UserProfileComponent {
  private userService = inject(UserService);
  user = this.userService.getCurrentUser();
}

Prerequisites: What You Actually Need Before Angular Makes Sense

Before you touch Angular, you need to be comfortable with TypeScript. Not just "I saw a type annotation once" — you need to understand generics, decorators, interfaces, and the type system. Angular is TypeScript-first. If you fight the type system, Angular will fight you back.

Second: you need Node.js 18 or later and npm. Angular CLI is an npm package. Run npm install -g @angular/cli to install it globally. Then ng new my-app scaffolds a project. If you've never used a terminal, fix that first.

Third: understand the difference between a component, a service, and a module. Components display data. Services contain business logic and data fetching. Modules (if you must use them) group components and services together. Get this wrong, and you'll end up with components making HTTP calls directly — a security and testability nightmare.

Fourth: learn RxJS observables. Angular uses them for HTTP, router events, and form value changes. You don't need to be an RxJS guru, but you must understand .subscribe(), pipe(), and map(). Without it, your async code will leak memory.

Finally: you need a code editor with TypeScript support. VS Code with the Angular Language Service extension gives you template type-checking and autocomplete. Don't code Angular in Notepad.

// io.thecodeforge — javascript tutorial

# Check Node version
node --version
# Should output v18.x or higher

# Install Angular CLI globally
npm install -g @angular/cli

# Scaffold new project with standalone components
ng new enterprise-app --standalone --style=scss

# Serve the app
cd enterprise-app
ng serve