Observables & RxJS

import { debounceTime, distinctUntilChanged } from 'rxjs/operators';

// Search input with debounce
@Component({
  template: '<input (input)="onSearch($event)" />'
})
export class SearchComponent implements OnInit {
  private searchSubject = new Subject<string>();

  ngOnInit() {
    this.searchSubject.pipe(
      debounceTime(300),          // wait 300ms after last keystroke
      distinctUntilChanged(),      // skip if same value as previous
      switchMap(term => this.searchService.search(term))
    ).subscribe(results => this.results = results);
  }

  onSearch(event: Event) {
    const term = (event.target as HTMLInputElement).value;
    this.searchSubject.next(term);
  }
}

Why it matters: Tests understanding of performance optimization for user input. Shows you can prevent unnecessary API calls.

Real applications: Search boxes that query on every keystroke would be slow. autocomplete fields, live filtering with 300ms debounce reduces server load.

Common mistakes: Developers don't debounce rapid user input causing excessive API calls. They use throttle when they should use debounce. They debounce without distinctUntilChanged still making redundant calls.

import { catchError, of, EMPTY } from 'rxjs';

// Return a default value on error
this.http.get<User[]>('/api/users').pipe(
  catchError(error => {
    console.error('Failed to load users:', error);
    return of([]); // return empty array as fallback
  })
).subscribe(users => this.users = users);

// Rethrow with custom error
this.http.get('/api/data').pipe(
  catchError(error => {
    if (error.status === 401) {
      this.router.navigate(['/login']);
      return EMPTY; // complete without emitting
    }
    return throwError(() => new Error('Server error'));
  })
).subscribe();

// Retry then catch
this.http.get('/api/data').pipe(
  retry(2),
  catchError(err => of({ error: true, message: err.message }))
).subscribe();

Why it matters: Tests understanding of error handling in reactive chains. Shows you can build resilient async operations.

Real applications: HTTP errors return cached data or empty array. 401 Unauthorized redirects to login. Network retries fail then show offline message.

Common mistakes: Developers don't catch errors letting observables fail silently. They forget catchError must return an Observable causing type errors. They place catchError before retry, catching each retry instead of final failure.

// switchMap: cancel previous (search)
search$.pipe(switchMap(term => api.search(term)));

// mergeMap: run all concurrently (parallel uploads)
files$.pipe(mergeMap(file => api.upload(file)));

// concatMap: run one after another (ordered saves)
saves$.pipe(concatMap(data => api.save(data)));

// exhaustMap: ignore new until done (login button)
click$.pipe(exhaustMap(() => api.login(credentials)));

Why it matters: Tests understanding of higher-order Observable operators and concurrency control. Shows you know when to use each flattening strategy.

Real applications: switchMap for search (cancel old), mergeMap for file uploads (all at once), concatMap for sequential saves, exhaustMap for login (prevent double-click).

Common mistakes: Developers mix up which operator to use causing wrong behavior. They use mergeMap everywhere creating race conditions. They don't understand the concurrency models.

// Manual subscribe: must handle cleanup yourself
export class UserComponent implements OnDestroy {
  private sub!: Subscription;
  users: User[] = [];
  ngOnInit() {
    this.sub = this.userService.getUsers()
      .subscribe(users => this.users = users);
  }
  ngOnDestroy() { this.sub.unsubscribe(); }
}

// Async pipe: automatic subscribe and cleanup
// Template: <li *ngFor="let user of users$ | async">{{ user.name }}</li>
users$ = this.userService.getUsers();

Why it matters: Tests understanding of Angular template integration and memory leak prevention. Shows you can write clean, maintainable templates.

Real applications: Displaying user lists, showing loading states, rendering data from multiple sources with | async in templates.

Common mistakes: Developers subscribe in component class when async pipe would work. They forget to unsubscribe when using subscribe manually. They use multiple async pipes on same observable causing multiple subscriptions.

import { forkJoin } from 'rxjs';

// Wait for all requests to complete
forkJoin({
  user: this.http.get<User>('/api/user/1'),
  orders: this.http.get<Order[]>('/api/orders'),
  prefs: this.http.get<Prefs>('/api/preferences')
}).subscribe(({ user, orders, prefs }) => {
  this.user = user;
  this.orders = orders;
  this.preferences = prefs;
});

Why it matters: Tests understanding of combining asynchronous operations. Shows you can manage multiple concurrent requests efficiently.

Real applications: Loading user data, orders, and preferences simultaneously. Page initialization that needs multiple independent API calls.

Common mistakes: Developers use forkJoin with never-completing observables. They don't handle one failure meaning everything fails. They use combineLatest when they meant forkJoin.

import { of, from, interval } from 'rxjs';

// of: emit values and complete
of(1, 2, 3).subscribe(v => console.log(v)); // 1, 2, 3, complete

// from: convert array or promise
from([10, 20, 30]).subscribe(v => console.log(v)); // 10, 20, 30
from(fetch('/api/data')).subscribe(resp => console.log(resp));

// interval: emit number every N ms
interval(1000).pipe(take(5)).subscribe(v => console.log(v));
// 0, 1, 2, 3, 4 (one per second)

Why it matters: Tests understanding of Observable creation patterns. Shows you know different ways to generate observables from data sources.

Real applications: of() for hardcoded option lists, from() for array conversions, interval() for polling or heartbeat timers.

Common mistakes: Developers use of() with arrays and don't understand it spreads arguments. They forget to take() from interval causing infinite emissions. They use from() for single values when of() is simpler.

// takeUntil pattern
private destroy$ = new Subject<void>();

ngOnInit() {
  this.data$.pipe(takeUntil(this.destroy$)).subscribe();
  this.events$.pipe(takeUntil(this.destroy$)).subscribe();
}
ngOnDestroy() { this.destroy$.next(); this.destroy$.complete(); }

// Angular 16+: takeUntilDestroyed
constructor() {
  this.data$.pipe(takeUntilDestroyed()).subscribe();
}

Why it matters: Tests understanding of memory management in long-lived applications. Shows you can prevent performance degradation over time.

Real applications: Apps with hundreds of components created/destroyed over user session. Memory leaks compound causing slowdowns and browser crashes.

Common mistakes: Developers don't track subscriptions causing memory leaks. They create multiple destroy$ subjects instead of one per component. They don't test for leaks with Chrome DevTools heap snapshots.