You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our ongoing effort of rewriting some of our popover-based components to ariakit (Tooltip, DropdownMenu, CustomSelectControl, Dialog...)
As we introduce new versions of existing components, one of the questions is whether these new components should try to tentatively render in Popover.Slot by default, like the internal Popover component currently does.
This conversation is also related (and a part of):
After discussing with @youknowriad , we established that we should always try to aim to offer the best possible experience to the consumers of our components — and we both agreed that the best experience is NOT to rely on Popover.Slot, and have our new components render their popovers in a new DOM node in the document.body.
We also discussed how in order to ensure a more coherent behavior between components using the internal Popover component and the new components using ariakit, we should also apply this new behavior to the first-party Popover component. This will likely require a few tweaks around Gutenberg (and a dev note), but we ultimately think that the change is going to result in an improvement of our components library.
Plan of action
Tweak the Popover component so that it doesn't render in Popover.Slot by default.
This should be likely achieved by removing the default value of the slotName prop.
We should check all usages in the editor for where it's effectively required for Popover to render in Popover.Slot (the block toolbar is definitely one such example)
We should check that there are not regressions introduced to how different popover-based UIs stack on top of each other
We should add a dev note, with an explanation of how to restore the previous behaviour (ie. passing an explicit slotName prop to Popover)
Make sure that all ariakit-based components do not render in Popover.Slot by default
Rever changes to the new version of DropdownMenu
The text was updated successfully, but these errors were encountered:
What problem does this address?
The subject of this conversation is influenced mainly by two related topics:
ariakit
(Tooltip
,DropdownMenu
,CustomSelectControl
,Dialog
...)As we introduce new versions of existing components, one of the questions is whether these new components should try to tentatively render in
Popover.Slot
by default, like the internalPopover
component currently does.This conversation is also related (and a part of):
@wordpress/components
: portal behavior of popover-based components #63697What is your proposed solution?
After discussing with @youknowriad , we established that we should always try to aim to offer the best possible experience to the consumers of our components — and we both agreed that the best experience is NOT to rely on
Popover.Slot
, and have our new components render their popovers in a new DOM node in thedocument.body
.We also discussed how in order to ensure a more coherent behavior between components using the internal
Popover
component and the new components usingariakit
, we should also apply this new behavior to the first-partyPopover
component. This will likely require a few tweaks around Gutenberg (and a dev note), but we ultimately think that the change is going to result in an improvement of our components library.Plan of action
Popover
component so that it doesn't render inPopover.Slot
by default.slotName
prop.Popover
to render inPopover.Slot
(the block toolbar is definitely one such example)slotName
prop toPopover
)Popover.Slot
by defaultThe text was updated successfully, but these errors were encountered: