MatTable Virtual Scrolling & MatSort: Preventing Concurrent Data Requests

Answer the question first

When a MatTable is combined with MatSort and CDK virtual scrolling, each viewport change can trigger a new HTTP request. The most reliable way to avoid overlapping calls is to let the application layer cancel the previous request as soon as a new sort or scroll event arrives. In practice this is achieved with switchMap (or mergeMap(..., 1)) inside the DataSource.connect() stream, optionally preceded by a small debounceTime to coalesce rapid user actions. Angular Material itself does not provide a default concurrency strategy because its DataSource API is intentionally minimal and meant to be adapted to the specific server contract of the app.

Why switchMap is the safest choice

• It automatically unsubscribes from the previous inner observable, which aborts the HTTP request in Angular’s HttpClient.
• It guarantees that only the latest response is processed, preventing out‑of‑order rendering.
• It keeps the code concise and aligns with the reactive pattern encouraged by Angular.

Optional debounce for server‑rate‑limit safety

If the backend has strict rate limits or you want to reduce the number of round‑trips during fast scrolling, add a debounceTime(200) before switchMap. The trade‑off is a brief visual lag: the table will show a loading indicator until the debounced request completes.

Implementation sketch

export class VirtualScrollDataSource extends DataSource<MyItem> {
  private readonly pageSize$ = new BehaviorSubject<number>(50);
  private readonly sort$ = new BehaviorSubject<Sort>({active: '', direction: ''});
  private readonly scroll$ = new Subject<number>(); // index of first visible row

  constructor(private readonly api: MyApiService) {
    super();
  }

  connect(): Observable<MyItem[]> {
    return combineLatest([this.pageSize$, this.sort$, this.scroll$]).pipe(
      debounceTime(200), // optional coalescing
      switchMap(([size, sort, index]) => {
        this.loading = true;
        return this.api.fetchPage({size, sort, offset: index}).pipe(
          tap(() => this.loading = false),
          catchError(err => {
            this.loading = false;
            return of([]); // or a fallback
          })
        );
      })
    );
  }

  disconnect() {}
}

Evaluating trade‑offs

• Responsiveness: switchMap alone gives instant feedback; adding debounceTime introduces a ~200 ms delay.
• Server load: Debounce reduces burst traffic but may still send a request per scroll page. switchMap alone can send many requests if the user scrolls extremely fast.
• UX consistency: Maintain a loading flag so the UI shows a spinner or placeholder until the latest data arrives, avoiding flicker from stale rows.
• Cancellation side‑effects: Even though the client cancels the request, the server may still finish processing it. If this is a concern, coordinate with backend to honour AbortSignal or use a short‑lived token.

Should Angular Material provide a default?

Because DataSource is an extensible interface, a one‑size‑fits‑all concurrency policy would constrain developers who need custom caching, optimistic updates, or server‑specific cancellation semantics. Therefore, keeping concurrency control in the application layer preserves flexibility while giving developers a clear pattern (switchMap + optional debounce).

Next steps for your project

1. Wrap your MatSort and scroll events into observables (e.g., sort.sortChange, cdkVirtualScrollViewport.scrolledIndexChange).
2. Feed those streams into a combined source as shown above.
3. Test with a simulated 2‑second network delay to confirm that no flicker occurs and that a new request cancels the previous one.
4. Measure the number of concurrent requests in DevTools’ Network tab to verify that only the latest request remains pending.

With this pattern you get deterministic, cancel‑safe data loading that scales from simple tables to complex, high‑volume grids.