Feedback on closeOnInteractOutside and why its current implementation might not be the best in real-world apps

[baptisteArno]

Currently, if adding a portalled element (like a list) in a dialog with closeOnInteractOutside set to true, if you end up clicking on this list and the mouse is outside the dialog content, it will close the dialog altogether.

I see that maintainers are advising not to use portalled elements in dialogs, but I really feel like this is wrong..

Also what about toast notifications? If you happen to have one and dismiss it, it will close the opened dialog.

So I ended up composing my dialog components like so:

<ArkDialog.Root
  closeOnInteractOutside={false}
>
  <Portal>
    <ArkDialog.Backdrop className="fixed inset-0 w-full bg-gray-12/50 data-[state=open]:animate-in data-[state=open]:fade-in data-[state=closed]:animate-out data-[state=closed]:fade-out" />
    <ArkDialog.Positioner
      className="flex justify-center items-start fixed top-0 w-full py-12 h-full overflow-y-auto pointer-events-auto"
      onClick={onClose}
    >
      <ArkDialog.Content
        className={cn(
          "relative bg-gray-1 p-6 rounded-xl w-full max-w-xl data-[state=open]:animate-in data-[state=open]:slide-in-from-bottom-5 data-[state=open]:fade-in data-[state=closed]:animate-out data-[state=closed]:slide-out-to-bottom-5 data-[state=closed]:fade-out flex flex-col gap-4",
          className
        )}
        onClick={(e) => {
          e.stopPropagation();
        }}
      >
        {children}
      </ArkDialog.Content>
    </ArkDialog.Positioner>
  </Portal>
</ArkDialog.Root>;

This definitely feels hacky but I could not find any issue with this in a complex app like Typebot.

I close the dialog, only if the Positioner is clicked and stop the click propagation on content click

With this I also needed to set pointer-events: auto !important; to the body. So that outside elements like toasts are clickable even if a dialog is opened.

All this to say that I am a bit surprised with the current dialog implementation / behavior and that it really does not work for my real app needs. So I am wondering if I misunderstood something.

[segunadebayo]

There are two alternative approaches to consider when using the popover within a dialog.

• Set the Portal container target to the Dialog.Content, which will ensure it is rendered within the dialog's content, keeping the focus trap intact.

• Set the positioning strategy of the floating UI component to fixed

<Popover.Root positioning={{ strategy: "fixed", hideWhenDetached: true }}>
  {/* ... */}
</Popover.Root>

We'll add this to the docs.

[baptisteArno]

I think it would solve a lot of the issues I mentioned, but not the Toast focus issue though.

This means I would need to create a React context and never forget to manually inject the parent portal ref. Can't we maybe have a mountToNearestPortalledParent prop to Portal?

Also wondering why strategy fixed is not the default strategy? Any drawbacks I should be aware of if I use fixed positioning for portalled floating elements?

[segunadebayo]

Excessive use position fixed combined with animations can impact paint performance.

You could also consider passing a “withPortal” or “portalled” prop to the dialog so you can disable portals as needed.

By design, focusing a toast should not make the dialog close. If you have a reproduction, you can open an issue.