[data grid] React 19 - everything that depends on `GridRootPropsContext` re-renders on every state change (or root re-render) if the ref prop is present

[lauri865]

Search keywords

N/A

Latest version

• I have tested the latest version

Affected products

Data Grid

Steps to reproduce

Steps:

1. Generic – [React 19] ForwardRef props are not referentially stable, breaking downstream memoizations facebook/react#31613
2. Datagrid specific – [DataGrid] Improve resize performance #15549 (comment)

Current behavior

Read more about on the links above.

Found in the midst of another PR, so opening an issue so it doesn't go overlooked, especially now that there's official React 19 support and React 19 is stable.

Worth noting that it can also affect instances where developers don't actually provide a ref, but have created an abstracted component over the Datagrid which passes forward the ref prop by explicitly naming it as ref={ref} even if ref={undefined}. This was the case for us. Which means that the potential share of users affected is much wider.

Not sure if the problem affects any other areas of the DataGrid as well, but probably not as critical as this.

cc @arminmeh, since you worked on the React 19 support

[michelengelen]

Thanks for opening it @lauri865 ... you're adopting R19 pretty swiftly, very nice!

I'll forward it to the team and add it to the board! 👍🏼

[cherniavskii]

It looks like there's nothing we can do about it on our side until it's fixed in React 😕

[lauri865]

A breaking fix on Datagrid's end in v8 could be to have a prop rootRef or gridRef for backwards compatibility (i.e. skipping the forwardRef wrapping), yet enabling the use of the ref prop with React 19 still. The only other alternative is to change how rootProps get memoized, but that's maybe not the preferred solution.

I wouldn't hold my breath waiting after React 🙊

Fwiw, we're just running a locally patched version of the Datagrid that strips out the forwardRef wrapper.

[romgrk]

If React doesn't fix it, then yes the rootRef approach could be nice. Meanwhile we could maybe do something with objectShallowCompare to preserve props & prevent re-renders. But I'd wait a bit to see what they want to do upstream.

[lauri865]

Alternatively, maybe something like that could work?

const forwardRefBackwardsCompatible = <T, P>(
  render: React.ForwardRefRenderFunction<T, P>,
) => {
  if (React.version.startsWith("19")) {
    const Component = (props: any) => render(props, props.ref ?? null);
    return Component;
  }

  return React.forwardRef(render);
};

If it works, it'd probably be more performant than creating a new object on every render in React 19 and then trying to memoize it / shallow compare it.

[lauri865]

And a reason why I wouldn't count on an upstream change is that the fix would likely mean breaking the below pattern:

const Test = React.forwardRef((props, refProp) => {
  const internalRef = React.useRef(null);
  const ref = useMergedRef(refProp, internalRef);
  return <div ref={ref} {...props}>Test</div>;
})

<Test ref={React.useRef()} />

Internal ref would be never be set now in React 19, because props are spread after the ref and props contain the ref prop as well. Since React 19 is a stable release now, making that change would be breaking. And frankly, between the two, one breaks memoization in an edge case, the other can alter rendering altogether or break components, so you can guess which of the two bads they'll opt for.

Still, it should come with a big fat red warning label though, as the new behaviour is very unclear and undocumented.

[dmytro-shchurov]

And a reason why I wouldn't count on an upstream change is that the fix would likely mean breaking the below pattern:

I would call this an antipattern, cause this is quite naive to specify overrides prior to a spread operator. If such exists in mui code it must be refactored IMHO