Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[React 19] Removal of ReactDOM.findDOMNode #28926

Open
migueloller opened this issue Apr 26, 2024 · 3 comments
Open

[React 19] Removal of ReactDOM.findDOMNode #28926

migueloller opened this issue Apr 26, 2024 · 3 comments
Labels

Comments

@migueloller
Copy link

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!

@eps1lon
Copy link
Collaborator

eps1lon commented Apr 26, 2024

Prior discussion: #14357

@migueloller
Copy link
Author

migueloller commented Apr 26, 2024

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.

@childrentime
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants