-
Notifications
You must be signed in to change notification settings - Fork 1.1k
fix(render): Don't reject wrapper types based on statics #973
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
Conversation
| options?: pure.RenderOptions, | ||
| ) { | ||
| const Wrapper: React.FunctionComponent = ({children}) => { | ||
| const Wrapper: React.FunctionComponent<{children?: React.ReactNode}> = ({ |
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.
While FunctionComponent adds implicit children, its propTypes do not so we didn't catch that issue. Here we make sure all statics assume the same props. Also makes sure this doesn't break once we get rid of implicit children in React.FunctionComponent.
|
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 54057ef:
|
Codecov Report
@@ Coverage Diff @@
## main #973 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 4 4
Lines 140 140
Branches 26 26
=========================================
Hits 140 140 Continue to review full report at Codecov.
|
MatanBobi
left a comment
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.
Looks good :)
|
🎉 This PR is included in version 12.1.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
| * @see https://testing-library.com/docs/react-testing-library/api/#wrapper | ||
| */ | ||
| wrapper?: React.ComponentType<{children: React.ReactElement}> | ||
| wrapper?: React.JSXElementConstructor<{children: React.ReactElement}> |
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.
I'm wondering whether we should define children as React.ReactNode which seems to be the "official" type for children props. https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L829
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.
wrapper never receives anything other than ReactElement. If we would widen children to ReactNode, the implementation of wrapper would have to account for types that it never actually receives.
This is problematic if you want to apply methods to children in the implementation of wrapper that require a single ReactElement such as React.cloneElement.
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.
That makes perfect sense - ReactNode is indeed very wide. Thanks for the explanation.
|
🎉 This PR is included in version 13.0.0-alpha.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What:
Closes #970
Closes #972
Why:
Broke in #966
How:
Implicit children strikes yet again. While
FunctionComponentadds implicit children, itspropTypesdo not so we didn't catch that issue. We don't care about React statics and just that we can pass it tocreateElement(or any JSX runtime).Checklist:
[ ]Documentation added to thedocs site