-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Card] Fix TypeScript not recognizing "component" prop #20179
Conversation
… (title & subheader)
Details of bundle changes.Comparing: 14f5de6...30c75b8 Details of page changes
|
<CardHeader | ||
titleTypographyProps={{ | ||
component: 'a', | ||
// $ExpectError | ||
propThatDoesntExist: 'shouldNotWork', | ||
}} | ||
/>; |
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.
@eps1lon @fyodore82 need some advice...
CardHeader has an additional level of complexity compared to ListItemText
in that it's a type map.
The component prop on both titleTypographyProps
& subheaderTypographyProps
now works as expected. However I can't seem to find the way to get these particular set of tests to fail — the tests that look into unknown props on typography object. The nested typography prop objects accept any number of unknown props. The correct typography props work as expected and the optional component prop too but the typing system just let's any other unknown props go through as well.
- Is this an issue? ListItemText rejects unknown props.
- If it is an issue, any ideas on how to address?
FYI: At the moment, the test_types
build on the CI is broken for this reason.
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 don't have the bandwidth to deep-dive into this issue. Maybe some issue with to many free type parameters or some quirk in JSX.
For now just document that this is undesired behavior in code comments. In addition it might be nice to extend these undesired behavior with tests using createElement
directly (instead of JSX) and if wrong value types are rejected e.g. { variant: 123213 } or { component: SomeComponentImplementingFooNumber, foo: 'a-string-which-should-be-a-number' }
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.
- Documented the unmet expectations via comments
- Added createElement tests
- Behaviour is pretty consistent with JSX. Only exception I found was the type system not demanding the required props from the
component
prop type like it does in JSX — both for CardHeader and it's nested typography items. - Wrong value types are indeed rejected (e.g.
{ variant: 123213 }
, etc)
- Behaviour is pretty consistent with JSX. Only exception I found was the type system not demanding the required props from the
Add additional tests using React.createElement
@rart Looking good. Thanks! |
In continuation of #20093