[Data Grid] Avoid <GridRoot /> double-render pass on mount in SPA mode

[lauri865]

• I have followed (at least) the PR section of the contributing guide.

Currently, GridRoot double-renders in all cases on mount to prevent SSR. In SPA-mode this is irrelevant, and can be avoided with the help of useSyncExternalStore, since there's no server snapshot in SPA-mode, the gird will be mounted directly. As a result, the rootRef becomes immediately available on first mount in SPAs, as one would expect.

Adds a new dependency use-sync-external-store to make it backwards compatible with React 17. Charts and treeview have the same dependency.

Changelog

Breaking changes

• The filteredRowsLookup object of the filter state does not contain true values anymore. If the row is filtered out, the value is false. Otherwise, the row id is not present in the object.
  This change only impacts you if you relied on filteredRowsLookup to get ids of filtered rows. In this case,use gridDataRowIdsSelector selector to get row ids and check filteredRowsLookup for false values:

   const filteredRowsLookup = gridFilteredRowsLookupSelector(apiRef);
  -const filteredRowIds = Object.keys(filteredRowsLookup).filter((rowId) => filteredRowsLookup[rowId] === true);
  +const rowIds = gridDataRowIdsSelector(apiRef);
  +const filteredRowIds = rowIds.filter((rowId) => filteredRowsLookup[rowId] !== false);

[mui-bot]

Deploy preview: https://deploy-preview-15648--material-ui-x.netlify.app/

Updated pages:

• docs/data/migration/migration-data-grid-v7/migration-data-grid-v7.md

Generated by 🚫 dangerJS against e45e07a

[lauri865]

Side-benefit is also probably more robust tests if the Datagrid is mounted on the first pass.

[romgrk]

Code LGTM, we can merge once the tests are passing.

[lauri865]

I have no idea how to fix the last failing test. Either it's a symptom of column headers updated more times now or just a bad test. But I lack understanding why it was previously expected that the warning message will be output exactly twice.

Edit: discovered some areas to improve around mounting / state initialization

[lauri865]

Also fixes an annoying flicker coming out of loading state. It's probably the root cause of a layout shift I once reported with autoHeight grid coming out of loading state.

Before:
https://github.com/user-attachments/assets/1a68b2de-f2fd-4ef4-a93d-215d044e35b7

After:
https://github.com/user-attachments/assets/cfe55012-092a-429d-a79d-75e243124d10

[lauri865]

Tests should be passing now. 4 was the right amount of warnings for this approach, 1 extra pass (+1 warning for header/row each = 2+2 = 4) that doesn't even flush to the dom, so I think we're good there.

Curiously, after this optimisation:

mui-x/packages/x-data-grid/src/hooks/features/columns/useGridColumns.tsx

Lines 400 to 412 in 5ca918f

	const hasFlexColumns = gridVisibleColumnDefinitionsSelector(apiRef).some(
	(col) => col.flex && col.flex > 0,
	);
	if (!hasFlexColumns) {
	return;
	}
	setGridColumnsState(
	hydrateColumnsWidth(
	gridColumnsStateSelector(apiRef.current.state),
	apiRef.current.getRootDimensions(),
	),
	);

This test started failing:

mui-x/packages/x-data-grid-premium/src/tests/aggregation.DataGridPremium.test.tsx

Lines 145 to 150 in 1a079e1

	it('should correctly restore the column when changing from aggregated to non-aggregated', () => {
	const { setProps } = render(<Test aggregationModel={{ id: 'max' }} />);
	expect(getColumnHeaderCell(0, 0).textContent).to.equal('idmax');
	setProps({ aggregationModel: {} });
	expect(getColumnHeaderCell(0, 0).textContent).to.equal('id');
	});

The only reason I can think of is that aggregations didn't explicitly trigger column updates, but somehow were piggybacking on viewportInnerSizeChange event for taking care of it. Adding an explicit updateColumns call fixed it. Is there any other explanation to it?

If that's the case, then I suppose there was a bug whereby columns didn't clear when there was no totals row visible, as viewPortInnerSize would only change if there was a pinned row.

[lauri865]

I've also observed that issue, and I've mentionned that we could get rid of the perf cost of running all the selectors during scrolling by switching from selector-based reactivity to event-based reactivity (conceptual notes in this gist). That's of course a general solution to selector-based reactivity's issues, but yours could provide more immediate gains. I'm wary though of adding quick workarounds, the codebase already has a fair amount of tech debt to resolve.

That's also why getCellParams was a single bag-of-data selector previously, it allowed to keep the number of selector-listeners as low as possible.

Thanks for the additional context, sounds like an interesting approach. I thought about alternative approaches as well, but after some quick measurements, I was more leaning towards the number of selectors not being an issue in and of itself – they're pretty performant. It's only an issue when the state updates a) with high frequency and b) we're rendering based on each state change / where every last ms counts. The only two areas I can think of are renderContext and potentially dimensions (if not throttled, but even that shouldn't be much of an issue anymore).

So, that leaves only renderContext (at least to my current understanding, let me know if you can think of anything else). Unless we can measurably show an issue, then maybe it's not worth refactoring too much of the code base, only to measurably gain in one pretty contained use case.

[cherniavskii]

A minor downside is that the data grid won't properly react to scrollbar size change (e.g. on Mac "Show scroll bars: Automatically => Always).
It's faster though, so let's keep it like this.

[cherniavskii]

I spotted 2 places like this where we were still assigning true values, so I narrowed the type in 3449782 (#15648)

[lauri865]

Good catch, thanks. Fixed a few checks as well on that front, and tests are passing again for all cases.

[lauri865]

Since streamlining state updates made detailPanel tests fail, I was forced to fix some measurement propagation issues on that front as well. Now there's no layout shifts when opening up detail panels anymore, and further reduced state updates:

Before:

master-detail-before.mp4

After:

master-detail-after.mp4

[cherniavskii]

Same change for visibleRowsLookup as previously with filteredRowsLookup.

[MBilalShafi]

Since we don't store true values now, does it make sense to simplify the type further? It could be slightly better performance wise, and more aligned DX wise, as the filteredRowsLookup no longer stores the "filtered" rows, rather it stores "excluded" ones.

For consistency, a similar concept could be applied on the visible rows (invisibleRows: Set<GridRowId>), column visibility model (hiddenColumns: Set<GridColDef['field']>), etc.

Suggested change

	filteredRowsLookup: Record<GridRowId, false>;
	excludedRows: Set<GridRowId>;

[cherniavskii]

Changing Record to Set/Map won't necessarily be faster – see #9120 (comment)

[romgrk]

See #10068 (comment) and #10068 (comment). I think the change is good and has potential for improvement, but I didn't have the bandwidth to investigate it more.

[MBilalShafi]

Suggested change

	* If a row is not registered in this lookup, it is filtered.
	* All the rows are filtered except the ones registered in this lookup with `false` values.

[romgrk]

If this value isn't used, can we use -1 as an empty value marker instead? It will avoid changing the shape of those objects.

[romgrk]

useGridApiEventHandler doesn't need stable functions (with useEventCallback), it already replicates the same logic that useEventCallback implements.

[romgrk]

This file should probably be under the features/dimensions folder, to keep with existing conventions. You can add an export { ... } from '.../features/dimensions/dimensionSelectors' where appropriate to expose these from @mui/x-data-grid/internals.

[romgrk]

You said there is a name conflict with another selector called gridColumnsTotalWidthSelector. Are the two selectors returning the same value, calculated differently? If so, would it be appropriate to remove one of them?

Otherwise, could we rename the other one and keep the short name for this one?

[romgrk]

We could also use -1 for the type.

[romgrk]

LGTM beyond the small comments above.