-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat: add FloatingMenu to dropdown #7928
feat: add FloatingMenu to dropdown #7928
Conversation
Deploy preview for carbon-elements ready! Built with commit 6ddd093 |
Deploy preview for carbon-components-react ready! Built without sensitive environment variables with commit b46f1b3 https://deploy-preview-7928--carbon-components-react.netlify.app |
Deploy preview for carbon-components-react ready! Built without sensitive environment variables with commit 6ddd093 https://deploy-preview-7928--carbon-components-react.netlify.app |
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.
thanks for jumping in on this issue, the menu placement looks good so far. currently keyboard navigation is not supported in the floating menu though, which is a regression
to answer some of your questions:
- Should this be a default or triggered by a property?
I'm leaning towards this being triggered by a property because of the scrolling issue you mention below
- Should this be added to multi select?
yes I believe eventually this could make its way to the other listbox components but we can focus on dropdown for the time being
- This is required by the FloatingMenu, should these properties optional? (Code)
menuRef={() => {}} menuOffset={() => {}}
I believe menuRef
will be required to find the menu body and focus on the proper element, but menuOffset
probably won't be needed
- This is needed for the modal to work (otherwise it closes on select) - any other ideas to fix this? (Code)
<ListBox.Menu onMouseDown={e => e.stopPropagation()}
I don't think there's a way around this, since the floating menu is no longer a child of the modal, it views clicking inside the menu as clicking outside of the modal, which closes the modal by default. Probably another reason to go with prop vs default behavior (referring to question 1)
|
Also:
|
@emyarod are there any updates on this PR? Is this solution still viable or are there any other solutions to this issue? |
there are still some open questions from our last conversation, mainly looking for any downshift examples where a floating menu is used. I still have concerns about this use case and its compatibility with downshift |
I'm going to close this due inactivity, but feel free to reopen if the use case concerns and downshift compatibility can be addressed |
DCO Assistant Lite bot: Thanks for your submission! We ask that you sign our Developer Certificate of Origin before we can accept your contribution. You can sign the DCO by adding a comment below using this text: I have read the DCO document and I hereby sign the DCO. Conrad Schmidt seems not to be a GitHub user. You need a GitHub account to be able to sign the DCO. If you have already a GitHub account, please add the email address used for this commit to your account. |
Closes #7565
Adds a FloatingMenu to the dropdown component, to use it within scrollable areas
Changelog
New
Changed
Removed
Testing / Reviewing
Open points
Should this be a default or triggered by a property?
Should this be added to multi select?
This is required by the FloatingMenu, should these properties optional? (Code)
A simple solution for the dropdown would be to close it on scroll, to avoid updating the menu via JS (because this is laggy). For other components like the Tooltip this could work as well, but I guess this needs to be discussed in the separate issue.