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! 👍🏼

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

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.

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.

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.

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.

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

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

Well, prior to React 19 it wasn't an override, as props could never contain a ref. Now it is. Which is the core reason why this change exists in React. Agree that it should be removed in Mui if it exists going forward, but it doesn't change anything for upstream and the issue remains so long as forwardRef is used within React 19.

Alternatively, maybe something like that could work?

I'm happy with that solution, and yes considering the facts it's likely React won't fix it, so we can go ahead with that.