Skip to content
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

[Portal] Add possibility to specify the container in which the portal is rendered #666

Closed
Drogglbecher opened this issue Sep 7, 2020 · 2 comments · Fixed by #756
Closed
Labels

Comments

@Drogglbecher
Copy link

Drogglbecher commented Sep 7, 2020

🚀 Feature request

Current Behavior

I want to implement the MenuButton within a component with fullscreen option. The current implementation of the portal only allows children as props and renders the popover menu as child of body.

This behaviour is implemented in the followig CodeSandbox Template (You have to open the app in a new window to ensure fullscreen is working)

Desired Behavior

It would be nice to specify the component content the portal is rendered in and allow to access this for all components using a portal.

Suggested Solution

I think a good way could be adding a prop to the Portal like the portalContainer prop of blueprints popover component

@Drogglbecher Drogglbecher changed the title [Portal] [Portal] Add possibility to specify the container in which the portal is rendered Sep 7, 2020
@john-oliveoil
Copy link

john-oliveoil commented Nov 21, 2020

A feature like this, to allow us to specify the container or specify the node where the portal should be rendered, is essential for us.

Why not just have a prop called node that allows us to specify a custom DOM element for the portal (if not specified then it would still append to the body as now). Basically the same as react-portal.

This additional prop should extend to the other Reach packages (e.g. reach/dialog).

Without this feature it makes it impossible for us to correctly use this library in combination with the ShadowDOM. We do like Reach, but without this option, we have been considering dropping it in favor of other libraries. So please do consider adding this in a future (hopefully soon) version.

@selrond
Copy link

selrond commented Dec 11, 2020

Already mentioned in #571

Another use case: say you have notification toasters / whatever UI element / you need to ensure is always on top of everything else.

In its current implementation, @react/dialog (which usese @reach/portal under the hood) just always appends portal node to body making it always the last child of body, which in turn makes it impossible to layer anything else on top of it in a predictable way.

So the underlying issue is that @react/portal makes an assumption that it should always be the last element in the DOM when rendered.

@chaance chaance added the Type: Feature New feature request label Dec 18, 2020
@chaance chaance linked a pull request Mar 30, 2021 that will close this issue
11 tasks
@stale stale bot closed this as completed Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants