mergeMap vs concatMap vs exhaustMap in Angular - Visual Side-by-Side Comparison

Concept Flow - mergeMap vs concatMap vs exhaustMap

Source Observable emits value

↓

Operator handles inner Observable

↓

Emit values from inner Observables

↓

Output Observable emits merged results

When the source emits, each operator decides how to handle inner Observables: mergeMap runs all concurrently, concatMap queues them, exhaustMap ignores new while busy.

Execution Sample

Angular

source$.pipe(
  mergeMap(val => innerObservable(val))
).subscribe(console.log);

This code runs all inner Observables at once, emitting their results as they come.

Execution Table

Step	Source Emit	Operator	Inner Observable Action	Output Emitted
1	A	mergeMap	Start innerObservable(A)	Value A1
2	B	mergeMap	Start innerObservable(B) concurrently	Value B1
3	A inner emits again	mergeMap	Emit innerObservable(A) value	Value A2
4	B inner emits again	mergeMap	Emit innerObservable(B) value	Value B2
5	C	concatMap	Queue innerObservable(C)	No output yet
6	A inner completes	concatMap	Start innerObservable(C)	Value C1
7	D	concatMap	Queue innerObservable(D)	Value C2
8	C inner completes	concatMap	Start innerObservable(D)	Value D1
9	E	exhaustMap	Ignore new since inner active	No output
10	D inner completes	exhaustMap	No action: ignored emissions (like E) are dropped	No output
11	F	exhaustMap	Start innerObservable(F)	Value F1
12	F inner emits again	exhaustMap	Emit innerObservable(F) value	Value F2
13	No more source emits	-	-	Complete output
14	End	-	-	All inner Observables completed

💡 Execution stops when source completes and all inner Observables finish emitting.

Variable Tracker

Variable	Start	After Step 2	After Step 6	After Step 10	Final
Active inner Observables (mergeMap)	0	2 (A,B)	1 (B,C)	0	0
Queued inner Observables (concatMap)	0	0	1 (D)	0	0
Active inner Observable (exhaustMap)	0	0	0	0	0

Key Moments - 3 Insights

Why does concatMap wait before starting the next inner Observable?

concatMap queues new inner Observables until the current one completes, as shown in execution_table rows 5-8 where C waits until A completes.

Why does exhaustMap ignore new source emissions while an inner Observable is active?

exhaustMap ignores (drops) new source values if an inner Observable is running, shown in row 9 where E is ignored while D active. Ignored emissions are not processed later.

How does mergeMap handle multiple inner Observables?

mergeMap runs all inner Observables concurrently, emitting their values as they arrive, as seen in rows 1-4.

Visual Quiz - 3 Questions

Look at the execution_table at step 5, what does concatMap do when source emits 'C'?

A Starts innerObservable(C) immediately

B Queues innerObservable(C) to start later

C Ignores the emission 'C'

D Cancels previous innerObservable

💡 Hint

Check execution_table row 5 where concatMap queues innerObservable(C) without output.

At which step does exhaustMap start processing innerObservable(F)?

A Step 9

B Step 10

C Step 11

D Step 12

💡 Hint

Look at execution_table row 11 where exhaustMap starts innerObservable(F) after previous completes.

According to variable_tracker, how many active inner Observables does mergeMap have after step 2?

A 2

B 0

C 1

D 3

💡 Hint

See variable_tracker row for mergeMap active inner Observables after step 2.

Concept Snapshot

mergeMap: runs all inner Observables at once, outputs as they come.
concatMap: queues inner Observables, runs one at a time in order.
exhaustMap: ignores new source values while inner Observable is active.
Use mergeMap for parallel, concatMap for ordered, exhaustMap to ignore overlaps.

Full Transcript

This visual execution compares three Angular RxJS operators: mergeMap, concatMap, and exhaustMap. When the source Observable emits a value, each operator decides how to handle the inner Observable created from that value. mergeMap runs all inner Observables concurrently, emitting their results as they arrive. concatMap queues inner Observables and runs them one after another, waiting for each to complete before starting the next. exhaustMap ignores new source emissions if an inner Observable is still active, only starting a new one after the current completes. The execution table shows step-by-step how each operator behaves with source emissions and inner Observable outputs. The variable tracker highlights how many inner Observables are active or queued at key steps. Key moments clarify common confusions about queuing, ignoring, and concurrency. The visual quiz tests understanding by referencing specific steps and variable states. The snapshot summarizes when to use each operator based on concurrency and ordering needs.