Summary

We implement most of our Datagrids while persisting state between navigations for better UX. It's all good implemented in userland, and no complaints there in general.

However, restoring scroll is extremely painful in userland, and it's impossible to achieve a performant outcome there, because the initial renderContext is flushSynced, and there's no way to override that. So you end up with reflows and unnecessary component renders (even if they don't end up in the DOM, e.g. canvas elements end up still be drawn and have to be trashed if they don't end up in the viewport) on remounting the grid.

Examples

What works but is slow / subject to reflows / unnecessary computations:

apiRef.current.subscribeEvent("viewportInnerSizeChange", ...
// 1. Set up MutationObserver
// 2. Check for whether `.MuiDataGrid-virtualScroller` exists
// 3. Restore scroll

Slightly more performant, but less widely supported option (based on heuristics rather than explictly waiting for the virtualScroll to enter the DOM):

React.useLayoutEffect(() => {
  queueMicrotask(() => {
      const rootRef = apiRef.current.rootElementRef?.current;
      const scrollContainer = rootRef?.querySelector(
        ".MuiDataGrid-virtualScroller",
      );
      if (!scrollContainer) return;

      if (gridState.scroll!.top) {
        scrollContainer.scrollTop = gridState.scroll!.top;
      }
      if (gridState.scroll!.left) {
        scrollContainer.scrollLeft = gridState.scroll!.left;
      }
  });
}, []);

Even more performant option (almost there, but could be better):

React.useLayoutEffect(() => {
  queueMicrotask(() => {
      const rootRef = apiRef.current.rootElementRef?.current;
      const scrollContainer = rootRef?.querySelector(
        ".MuiDataGrid-virtualScroller",
      );
      if (!scrollContainer) return;
      
      // we make sure that the renderContext matches the scrollPosition before updating the scroll
      flushSync(() => {
        apiRef.current.setState((state) => ({
          ...state,
          virtualization: {
            ...state.virtualization,
            renderContext: gridState.scroll?.renderContext!,
          },
        }));
      });

      if (gridState.scroll!.top) {
        scrollContainer.scrollTop = gridState.scroll!.top;
      }
      if (gridState.scroll!.left) {
        scrollContainer.scrollLeft = gridState.scroll!.left;
      }
  });
}, []);

Almost as snappy as without scroll restoration, but expensive components are still called and flushSync needs to wait for another flushSync to complete from what I understand, so we still lose a frame or a few and end up with higher CPU use.

Motivation

The source of the issue seems to be – the following call to updateRenderContext cannot be intercepted or overridden:
https://github.com/mui/mui-x/blob/f613377c4740cb7ebda19d4b3a81cf27be8e0a01/packages/x-data-grid/src/hooks/features/virtualization/useGridVirtualScroller.tsx#L580C3-L591C6

FlushSynced:

Maybe a stopgap solution could be if scrollPositionChange could prevent the default behaviour (e.g. could prevent the first event and first invocation of updateRenderContext).

Restoring scroll is difficult in userland, subject to performance woes and regardless of the approach, ends up in spaghetti code that may not work in future versions.

Related: #5071 and #6411
Opened a new issue as these discussions are stale and based on old versions.

Search keywords: restore scroll