You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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!
The text was updated successfully, but these errors were encountered:
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.
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.
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 leveragefindDOMNode
so that we can find registered component's DOM nodes when users don't useforwardRef
(or in React 19, handle theref
prop).Here's how we use
findDOMNode
: https://github.com/makeswift/makeswift/blob/58f425cf522c23af4a71b2f07a7625b252c59a5e/packages/runtime/src/runtimes/react/find-dom-node.tsxWhile 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
withdisplay: 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 withoutfindDOMNode
, 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!
The text was updated successfully, but these errors were encountered: