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.

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();
  }
}