-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
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
[Dropdown] Introduce higher-level menu component #37667
Conversation
Netlify deploy preview@material-ui/unstyled: parsed: +2.92% , gzip: +2.45% Bundle size reportDetails of bundle changes (Toolpad) |
👏 Love it! |
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.
For the naming, here is my thought
Dropdown
sounds better and shorter thanDropdownMenu
without losing the meaning.- I don't agree to change
Menu
toMenuList
because that will introduce a big change to the codebase and to developers (I think theMenu
works great).
Interesting idea. I'm not sure I', 100% sold, but I'll consider it. When we add a context menu in the future, I wonder what the naming scheme should be. <Dropdown>
<ContextTrigger element={ref} />
<Menu>...</Menu>
</Dropdown> While it's something for the future, it could be worth having this at the back of our heads we create an intuitive API. |
On the naming, I would go with |
But in our case, we still have a |
Fair enough, let's go with |
A problem with this approach is that we'd have to make the Menu unstable as well as it had to be adjusted to work with the Dropdown |
@siriwatknp I'll introduce these changes to Joy as well. Are you OK with it? |
Sounds good to me! |
Thinking about it again. Would it be better to separate the PR? easier to review and track in the changelog. |
Merging just the changes from Base UI would leave Joy UI broken as the Base Menu's API was changed. |
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.
This is a great utility component, I think it completely delivers on the promise of making easier the building of dropdown menus 🎉
Regarding naming, Dropdown
and Menu
sound good to me, at the beginning, I was also thinking MenuList
would have been better but the role is menu
and on the ARIA design patterns they name it Menu
as well, so I think it's consistent with the ecosystem.
It's a complex problem and thus complex implementation so reviewing was hard. I got the general picture of how it works and it makes sense to me, as well as how it was implemented, so I'm approving.
I just left a little comment/question.
I think we should wait for @siriwatknp to review and approve the Joy changes
import { useTheme } from '@mui/system'; | ||
import { ListActionTypes } from '@mui/base/useList'; | ||
|
||
export default function UnstyledMenuSimple() { |
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.
Shouldn't we replace the "Unstyled" prefixes for "Base"? Or are we keeping the "Unstyled"? I think it might be confusing. Maybe just use "MenuSimple"
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.
Yeah, good point. I'll create a separate PR for this.
42fe487
to
cbdc759
Compare
@siriwatknp I'd appreciate if you could double-check the changes in Joy. |
Got it. |
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 great!
This PR introduces hooks and components that aim to make building menus easier. The general shape was discussed in #32088.
One notable change from what was discussed in the linked issue is the name of the outermost component. We agreed to use
MenuProvider
, but this name is already used elsewhere in Base UI. I decided to call the component (and the associated hook)DropdownMenu
. Similarly toMenuProvider
, this won't conflict with any existing identifiers from Material UI.The structure currently looks as follows:
I'm looking forward to seeing opinions about this naming pattern. I'm considering renaming the
Menu
toMenuList
to make it less ambiguous.As for the implementation, controlling the open/close state is done via a controllable reducer owned by the DropdownMenu. Menu and MenuItem dispatch actions, and the whole logic sits in dropdownMenuReducer. The dispatch function could be exposed externally in the future if needed. Such architecture allows for easy communication between components and enables painless introduction of other menu items, such as radio button or checkbox going forward.
This PR changes how menus are used. Instead of custom wiring of a menu and a button to open/close it, place the Menu and the MenuButton within a Dropdown component. The
open
andonOpenChange
props now are accepted by the Dropdown, not the menu.Playground: https://deploy-preview-37667--material-ui.netlify.app/experiments/base/menu/
Closes #32088