Add optional node container target to Portal

[Warsaken]

This PR aims to solve the issue #666.

It introduces a new optional prop for Portal: nodeContainer containerRef that allows the user to specify the containing node to render the Portal in.

If this PR is approved, then we can create a follow up PR to pass this prop to other relevant packages.

---

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code (Compile and run).
• Add or edit tests to reflect the change (Run with yarn test).
• Add or edit Storybook examples to reflect the change (Run with yarn start).
• Ensure formatting is consistent with the project's Prettier configuration.
• Add documentation to support any new features.

This pull request:

• Creates a new package
• Fixes a bug in an existing package
• Adds additional features/functionality to an existing package
• Updates documentation or example code
• Other

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1ef0803:

Sandbox	Source
reach-ui-template	Configuration

[chaance]

Thanks for the PR! A few changes requested but I'd like to merge this when we can.

[Warsaken]

@chaance thanks for reviewing, I made the requested changes now.

[chaance]

On second thought I think it makes a lot more sense for this prop to accept a ref rather than a DOM node. Probably requested changes before I thought about it more fully, so sorry about that. Let's hold for right now, I'll circle back to this after I've taken care of a few high-priority bugs for the next release.

[Warsaken]

On second thought I think it makes a lot more sense for this prop to accept a ref rather than a DOM node. Probably requested changes before I thought about it more fully, so sorry about that. Let's hold for right now, I'll circle back to this after I've taken care of a few high-priority bugs for the next release.

Several of the other libraries I encountered write it as an HTMLElement (e.g.: https://github.com/palantir/blueprint/blob/develop/packages/core/src/components/portal/portal.tsx) that's why I started with that type, since it's familiar and easy to migrate existing code to Reach later. But let me know which type you think is the best here and I can make those changes.

[Warsaken]

@chaance This has been here for a while so I went ahead and updated the type to a ref like you suggested.

Being of node type or HTMLElement also seemed reasonable to me, for example in my use case the container I need to append the portal to is obtained through a function that returns a HTMLElement which may not even be a react component.
But either way works, I just need to convert that to the ref format afterwards.

Let me know if there are any other changes necessary. Thanks.

[zefj]

hey @chaance , we could really use this feature too. Our case involves menu-button within overflow: hidden nodes living within modals, so unfortunately we cannot just disable the portal 😞 Is there any chance of getting this soon?

[Warsaken]

I see the PR was merged, thanks @chaance.

Now we need to create a PR to pass the prop along for the other libraries that use Portal (e.g. Dialog).
Will you, or someone else, create a PR for that or should I do it?