These RxJS flattening operators control how Angular handles overlapping async work (HTTP calls, saves, clicks, search). switchMap cancels previous, mergeMap runs in parallel, concatMap queues sequentially, and exhaustMap ignores new triggers while busy. Choosing the right one prevents race conditions, double submits, and UI glitches.
switchMap vs mergeMap vs exhaustMap vs concatMap: When Would You Use Each in Angular?
Preparing for interviews?
Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.
Quick Answer
Answer
Core idea
All four operators take a stream of “triggers” (typing, clicks, route params) and map each trigger to an inner Observable (usually an HTTP call). The difference is what they do when a new trigger arrives before the previous one finishes:switchMap = cancel old, keep latestmergeMap = run all in parallelconcatMap = queue one by oneexhaustMap = ignore new until current completes
Operator | What it does with overlap | Best Angular use-cases | Common bug it prevents (or causes) |
|---|---|---|---|
| Cancels the previous inner Observable when a new value arrives (keeps only the latest). | Search/autocomplete, typeahead filtering, route param changes where you only want the latest request. | Prevents stale UI from older responses. (But can cancel work you actually needed.) |
| Runs all inner Observables concurrently (no cancellation). | Fire-and-forget analytics, loading independent resources in parallel, batch requests where order doesn’t matter. | Can cause race conditions (older response overwrites newer state) if you update shared UI state. |
| Queues triggers and runs inner Observables sequentially (preserves order). | Save queue, uploading files in order, sequential steps where order matters and every action must run. | Prevents out-of-order state. (But can feel “slow” under rapid triggers.) |
| Ignores new triggers while an inner Observable is active (first wins until completion). | Login button, “Submit” button, “Pay now”, any action where double submit must be blocked. | Prevents double submits. (But can drop user actions if they click again too soon.) |
Interview mental model
Ask yourself: when triggers happen fast, do you want latest wins, all run, in order, or ignore spam?
You want… | Pick | Why |
|---|---|---|
Only the latest result (cancel previous) |
| Typing fast should not show older results. |
All requests to run concurrently |
| Independent work can finish in any order. |
Every action to run, but strictly in order |
| Queue saves/commands to avoid state corruption. |
Block spam clicks until completion |
| Prevent double submit / duplicate payments. |
Real Angular examples
TYPESCRIPT
import { Component, ChangeDetectionStrategy, inject } from '@angular/core';
import { FormControl } from '@angular/forms';
import { debounceTime, distinctUntilChanged, switchMap, mergeMap, concatMap, exhaustMap, tap, filter } from 'rxjs/operators';
import { Observable, of, Subject } from 'rxjs';
class Api {
search(term: string): Observable<string[]> { return of([term]); }
save(payload: unknown): Observable<void> { return of(void 0); }
analytics(event: string): Observable<void> { return of(void 0); }
}
@Component({
selector: 'app-demo',
template: ``,
changeDetection: ChangeDetectionStrategy.OnPush
})
export class DemoComponent {
private api = inject(Api);
// 1) Typeahead search: latest wins => switchMap
searchControl = new FormControl('');
searchResults$ = this.searchControl.valueChanges.pipe(
debounceTime(250),
distinctUntilChanged(),
switchMap(term => this.api.search(String(term ?? '')))
);
// 2) Submit button: block double submit => exhaustMap
private submitClicks$ = new Subject<void>();
submitting$ = this.submitClicks$.pipe(
exhaustMap(() => this.api.save({ /* form value */ }))
);
// 3) Sequential saves: preserve order => concatMap
private saveQueue$ = new Subject<unknown>();
saveInOrder$ = this.saveQueue$.pipe(
concatMap(payload => this.api.save(payload))
);
// 4) Parallel work: independent calls => mergeMap
private events$ = new Subject<string>();
trackEvents$ = this.events$.pipe(
mergeMap(name => this.api.analytics(name))
);
}
Senior pitfall #1: race conditions with mergeMap
If you use mergeMap for UI state that should reflect the latest request, you can get out-of-order overwrites: request A starts, then request B starts, B returns first (UI shows B), then A returns later and overwrites the UI with stale data. That’s why typeahead/search is almost always switchMap.
Senior pitfall #2: thinking switchMap “cancels the server”switchMap unsubscribes from the previous inner Observable. For Angular HttpClient, unsubscribing typically aborts the underlying request (via browser APIs). But if the server already processed it, cancellation won’t rewind time—it mainly prevents your app from handling stale results.
Senior pitfall #3: exhaustMap dropping user intentexhaustMap ignores new triggers while busy. Great for preventing double submits, but if you need “last click wins after current finishes”, use a different strategy (e.g., disable button in UI, or use switchMap with careful semantics).
Angular scenario | Best operator | Reason |
|---|---|---|
Search field / autocomplete |
| Only latest input should win; old requests must be ignored. |
Submit / payment / login button |
| Block duplicates until completion. |
Queueing writes (save draft events, ordered commands) |
| Guarantees order and prevents overlapping state changes. |
Load independent resources (A, B, C in parallel) |
| Parallelism improves speed; ordering doesn’t matter. |
Summary
switchMap = latest wins (search, route changes). mergeMap = run all in parallel (independent work). concatMap = queue sequentially (ordered saves). exhaustMap = ignore spam until done (submit buttons). The “correct” choice is the one that matches how you want to handle overlapping triggers.
Similar questions
Guides