react icon indicating copy to clipboard operation
react copied to clipboard

[React 19] Removal of `ReactDOM.findDOMNode`

Open migueloller opened this issue 9 months ago • 5 comments

Summary

React 19 removes the deprecated ReactDOM.findDOMNode utility. While this utility was an escape hatch and refs are the recommended way to access the DOM, in certain cases, findDOMNode was the only solution using a React API. Let me explain.

I maintain @makeswift/runtime, hosted at https://github.com/makeswift/makeswift, which is the SDK for Makeswift, a visual editor for Next.js and React. Users of Makeswift can register React components with Makeswift so that they're available to drop in the Makeswift builder. We leverage findDOMNode so that we can find registered component's DOM nodes when users don't use forwardRef (or in React 19, handle the ref prop).

Here's how we use findDOMNode: https://github.com/makeswift/makeswift/blob/58f425cf522c23af4a71b2f07a7625b252c59a5e/packages/runtime/src/runtimes/react/find-dom-node.tsx

While we could force users to use forwardRef, a very important product philosophy of Makeswift is that we meet developers where they're at. We don't want them to have to make any changes to their components. Their components shouldn't know about Makeswift, and if they weren't forwarding a ref then introducing Makeswift shouldn't make them do so.

In the same vein, we also don't want to alter the DOM in any way, so alternatives like using a div with display: contents are a no-go for us.

Ideally, we'd be able to use refs with a React.Fragment, but that API doesn't exist yet. This leaves us with the alternative of requiring users to forward refs in their components or reaching for React internals, like React DevTools does to associate a DOM node with rendered components. We'd like to avoid using internals but without findDOMNode, that might be what we have to do since we'd rather do that than force users to have to forward refs.

Would love to hear thoughts and guidance on what the expectation is for library maintainers to do for this use case that can't be handled with refs. Is the suggested approach to use React internals like React DevTools does? Or perhaps support for refs in React.Fragment is on the way?

Thanks!

migueloller avatar Apr 26 '24 14:04 migueloller

Prior discussion: https://github.com/facebook/react/issues/14357

eps1lon avatar Apr 26 '24 16:04 eps1lon

Prior discussion: #14357

Thanks for pointing out that discussion @eps1lon. It seems that the visual building case is a common use case. That being said, that issue seems to be quite old and there's not a ton of activity from the React team on that. Do you have any insight on ways to move forward?

I like the idea proposed there about extracting findDOMNode to a separate package, like was done with prop types, so that it's not in react-dom but library maintainers can still leverage it if refs don't cut it.

migueloller avatar Apr 26 '24 17:04 migueloller

https://react.dev/reference/react-dom/findDOMNode#adding-a-wrapper-div-element

What's troubling me is this: I have an 'Impr' component, which is used as follows:

<Impr><div/></Impr/>

I need to find the root of the child element directly in 'Impr' using findDomNode. I don't want to use a div wrapper because it might disrupt the style layout.

childrentime avatar May 09 '24 04:05 childrentime

https://react.dev/reference/react-dom/findDOMNode#adding-a-wrapper-div-element

wrapper will impact inner child component style, this is question !!!!

hlerenow avatar Jun 25 '24 06:06 hlerenow

Children.only({ ...children, ref });

Anyway, I find a way to add ref to children, it can replace findDomNode

childrentime avatar Aug 19 '24 09:08 childrentime