-
Notifications
You must be signed in to change notification settings - Fork 47k
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
[ReactDOM] Add strict mode test for findDOMNode #15091
[ReactDOM] Add strict mode test for findDOMNode #15091
Conversation
|
||
// outside of dev toWarnDev would always pass which means negating it would always fail | ||
if (__DEV__) { | ||
expect(() => ReactDOM.findDOMNode(child)).not.toWarnDev(['**']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this also match a potential future warning? I had the full message originally but I'm not sure how it would actually look like
expect(() => ReactDOM.findDOMNode(child)).not.toWarnDev(['**']); | |
expect(() => ReactDOM.findDOMNode(child)).not.toWarnDev(['Warning: findDOMNode is deprecated in StrictMode.**']); |
d0c9719
to
3796d53
Compare
No significant bundle size changes to report. Generated by 🚫 dangerJS |
3796d53
to
6b01aa1
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution. |
Still active |
6b01aa1
to
041b47e
Compare
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 2469628:
|
Unsure if we won't get false positves if the error message changes slightly
041b47e
to
2469628
Compare
Closing due to lack of interest. We test this compatibility layer in our own code base on React canaries. |
#13841 deprecated presumably "all usage" of
findDOMNode
. This is not the case if passed a host component1. I wanted to verify if this is intended or not since we have a use case for not issuing a deprecation warning for host components:We have a component library that lets the user pass a custom component that is rendered. It can be a different DOM node or an actual component:
However we required the DOM node of the rendered component for focus handling (essentially adding a focus-visible polyfill). Before deprecation we used
findDOMNode(this)
. Now thatfindDOMNode
is deprecated we want to move away from that usage while enabling some backwards compatibility:This change:
<LibraryComponent as={SomeFunctionComponent} />
<LibraryComponent as="div" />
or any other host component or ref forwarding component<LibraryComponent as={SomeClassComponent} />
The test added with this PR is basically ensuring the third behavior.
Followup on #13841 (comment)
1 Not sure if this is the correct term.