Combobox render strategy #3808
Replies: 2 comments
|
This is a known pain point when rendering Headless UI components inside non-Headless modals/dialogs. The A couple of approaches that work: 1. Use the Headless UI supports rendering options into a portal, which moves them to the end of <Combobox>
<ComboboxInput />
<ComboboxOptions portal>
{/* your options */}
</ComboboxOptions>
</Combobox>This should solve the clipping issue since the portal-ed element is no longer a child of the modal in the DOM tree. 2. Set a higher z-index on the portaled options If your modal has a high [data-headlessui-portal] {
z-index: 9999;
}The |
|
If the combobox lives inside a custom fixed modal, I would treat this as a positioning/clipping problem rather than something you can solve by forcing Two things usually help: <Combobox value={value} onChange={setValue}>
<ComboboxInput className="w-full" />
<ComboboxOptions
anchor="bottom start"
portal
className="z-50 w-[var(--input-width)] overflow-auto rounded-md border bg-white"
>
...
</ComboboxOptions>
</Combobox>
If your modal has its own focus trap, make sure it allows interactions with the portaled listbox. That's the part that often breaks when mixing Headless UI with another modal implementation. If you need the options panel to stay inside the modal subtree, another practical pattern is to create a dedicated portal root inside the modal and portal the options there instead of |
Uh oh!
There was an error while loading. Please reload this page.
ComboboxOptions use
absoluteposition strategy, which can breaks if I render Combobox inside Modal (not headlessui component) which one is rendered usingposition: fixed. Also when Modal is rendering body getsoverflow: hiddento disable page scroll. Maybe somehow we can useposition: fixedstrategy if it's possible?All reactions