-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[docs] Add simple list typescript demo #14485
Conversation
It's already a pretty challenging demo if one wants to infer what DOM node will actually be rendered and therefore what DOM attributes are allowed. `button` would render a button but the component overrides that again...
f4bf8e9
to
4d1847c
Compare
No bundle size changes comparing 56fcebb...4d1847c |
}); | ||
|
||
function ListItemLink(props: ListItemProps<'a', { button?: true }>) { | ||
return <ListItem button component="a" {...props} />; |
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.
@pelotom I guess this is somewhat better than before. It's not truly accurate because I would not be able to use <ListItemLink component="span" />
but I guess the tradeoff is somewhat ok. I think it's even good to forbid this because it limits the amount of places people would change what DOM node is rendered.
ListItemProps<'a', { button?: true }>
is however accurate for <ListItem {...props} button component="a"/>
.
I tried it with union props but gave up at some point. ListItem
is just a monster when it comes to "what DOM node will be rendered?". I'll look into a simpler component and see if we can simplify those types with union props. I'm suspecting that this will still cause implicit any
in callbacks because type inference works differently in JSX.
Testing #11731