<Dialog /> / <Portal /> custom root element #666
Replies: 27 comments 27 replies
-
|
Any update on this? This is a feature we would like as well 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Running into this same issue. Custom root element would be great. |
Beta Was this translation helpful? Give feedback.
-
|
Same here. I think I'm running into a similar thing... |
Beta Was this translation helpful? Give feedback.
-
|
Same issue here. Workaround: must use a custom modal implementation :/ |
Beta Was this translation helpful? Give feedback.
-
|
Would be great to have this feature. My custom Modal implementation isn't as good as this one 😢. Using styled components and my CSS is scoped to the top of my shadow too. A custom element for where the portal should be rendered would be a great implementation! |
Beta Was this translation helpful? Give feedback.
-
|
I also have the use case where I don't want to use a portal because the dialog needs to be positioned based on the element close to which the React component is rendered. The dialog takes in most of the screen space, the background gets blurred while the dialog is open and I want to trap the focus in the dialog, so using a Popover wouldn't be the right choice here. I need to use a different library for this although the functionality is basically the same as the Headless UI dialog. Would be awesome if Headless UI could support not using a portal at all! ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
I have an unbelievably hacky solution, but it works (sort of). Paste the following code as early as possible (index.ts or something) const elementById = Document.prototype.getElementById;
Document.prototype.getElementById = function (elementId: string) {
if (elementId === "headlessui-portal-root") {
return root.element; // This is the root element which exists inside the Shadow DOM
}
return elementById.call(this, elementId);
};The issue now is that clicking anywhere closes the Modal |
Beta Was this translation helpful? Give feedback.
-
|
This issue can be solved by removing the @close listener from the Dialog component and manually placing it on the overlay |
Beta Was this translation helpful? Give feedback.
-
|
I've written a more complete solution here - #874 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Dialog should allow for customizing what's/where's the portal root node. This will solve problems like: Until then, devs have to choose a different Dialog implementation, or go around with hacks (like replacing the @RobinMalfait tell me that you'd be open to this, and I can raise a PR. |
Beta Was this translation helpful? Give feedback.
-
|
thanks a lot, works for me too 🙂 |
Beta Was this translation helpful? Give feedback.
-
I found that if I set it to EDIT: Figured out |
Beta Was this translation helpful? Give feedback.
-
|
When I did this, clicking on the dialog itself closes the dialog. @jtomaszewski please, do you have any fix for that. |
Beta Was this translation helpful? Give feedback.
-
|
@steph-crown I encountered a similar issue and had to use a different workaround in my case. The dialog was not interactive because of an |
Beta Was this translation helpful? Give feedback.
-
|
@steph-crown my fix was (suggested by @thevisioner here) remove the import { useEffect } from "react";
export const useRemoveInert = ({ isModalOpen }: { isModalOpen: boolean }) => {
useEffect(() => {
if (isModalOpen) {
// timeout needed to make sure inert is removed after dialog is opened
setTimeout(() => {
// disable inert to make dialog interactive -> https://github.com/tailwindlabs/headlessui/discussions/666#discussioncomment-6183443
const rootNode = document.getElementById("your-root-id");
if (rootNode) rootNode.inert = false;
}, 100);
}
}, [isModalOpen]);
}; |
Beta Was this translation helpful? Give feedback.
-
|
For some reason non of the solutions here helped me, so listening to changes in the DOM and then moving the portal root to wherever I wanted worked for me: // Just create the container and shadow root
let container = document.getElementById('some-container');
if (!container) {
container = document.createElement('div');
container.id = 'some-container';
document.body.appendChild(container);
}
const shadow = container.shadowRoot ?? container.attachShadow({ mode: 'open' });
/**
* Every time a new element `headlessui-portal-root` is added to the DOM,
* it will place it into the shadow body inside `some-container`
*/
new MutationObserver((records: MutationRecord[]) => {
const record: MutationRecord | undefined = records
.filter((record) => (record.target as HTMLElement).id === 'headlessui-portal-root')
.pop();
if (!record) return;
shadow.append(record.target);
}).observe(document, { childList: true, subtree: true }); |
Beta Was this translation helpful? Give feedback.
-
|
The issue over here is that the click to hide functionality will no longer work with this solution. For example, with the Dialog element, with this solution when you click on the Dialog itself, the Dialog closes. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that something I'm facing, do you know why this might be happening? |
Beta Was this translation helpful? Give feedback.
-
|
You can take a look at my solution here for a working fix: #874 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@yaakov123 This one works for me, but can you help me understand how to convert this solution to yours, or what the fundamental differences are? |
Beta Was this translation helpful? Give feedback.
-
|
Forcing a single portal that is unmodifiable is a pretty big architectural flaw imo. We should be able to use our own like Radix UI does https://www.radix-ui.com/docs/primitives/components/dialog#custom-portal-container |
Beta Was this translation helpful? Give feedback.
-
|
I really need this for my use case. |
Beta Was this translation helpful? Give feedback.
-
|
🙏 |
Beta Was this translation helpful? Give feedback.
-
|
i still got this issue in "@headlessui/react": "^1.6.6", please any fix, other solution does not fix this |
Beta Was this translation helpful? Give feedback.
-
|
I have the same issue here. As a work around i am doing the following: |
Beta Was this translation helpful? Give feedback.
-
|
any updates on this? |
Beta Was this translation helpful? Give feedback.
-
|
For those who happen to them in Next.js and the new Font component , this was my solution:
|
Beta Was this translation helpful? Give feedback.
-
|
To add to this, Full example (in your const font = Noto_Sans({
variable: "--next-font",
subsets: ["latin"],
weight: ["400"],
});
export default function App({
Component,
pageProps,
}: AppProps) {
return (
<div
className={clsx(
// The important line:
font.variable,
// className is optional. It will set the `font-family`
// Alternatively, add the snippet below this one inside your tailwind.config.json
font.className,
)}
>
<Component {...pageProps} />
{/* Workaround for https://github.com/tailwindlabs/headlessui/discussions/666, to allow font CSS variable */}
<div id="headlessui-portal-root">
{/* Important that a div is inside the portal root */}
<div />
</div>
</div>
);
}For module.exports = {
// ...,
theme: {
fontFamily: {
sans: [
// Important line, uses the font family from Next Font
"var(--next-font)",
// Your fallback. This was my default from Tailwind
"ui-sans-serif",
"system-ui",
"-apple-system",
"BlinkMacSystemFont",
'"Segoe UI"',
"Roboto",
'"Helvetica Neue"',
"Arial",
'"Noto Sans"',
"sans-serif",
'"Apple Color Emoji"',
'"Segoe UI Emoji"',
'"Segoe UI Symbol"',
'"Noto Color Emoji"',
],
},
},
}; |
Beta Was this translation helpful? Give feedback.
-
|
For anyone using the new App Directory in Next 13, this approach will work for fixing issues with tailwind CSS custom variables not being available at runtime in your headless components. For example, I use |
Beta Was this translation helpful? Give feedback.
-
|
I get the following error when trying this workaround: |
Beta Was this translation helpful? Give feedback.
-
I recently had the same problem and what I did was remove the div and change the way load the font: In _app.js: |
Beta Was this translation helpful? Give feedback.
-
|
This works! Thanks @franco14lorenzo |
Beta Was this translation helpful? Give feedback.
-
|
Just got trapped into that same issue, by trying to introduce dynamic CSS variables. In Vue, they can't be bound to <script setup>
// Root.vue
const primaryColor = computed(() => ({
50: '#eff9ff',
100: '#def2ff',
200: '#b6e7ff',
300: '#75d7ff',
400: '#2cc3ff',
500: '#00A0E6',
600: '#0089d4',
700: '#006dab',
800: '#005c8d',
900: '#064d74',
950: '#04304d',
})); // Computed, because values can change at runtime (changing app theme)
</script>
<style lang="scss">
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer base {
* {
--color-primary-50: v-bind(primaryColor[50]);
--color-primary-100: v-bind(primaryColor[100]);
--color-primary-200: v-bind(primaryColor[200]);
--color-primary-300: v-bind(primaryColor[300]);
--color-primary-400: v-bind(primaryColor[400]);
--color-primary-500: v-bind(primaryColor[500]);
--color-primary-600: v-bind(primaryColor[600]);
--color-primary-700: v-bind(primaryColor[700]);
--color-primary-800: v-bind(primaryColor[800]);
--color-primary-900: v-bind(primaryColor[900]);
--color-primary-950: v-bind(primaryColor[950]);
}
}
</style>
<template>
<RouterView />
</template>// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
primary: {
50: 'var(--color-primary-50)',
100: 'var(--color-primary-100)',
200: 'var(--color-primary-200)',
300: 'var(--color-primary-300)',
400: 'var(--color-primary-400)',
500: 'var(--color-primary-500)',
600: 'var(--color-primary-600)',
700: 'var(--color-primary-700)',
800: 'var(--color-primary-800)',
900: 'var(--color-primary-900)',
950: 'var(--color-primary-950)',
}
},
},
},
};<script setup>
// PrimaryButton.vue
</script>
<template>
<button class="bg-primary-700 text-white">
<slot />
</button>
</template>Rendering
Thanks a lot @okpedro for saving my day! |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to mention that function DisableInert() {
useEffect(() => {
const rootNode = document.getElementById("__next");
if (rootNode) {
rootNode.inert = false;
}
}, []);
return null;
} |
Beta Was this translation helpful? Give feedback.
-
|
omg, thank you, that was just what i needed but i didn't though how simple it could have been |
Beta Was this translation helpful? Give feedback.
-
|
Why is this issue not fixed after 3 years of initial raise? any particular reason? This flaw significantly affects the main concept of headless UI - fully customizable, the modal component is completely useless for my usecase because of this ;*( |
Beta Was this translation helpful? Give feedback.
-
|
Have to agree :( Edit: Well, there is id="headlessui-portal-root" which tells headless ui where to put the portal. Works fine for me! :) |
Beta Was this translation helpful? Give feedback.
-
|
Was there any solution found for this problem? :-( |
Beta Was this translation helpful? Give feedback.
-
|
I facing the Dialog display issue when rendering Dialog in iframe (using react-frame-component), the Dialog will always attach to the outer window instead of the iframe window. |
Beta Was this translation helpful? Give feedback.
-
|
The way I solve it was to set a Modal on the my template root (the first element that will render and use context to open and close it. TL;DR I think I create my own modal but still use Transitions from headlessUI to animate it |
Beta Was this translation helpful? Give feedback.
-
|
Wanted to chime in with my use case where I stumbled on this issue: I am using Storybook + React and was testing out a Dialog. I have a wrapper around my Stories at the preview level which applies my custom font. This works fine for the baseline rendering of a Story, but when a Dialog Portal is created it is created outside of that wrapper and thus does not retain the font. I can fix this for an initial Dialog opening by defining a div with id = 'headlessui-portal-root' within my Stories rendering function, but this gets wiped out after you close and reopen the Dialog a second time. Given this issue is just in a testing environment I will probably just overlook it for now, but it would be nice to have a way to define a permanent portal root if necessary. |
Beta Was this translation helpful? Give feedback.
-
|
this makes it impossible to have more than one root (i.e. separate apps on the same page) It also makes it soe that you can't guarantee certain dialogs are at a higher stacking context than others |
Beta Was this translation helpful? Give feedback.
-
|
Chiming in with another workaround for usage in Storybook using the removeInert hook from @sturmenta and the storybook tips from @wade-wojcak-vib: export const Default: Story = {
args: {
open: false
},
render: function Render(args) {
const [open, setOpen] = useState(args.open)
// This can be extracted into a hook, but for the sake of example it's not
useEffect(() => {
if (open) {
setTimeout(() => {
const rootNode = document.getElementById('storybook-root')
if (rootNode) rootNode.inert = false
}, 100)
}
}, [open])
return (
<>
<div id="headlessui-portal-root" />
<MeshProviderMock mocks={globalQueryMocks}>
<SaturateCacheMock>
<ButtonPrimary label="Toggle" onClick={() => setOpen(!open)} />
{/* This EditorDialog component is a thin wrapper for the headlessui dialog component and is not rendered until the button is clicked */}
{open && <EditorDialog open={open} />}
</SaturateCacheMock>
</MeshProviderMock>
</>
)
}
}Note that the headlessui portal root component needs to exist in the dom before the headlessui dialog component has been rendered, otherwise it won't detect that a root already exists in the ownerDocument |
Beta Was this translation helpful? Give feedback.
-
|
-1 this only works for me on the first opening. if i close the dialog, it removes my predefined headless portal root from the dom and then proceeds to do default behavior upon opening the dialog a second time. |
Beta Was this translation helpful? Give feedback.
-
|
Not ideal, but in React I was trying to have notifications appear over all other elements. This issue caused me problems. I just did this: https://react.dev/reference/react-dom/createPortal#rendering-a-modal-dialog-with-a-portal It creates another portal which renders as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Can you provide me a full example of it? |
Beta Was this translation helpful? Give feedback.
-
|
https://codesandbox.io/p/sandbox/6c6clm If you click the button in the top right of the code snippets on the docs, you'll see a full example hosted on codesandbox. I don't fully understand it, but it looks like portals dynamically create elements at the document root. I just defined a portal in the component and it worked fine, even rendering after a modal component rendered within another portal. As the notification component renders after the modal, it's portal element renders above the modal. |
Beta Was this translation helpful? Give feedback.
-
|
This is so silly that we can't predefine where the portal goes to using a prop. <div id="headlessui-portal-root" />You can try putting this in your DOM but it will only hook into it one time. Once you close the Dialog, it will remove this element and then reinject it in the default spot. So silly. Took me twenty minutes reading through this to find my solve: {/* It needs at least one child, so that HeadlessUI doesn't remove this portal root workaround
( https://github.com/tailwindlabs/headlessui/blob/main/packages/@headlessui-react/src/components/portal/portal.tsx#L84 ) */} |
Beta Was this translation helpful? Give feedback.
-
|
Oh great but now the z-indexing is completely screwed so I cannot click on anything inside my dialogs. I give up what an awful library. Seems like an obvious thing you'd want to control. I don't just want portals opening up at the root of the document. |
Beta Was this translation helpful? Give feedback.
-
See my solution. It worked for me. Might work for you. |
Beta Was this translation helpful? Give feedback.
and others
-
What package within Headless UI are you using?
@headlessui/react
What version of that package are you using?
1.0.0
What browser are you using?
chrome
Reproduction repository
I'm rendering my react app under shadow root and all my css are scoped inside the shadow root.
I want the
<Dialog />or the<Portal />insert inside the shadow root instead of the document.body. It would be nice we can pass custom root element for<Dialog />/<Portal />.Beta Was this translation helpful? Give feedback.
All reactions