Using RxJS switchMap to Cancel Stale Requests in Real‑Time Search

The problem: stale requests slowing down autocomplete

When a user types quickly, each keystroke can trigger a network request. If the UI waits for every response, older calls may arrive after newer ones, causing flicker or wasted bandwidth.

Why switchMap solves it

switchMap maps each source value to an inner observable and automatically unsubscribes from the previous inner observable when a new source value arrives. This guarantees that only the projection from the most recent source value stays alive.

Worked example: simulating keystrokes

Run the following code in a Node console (requires npm i rxjs) or in a browser console with RxJS loaded.

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

// Simulate keystrokes every 100 ms
const key$ = interval(100).pipe(map(i => `key${i}`));

// Debounce rapid input, ignore repeats, then switch to a request
const response$ = key$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(input => {
    // Pretend a request that takes 200 ms
    return new Promise(resolve => setTimeout(() => resolve(`response for ${input}`), 200));
  })
);

response$.subscribe(console.log);

Only the latest keystroke’s response appears in the log. Replace switchMap with mergeMap and you will see overlapping responses, confirming the cancellation behavior.

Trade‑off: discarded intermediate results

If your application needs to log every request or show a loading indicator for each attempt, switchMap will silently drop earlier inner observables. In those cases, consider concatMap (queues) or mergeMap (runs concurrently) and handle ordering yourself.

How to verify the cancellation in practice

1. Install RxJS v7: npm i rxjs.
2. Save the example above to test.js and run node test.js.
3. Observe the console: you should see a single line per debounced interval, e.g., “response for key5”, “response for key8”, etc.
4. To see the difference, edit the file, change switchMap to mergeMap, rerun, and note multiple lines appearing for the same time window.

No special permissions are required; the code runs in the current user process. The only risk is that a long‑running inner observable will be cancelled abruptly, which could leave server‑side work unfinished if the request is not designed to be abortable.

Actionable takeaway

Use switchMap when you only care about the latest result from a rapid source—such as type‑ahead search, autocomplete, or real‑time filtering. Combine it with debounceTime and distinctUntilChanged to reduce unnecessary work, and remember that earlier inner observables are cancelled, so ensure any side‑effects are safe to abort.