Angular State Architecture: Signals, RxJS, and Change Detection

Angular Training: Model UI State with Signals and RxJS

A useful rule in Angular training is to keep synchronous, local UI state in signals and keep time-based or external work in RxJS. A search box value is a signal; debouncing it, cancelling an HTTP request, and representing loading or failure are an RxJS pipeline. This division prevents a common failure mode: subscribing inside a component method and manually trying to reset loading, data, and error fields in every callback.

import { Injectable, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { toObservable, toSignal } from '@angular/core/rxjs-interop';
import { catchError, debounceTime, distinctUntilChanged, map, of, startWith, switchMap } from 'rxjs';

type UsersState =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'ready'; users: User[] }
  | { kind: 'error'; message: string };

@Injectable({ providedIn: 'root' })
export class UserSearchStore {
  private readonly http = inject(HttpClient);
  readonly query = signal('');

  readonly state = toSignal(
    toObservable(this.query).pipe(
      debounceTime(250),
      distinctUntilChanged(),
      switchMap(query => {
        if (!query.trim()) return of({ kind: 'idle' } as const);

        return this.http.get<User[]>('/api/users', { params: { q: query } }).pipe(
          map(users => ({ kind: 'ready', users } as const)),
          startWith({ kind: 'loading' } as const),
          catchError(() => of({ kind: 'error', message: 'Search failed' } as const))
        );
      })
    ),
    { initialValue: { kind: 'idle' } as UsersState }
  );
}

The discriminated union is not decoration: it makes impossible combinations such as loading: true with stale error text unrepresentable. In the template, branch on state().kind with @switch rather than maintaining separate booleans. An experienced TypeScript training exercise should also cover the error path: without catchError, an error from the observable is rethrown when Angular reads the signal, which can turn one failed request into a render-time exception.

Profile Angular Change Detection Before Rewriting Components

For an enterprise frontend framework, render performance should be measured per interaction rather than inferred from component size. Record a typing or row-selection interaction in Angular DevTools Profiler, then compare the number of checked components and total change-detection time before and after a change. Repeat against a production build, for example ng build --configuration production followed by serving the generated output locally; development-mode checks distort absolute timings.

import { ChangeDetectionStrategy, Component, signal } from '@angular/core';

@Component({
  selector: 'app-user-table',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @for (user of users(); track user.id) {
      <button (click)="toggle(user.id)">
        {{ user.name }}: {{ user.enabled ? 'enabled' : 'disabled' }}
      </button>
    }
  `
})
export class UserTableComponent {
  readonly users = signal<User[]>([]);

  toggle(id: string) {
    this.users.update(users =>
      users.map(user =>
        user.id === id ? { ...user, enabled: !user.enabled } : user
      )
    );
  }
}

OnPush does not mean a component never updates. When a template reads a signal, Angular records that dependency and marks the component when that signal changes. The important detail is identity: mutating an object inside this.users() and then retaining the same array reference is easy to miss, while the immutable map update gives both the signal and list rendering a clear change boundary. The track user.id expression is equally important: without it, inserting or filtering rows can cause Angular to associate an existing DOM node with the wrong logical item, especially when a row contains focused inputs.

RxJS Search Pipelines: Make Cancellation Explicit

Use switchMap for type-ahead requests, not mergeMap. Each new query unsubscribes from the prior HTTP observable; with Angular's HttpClient this propagates to the underlying browser request where supported, and—more importantly—prevents an older response from publishing after a newer query. Test the behavior under artificial latency in browser DevTools by throttling the network, typing ann, then immediately replacing it with anna; only the latter result should render.

readonly results = toSignal(
  toObservable(this.query).pipe(
    map(value => value.trim()),
    debounceTime(250),
    distinctUntilChanged(),
    filter(value => value.length >= 2),
    switchMap(value =>
      this.http.get<User[]>('/api/users', { params: { q: value } })
    )
  ),
  { initialValue: [] as User[] }
);

Do not add shareReplay(1) automatically to every RxJS HTTP stream. A stream owned by one component usually does not need cross-subscriber caching, while a service-level cache needs an explicit key and invalidation rule. For example, cache user details by ID in a Map<string, Observable<User>>, delete the entry after a successful mutation, and choose whether failed requests should remain retryable. The subtle bug is caching a request whose authorization context or tenant header changed: the cache key must include every input that changes the server response, not merely the URL path.

Use Angular CLI Budgets and Lazy Boundaries as Guardrails

Treat initial JavaScript size as a CI contract. Configure Angular CLI budgets in the production configuration, run ng build --configuration production --stats-json in CI, and fail the pull request when the initial bundle exceeds an agreed limit. The exact threshold is product-specific, but choosing one from a measured baseline—for example, baseline plus 10%—turns bundle growth into a reviewable decision instead of a surprise on a slow mobile connection.

{
  "projects": {
    "portal": {
      "architect": {
        "build": {
          "configurations": {
            "production": {
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "250kb",
                  "maximumError": "300kb"
                }
              ]
            }
          }
        }
      }
    }
  }
}

Split routes at business boundaries, not at arbitrary folder boundaries. A reporting screen with charting dependencies is a good lazy candidate because users who never navigate there should not download its code during initial navigation. Use loadComponent and inspect the generated chunks with a stats viewer such as webpack-bundle-analyzer when supported by your builder output, or the Angular CLI build report otherwise.

export const routes: Routes = [
  {
    path: 'reports',
    loadComponent: () =>
      import('./reports/reports.page').then(m => m.ReportsPage),
    providers: [ReportsApi]
  }
];

Route-level providers create a route injector, which is useful when ReportsApi must be discarded after leaving the feature. The nuance is that a nearest route-level provider shadows a root provider of the same token; accidental duplication can produce two caches with different data. In a serious Angular course, verify this by logging instance IDs from both injection sites before introducing route-scoped providers.

Frequently Asked Questions

When should Angular training teach signals versus RxJS?

Teach signals for synchronous state read by templates, such as selected IDs, filters, and derived totals. Teach RxJS for event streams, timers, WebSocket messages, retries, and HTTP cancellation. Bridge at the boundary with toSignal or toObservable; do not expose a writable signal and an independently writable Subject for the same state.

How do I profile an Angular component with Angular CLI builds?

Create a production build with `ng build --configuration production`, serve the output, and record a real interaction in Angular DevTools Profiler. Compare checked-component count and elapsed change-detection work before and after one targeted change. Add `--stats-json` when investigating bundle composition and inspect the output with a compatible stats viewer.

Why does RxJS switchMap fix stale Angular search results?

switchMap unsubscribes from the previous inner request when a new query arrives. That prevents a slow response for an older query from emitting into the active result stream after a newer request has started. Combine it with debounceTime and distinctUntilChanged so identical or rapid keystrokes do not create unnecessary requests.

Is Angular a suitable enterprise frontend framework for large teams?

It is practical when teams enforce concrete boundaries: standalone route lazy loading, typed state unions, Angular CLI bundle budgets, and component tests around API contracts. The framework alone does not prevent architectural drift; route-scoped providers, shared caches, and generated client types need explicit ownership rules.