Does Material‑UI DataGrid getRows require manual AbortController handling to prevent race conditions under concurrent scrolling?

Answer

In MUI v5/v6 the getRows callback already receives an AbortSignal as its second argument. If your implementation forwards that signal to any cancellable fetch or promise, the grid will automatically cancel the previous request when a new one starts. Therefore, manual AbortController logic is only required when you ignore the provided signal or use a non‑cancellable API.

Likely Explanation

When a user scrolls rapidly, the DataGrid issues many getRows calls. Internally it creates a fresh AbortController for each call and passes the signal to getRows. If you propagate that signal to fetch or any library that accepts it, the earlier request is aborted as soon as a new scroll event triggers another call, preventing stale data from arriving out of order.

Confirmed Facts

• In the stable API (v5 & v6) getRows signature is (params, signal).
• Passing signal to fetch(url, { signal }) cancels the request when the grid starts a new one.
• If signal is ignored or a non‑abortable promise is used, earlier responses can overwrite newer ones, causing flicker.

Practical Steps

1. Verify the signature: Open the DataGrid source for your installed version and confirm that getRows receives a second argument named signal.
2. Forward the signal: In your implementation, use the signal in any cancellable API.

   async function getRows(params, signal) {
     const response = await fetch('/api/rows', {
       method: 'POST',
       body: JSON.stringify(params),
       signal, // <- forward
     });
     const data = await response.json();
     return data;
   }
   

3. Handle non‑abortable libraries: Wrap them in an abortable promise or cancel manually.

   function abortableFetch(url, options, signal) {
     return new Promise((resolve, reject) => {
       const controller = new AbortController();
       signal.addEventListener('abort', () => controller.abort());
       fetch(url, { ...options, signal: controller.signal })
         .then(resolve)
         .catch(reject);
     });
   }
   

4. Fallback for browsers without AbortController: Use a polyfill (e.g., abortcontroller-polyfill) or fall back to a simple request that ignores aborts but accepts the risk of stale data.

Diagnostic Question

Does your current getRows implementation already forward the signal to the underlying network call?

Key Takeaway

With the stable API you do not need to create a new AbortController; just forward the supplied signal. Manual cancellation is only necessary when you ignore that signal or use an API that doesn’t support aborting.