-
Notifications
You must be signed in to change notification settings - Fork 67
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
Support React.RefObject in React >=16.3 #46
Comments
Alright, so the main issue I see here – whatever the intent we have – is that if we manage make that TS prop non-readonly, we can't re-assign props.children.ref.current, because props are frozen (or should be treated as such). Correct me if I'm wrong but seems like the only future-proof solution would be to have a new prop that you could optionally provide. <Observer innerRef={reactRef} onChange={...}>
<div> {/* <-- gets innerRef assigned if provided */}
{...} |
Pardon me for not mentioning the obvious approach to |
@Rendez no, it should be ok. The less pervasive solution is to simply assign to Now, tapping on the children passed in the component may be seen as a bad practice (as you mentioned). I've seen other patterns for doing this exact same thing (get hold of a DOM node for measuring, etc.) - such as react-measure. Though, that's a much bigger breaking change. |
Handle children
ref
created using the newReact.createRef
. This is an object containing acurrent
property pointing to the HTML element. E.g.I've raised this with the React team before. See: facebook/react#13029.
We need to extend here to support this new format.
Expected behavior
☝️
this.targetRef.current
should be defined and should match HTMLDivElement.Current behavior
☝️
this.targetRef.current
isnull
.Context (environment)
React >= 16.3. See facebook/react#13029.
The text was updated successfully, but these errors were encountered: