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
Currently, for most components (e.g. MenuButton, Dialog, ...) it is impossible to configure the containerRef of the underlying Portal if the user wants to portal that component. See #900
As a result, you can't portal most of the reach-ui components if you are using reach-ui in a Web Component.
Desired Behavior
A clear and concise way to be able to set the containerRef of a Portal in components that use the reach-ui Portal.
Suggested Solution
The smallest impact to the components APIs would be to add a PortalContainerContext:
It serves as an opt-in for everyone who wants full control over the containerRef of the underlying Portal. Especially people who use reach-ui inside Web Components.
Describe alternatives you've considered
The alternative would be to expose the containerRef property on each component that may use a Portal underneath. That could be quite messy and PRs with that solution were closed without merging in the past (e.g. #901).
Additional context
I would be happy to contribute :)
The text was updated successfully, but these errors were encountered:
🚀 Feature request
Current Behavior
Currently, for most components (e.g.
MenuButton
,Dialog
, ...) it is impossible to configure thecontainerRef
of the underlying Portal if the user wants to portal that component. See #900As a result, you can't portal most of the reach-ui components if you are using reach-ui in a Web Component.
Desired Behavior
A clear and concise way to be able to set the
containerRef
of aPortal
in components that use the reach-uiPortal
.Suggested Solution
The smallest impact to the components APIs would be to add a
PortalContainerContext
:Which would be consumed by the
Portal
component and used if nocontainerRef
is set directly on thePortal
component.And the default value could be overridden like:
Who does this impact? Who is this for?
It serves as an opt-in for everyone who wants full control over the
containerRef
of the underlyingPortal
. Especially people who use reach-ui inside Web Components.Describe alternatives you've considered
The alternative would be to expose the
containerRef
property on each component that may use a Portal underneath. That could be quite messy and PRs with that solution were closed without merging in the past (e.g. #901).Additional context
I would be happy to contribute :)
The text was updated successfully, but these errors were encountered: