-
-
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
[ButtonGroup] Support different elements under ButtonGroup #28645
[ButtonGroup] Support different elements under ButtonGroup #28645
Conversation
…t different elements other than <Button />
@material-ui/lab: parsed: +0.08% , gzip: +0.10% |
Any news on this PR? I am using a customized |
It would help if someone gets time to review this PR. @Pablion Until then you can use this PR's preview package and check if it works for you.
|
@ZeeshanTamboli I just checked the new preview with my localhost, and it is improved but not what expacted. I'm trying to create to create a sandbox to explain but they dont support |
I made a explanatory demo with Code Sandbox. |
@Pablion Thanks for providing the codesandbox. You need to pass See this updated CodeSandbox. For how it is working on MUI |
Hi,@ZeeshanTamboli,
And I think that should be part of "Support different elements under ButtonGroup" |
Should it be a demo to showcase the children that are not Button? |
Is there something new to test with? |
See #28645 (comment) |
...other | ||
} = props; | ||
|
||
const color = colorProp || colorContext || 'primary'; | ||
const disabled = disabledProp || disabledContext || false; | ||
const disableElevation = disableElevationProp || disableElevationContext || false; |
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.
Using ||
looks wrong here. If disableElevationContext
is true and disableElevationProp
false, disableElevation
should be false, not true.
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.
Otherwise, we could explore the creation of a helper. I assume that it's always the same case when a parent component uses the context to change default values on its children.
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.
Using
||
looks wrong here. IfdisableElevationContext
is true anddisableElevationProp
false,disableElevation
should be false, not true.
Nice catch. That is interesting! Need to think how to handle these button boolean props if used with context.
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 assume this would work:
const disableElevation = disableElevationProp || disableElevationContext || false; | |
const disableElevation = disableElevationProp ?? disableElevationContext ?? false; |
I saw it used by Michal const ButtonRoot: React.ElementType = component ?? components.Root ?? 'button';
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.
@oliviertassinari I'm afraid that his is not supposed to be used here. If i recall it correctly, ??
checks nullity (undefined/null) instead of falsy/truthy.
Example here (i just wrote it)
So if a user has disableElevationProp={false} disableElevationContext={true}
, this version with ??
will return a false
instead of true
. (see the exception_case
in that example)
component ?? components.Root ?? 'button'
was correctly used or equally components?.Root ?? 'button'
.
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.
we do not support it like this without Context
It's interesting no one has filed a bug with this yet. I'd say let's keep the current behavior and fix it for the next major (and in unstyled Button when ButtonGroup is introduced there).
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'd say let's keep the current behavior and fix it for the next major (and in unstyled Button when ButtonGroup is introduced there).
Okay. With that I think there is nothing else pending in this PR. Resolving this conversation.
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.
@ZeeshanTamboli could we add a todo to change this behavior in v6?
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.
Added.
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 was just writing tests for this and noticed that we do not support it like this without Context.
@ZeeshanTamboli it looks like more bugs.
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.
See one last comment for adding TODO for v6. Apart from that, it looks great! :)
Hi MUI team. does this close #28899 as well? And will it on next patch? |
Closes #17226
Use Context API instead of
React.cloneElement
.I have also considered https://reactjs.org/docs/context.html#caveats by using
useMemo
. But I have not profiled any performance metrics.Also let me know if we want to test this in some other ways.
CodeSandbox with the fix.