-
Notifications
You must be signed in to change notification settings - Fork 48.6k
Expose refs on DOM Components as Direct Handles to the actual DOM Node #3223
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
Comments
I agree about "should be an unobservable implementation detail". But how would you accomplish "perhaps it shouldn't be implemented as a wrapper."? Anyway, it seems to me that direct interaction with the underlying frontend objects is something we want users to avoid? Instead favoring a reduced API bridge (when necessary) which would just fulfill the needs of the users and one that could also be reimplemented/proxied by community wrappers intended to fix/improve/extend/emulate native components for compatibility. This reduced API bridge could also provide additional benefits such as caching, batching or alternative APIs suitable for the React environment. Accessing the underlying frontend object would then be the "last resort". The idea of returning the actual DOM node instead of a component for a ref is really interesting... the more I think about the more directions/reasons for it appear to me so I can't really boil down my questions/concerns to something sensible so I'll just trust you ;)
That wouldn't work for |
@sebmarkbage This wouldn't work with e.g. #2242 I think? There's no universal guarantee the underlying DOM node lives as long as the owning component, unless polyfilled DOM components are exposed as such, but that doesn't seem to be your plan? EDIT: But even then, we're forcing that guarantee to hold for all frontend implementations unless there's a way to force refresh refs? |
Refs gets attached/reattached all the time: E.g: <div key={Math.random()}><div ref="myDiv" /></div> We respond by firing the ref callbacks and updating Even then, it seems like this is only a problem if you have a |
But are we sure this holds for every frontend out there? I agree input is kind of special here, but could one not imagine something similar for other frontends too? But then again, being able to refresh refs would solve that if it ever came to that. |
ZOMG! So exciting. |
@sebmarkbage With this new change, how would we reference an actual component instance? For example, how would I implement this hypothetical
|
Those work the same; only low-level DOM components (e.g., |
@spicyj Ah ok, that's great to know! Thanks. |
My mental model is that we have a polyfill layer (
ReactDOMInput
) to support what the browser would support, and will support in the future once these ideas propagate through the standards. The fact that it is currently implemented as a wrapper should be an unobservable implementation detail, and perhaps it shouldn't be implemented as a wrapper.As an upgrade path we would need to monkey patch existing legacy methods (
props
,setProps
,getDOMNode
) onto it as an upgrade path. These would work but immediately warn when used.setProps
will be replaced by some other imperative layer, or simply multiple calls toReact.render
.component.getDOMNode
is being replaced byReact.findDOMNode(component)
which can take either an arbitrary component or a DOM node directly. So you can use it on something that you're unsure about. In most cases, you can simply get rid of the call all together and use the DOM ref directly.The text was updated successfully, but these errors were encountered: