<Dialog /> / <Portal /> custom root element

[michael-land]

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 />.

[SigurdMW]

Any update on this? This is a feature we would like as well 😄

[zawilliams]

Running into this same issue. Custom root element would be great.

[rikkipitt]

Same here. I think I'm running into a similar thing...

[MarcelMalik]

Same issue here. Workaround: must use a custom modal implementation :/

[xylophonehero]

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!

[dcastil]

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! ❤️

[yaakov123]

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

[yaakov123]

This issue can be solved by removing the @close listener from the Dialog component and manually placing it on the overlay

[yaakov123]

I've written a more complete solution here - #874 (comment)

[jtomaszewski]

Dialog should allow for customizing what's/where's the portal root node.

This will solve problems like:

• this one
• Can't style Dialog when prefixing tailwind classes with a selector #998

Until then, devs have to choose a different Dialog implementation, or go around with hacks (like replacing the Document.prototype.getElementById or creating <div id="headlessui-portal-root" /> by themselves and making sure it's recreated between dialog mounts/dismounts).

@RobinMalfait tell me that you'd be open to this, and I can raise a PR.

[yassilah]

thanks a lot, works for me too 🙂

[okpedro]

P.S. For now, as a simplier workaround, you can just do

<React.Fragment>
  <YourAppThatUsesDialogs ... />
  
  {/* Workaround for https://github.com/tailwindlabs/headlessui/discussions/666 */}
  <div id="headlessui-portal-root">
    {/* 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 ) */}
    <div />
  </div>
</React.Fragment>

I found that if I set it to <div/> or an empty <div></div>, it doesn't work. Even if I put whitespace in there or fill it with content and hide it, it won't work. But if I put a single visible character, like <div>i</div>, it works. Otherwise, the modal opens and closes in a flash. I'm scratching my head trying to figure out why that matters.

EDIT: Figured out <div/> only doesn't work if the <Dialog> component is set to fixed instead of relative, in which case the <div> needs some visible content.

[steph-crown]

When I did this, clicking on the dialog itself closes the dialog. @jtomaszewski please, do you have any fix for that.

[paweltatarczuk]

@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 inert tag that was added to an ancestor of the <div id="headlessui-portal-root">. Since I was using this workaround only for scoped styles, I decided to solve it with the postcss-prefix-selector plugin instead.

[sturmenta]

@steph-crown my fix was (suggested by @thevisioner here)

remove the inert tag from the root component that I was using:

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]);
};

[sbarbat]

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 });

[yaakov123]

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.

[sbarbat]

Yes, that something I'm facing, do you know why this might be happening?

[yaakov123]

You can take a look at my solution here for a working fix: #874 (comment)

[animber0]

@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?

[pfcodes]

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

[curtgrimes]

I really need this for my use case.

[loicmagne]

🙏

[alifatic]

i still got this issue in "@headlessui/react": "^1.6.6", please any fix, other solution does not fix this

[lukeclifton]

I have the same issue here. As a work around i am doing the following:

<div id="headlessui-portal-root" class="tailwind-important-class-or-id">
    <div id="react-app-root-id"></div>
</div>

[web-programmer-here]

any updates on this?

[franco14lorenzo]

For those who happen to them in Next.js and the new Font component , this was my solution:

• In the _app.jsx file, add a div to wrap the page component, it must be a child element of the element that is applying the font variable

<div className={${montserrat.variable} font-sans}> <div id="headlessui-portal-root"> <Component {...pageProps} err={err} /> </div> </div>

[AdrianMachado]

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 Dialog and react-modal-hook to render a modal, but the mounting point was too high for tailwind to apply properly. I moved the mounting point within a lower hierarchy layout.tsx file and it works again!

[peyronoscar]

I get the following error when trying this workaround: There are no focusable elements inside the <FocusTrap />. Any ideas why?

[franco14lorenzo]

I get the following error when trying this workaround: There are no focusable elements inside the <FocusTrap />. Any ideas why?

I recently had the same problem and what I did was remove the div and change the way load the font:

In _app.js:

<style jsx global>{`:root { --font-montserrat: ${montserrat.style.fontFamily};}`}</style>
<Component {...pageProps} err={err} />

[bhatvikrant]

This works! Thanks @franco14lorenzo

[sipec]

Workaround no longer works as of headless ui 2.1

[bpolaszek]

Just got trapped into that same issue, by trying to introduce dynamic CSS variables. In Vue, they can't be bound to <body> (AFAIK) so classes that depend on them must be used within the root component and not inside one of its siblings.

<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 PrimaryButton.vue:

• Under Root.vue: 👌 (white text on #006dab background)
• Within a Dialog component: 💥 (white text on transparent background)

Thanks a lot @okpedro for saving my day!

[thevisioner]

Just wanted to mention that <div id="headlessui-portal-root"> helps with Next.js font scoping. Also added a little helper just before the closing </Dialog> to remove the 'inert' attribute and keep the dialog interactive:

function DisableInert() {
  useEffect(() => {
    const rootNode = document.getElementById("__next");
    if (rootNode) {
      rootNode.inert = false;
    }
  }, []);
  return null;
}

[xXDeonoXx]

omg, thank you, that was just what i needed but i didn't though how simple it could have been

[ScripterSugar]

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 ;*(

[axe312ger]

Have to agree :(

Edit:

Well, there is id="headlessui-portal-root" which tells headless ui where to put the portal. Works fine for me! :)

[Welfordian]

Was there any solution found for this problem? :-(

[TrustyTechSG]

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.

[heronoa]

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

[wade-wojcak-vib]

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.

[SampsonCrowley]

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

[ChaseIngebritson]

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

[johnnyshankman]

-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.

[AshleySchaeffer]

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.

[KrishEnacton]

Can you provide me a full example of it?

[AshleySchaeffer]

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.

[johnnyshankman]

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 ) */}

[johnnyshankman]

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.

[AshleySchaeffer]

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.

See my solution. It worked for me. Might work for you.