Replies: 3 comments 2 replies
-
@cutterbl Hi, from your comment it seems that you managed to use native dialog in combination with react-select. I know the question probably does not belong here but how you managed to solve potential overflow. Unfortunately portaling did not help me as using "showModal()" is setting dialog in #top-layer so the Menu is always lower. Thanks in advance! |
Beta Was this translation helpful? Give feedback.
-
@zayprom This is the purpose of my Feature Request. I'm not using native dialogs yet because of the need to render react-select on my dialogs. If react-select were to use the Popover API, for rendering of the MenuList, then it should be possible, as then the menu would automatically be on a higher layer of the top layer. You are correct, menu portaling does not work in that instance. I have several custom components in my own application (date time picker, cron picker, tree select control) where I have traded the 'picker's to use the Popover API with great success. (Still need |
Beta Was this translation helpful? Give feedback.
-
@zayprom I use the Popover API in my React 17 app. I just had to give a value to the |
Beta Was this translation helpful? Give feedback.
-
Now that the Popover API is standard in all browsers, it would be great if the MenuList were a true 'popover'. This would allow developers to use react-select on native
<dialog>
's, and remove the need for occasional document portaling. I know this would be easier if CSS Anchor Positioning was fully supported (We can dream, can't we? Come on Safari and FF!). But I think using@floating-ui
as a polyfill would cover the gap until that time comes. Probably trim some code too. If you did go this route, I would suggest a custom@floating-ui/dom
implementation though, rather than their React components. My $.02.Beta Was this translation helpful? Give feedback.
All reactions