Using switchMap for Latest-Wins Search in RxJS

The overlapping‑request problem

A type‑ahead input can emit a new value every few milliseconds while the user types. If each keystroke triggers an HTTP request, a slow response for an earlier term may arrive after a faster response for a later term. The UI would then show stale data, waste bandwidth, and keep unnecessary subscriptions alive.

Why switchMap gives the latest‑wins behavior

Treat the input as a single stream of intent. By flattening that stream with switchMap, every time a new value arrives the previous inner observable is unsubscribed. This makes the cancellation explicit: only the inner observable belonging to the most recent value can push results downstream.

A practical pipeline

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

function search(term: string): Observable {
  // replace with your actual HTTP call that returns an Observable
  return http.get(`/api/search?q=${encodeURIComponent(term)}`);
}

const results$ = query$.pipe(
  debounceTime(300),            // ignore rapid bursts
  distinctUntilChanged(),       // skip if the term didn’t actually change
  switchMap(term => term ? search(term) : of([])),
  catchError(() => of([]))      // keep the stream alive after a failed request
);

The debounceTime and distinctUntilChanged guards reduce unnecessary work, while catchError returns a fallback observable so the outer stream does not terminate.

Worked marble example

Using RxJS TestScheduler we can verify that only the latest inner subscription survives.

import { TestScheduler } from 'rxjs/testing';

const scheduler = new TestScheduler((actual, expected) => {
  expect(actual).toEqual(expected);
});

scheduler.run(({ cold, expectObservable }) => {
  // query$ emits 'rx' at 10ms, 'rxjs' at 20ms
  const query$ = cold('-a---b|', { a: 'rx', b: 'rxjs' });
  // simulate search: each term delays 30ms then returns an array with the term
  const search = (term: string) => cold('-d|', { d: [term] }).delay(30);

  const results = query$.pipe(
    debounceTime(0), distinctUntilChanged(),
    switchMap(term => term ? search(term) : of([])),
    catchError(() => of([]))
  );

  expectObservable(results).toBe('-(c|)', {
    c: ['rxjs']   // only the result from the second emission survives
  });
});

The marble diagram shows that the inner observable for 'rx' is unsubscribed when 'rxjs' arrives, so its delayed value never reaches the final subscriber.

Trade‑offs and alternatives

• mergeMap – keeps every inner subscription; use when you need all responses (e.g., firing multiple independent requests).
• concatMap – queues inner observables; preserves order but delays later requests until earlier ones finish.
• exhaustMap – ignores new values while an inner observable is active; useful for actions that should not be interrupted (e.g., a login flow).

Pick the flattening operator that matches the cancellation semantics you want. If you later change the operator without updating tests, the request‑cancellation behavior can silently shift.

Verification in a real application

1. Instrument the request factory to log subscribe and unsubscribe calls.
2. Type a quick sequence (e.g., "a", "ab", "abc") and confirm that only the log for the final term shows an unsubscribe after the request completes.
3. Use browser DevTools Network tab or a mock server to see whether abandoned requests are actually canceled; note that many HTTP libraries do not abort the underlying socket when the Observable is unsubscribed.

If you need guaranteed abort, wrap the HTTP call in a mechanism that supports cancellation (e.g., AbortController in fetch) and tie it to the subscription lifecycle.

Actionable closing

Define the desired cancellation semantics first, then select the flattening operator that expresses them. Encode that choice in a small marble or TestScheduler test so future refactors cannot accidentally alter the request‑winning behavior.