Use of Dialog (controlled) without Dialog.Trigger?

[janhoogeveen]

Hey everyone,

I'm trying to open a Dialog on route changes. The use case here is that I want a modal window on certain drilldown pages in Next.js using a catch-all route, and hide it when certain parameters are missing. I thought making a controlled Dialog would be a good solution here.

The way I open the Dialog is as follows:

1. I start at /main/:mainId
2. I navigate to /main/:mainId/sub/:subId though a next/link
3. Thanks to a useEffect hook listening to :subId, I set the Dialog to open.

<Dialog.Root open={isToolkitOpen}>

For the most part this is working as expected. There is one issue though. Once I close the Dialog, on touch devices things like sliders don't work anymore. They don't respond to any swipe events until you tap on a non interactive part of the page. I suspect it's because Dialog tries to reset focus to the previous focus state and it can't find the Trigger. Or any trigger for that matter.

The docs say this about it.

Escape key

Closes the dialog and moves focus to Dialog.Trigger.

I'm not using a Dialog.Trigger. Could this be the cause for this behaviour? It's not entirely clear for me if a Dialog implementation needs to use all parts listed in the documentation.

Update 1
Looks like the body has pointer-events: none set to it, which disappears as soon as I click or tap somewhere in the body.

Update 2
This is probably an issue due to the bodyPointerLock util, not because of the absence of a Trigger

[benoitgrelard]

Hey @janhoogeveen, generally you want to avoid showing dialogs without any user interactions, that's why the trigger exists as it is an integral part of the accessibility of the pattern (focus management, attributes, etc). I think that's generally a dark pattern UX-wise to open without user intent.

Regardless, in your case, if you don't use it, what you describe sounds like it could be a bug potentially.

Can you send me a quick sandbox reproducing it so I can take a look and see if it's actually a bug or just mis-use of the component?

Thanks 🙏

[janhoogeveen]

Oh yes, for context, the reason I don't use a Trigger is because we have tens of list items that could open a modal window, and I want that content to be visible on a new URL, not through some internal state. I thought you could only have one trigger attached to a dialog?

[benoitgrelard]

A bit tricky to visualise the situation exactly here, but there are things you can do architecture-wise when you want to have multiples of the same dialogs. Quite often, people try to re-use the same instance, instead of going towards component re-use.

If you can provide a simplified sandbox for this example, I'm happy to take a look.

[cdeutsch]

I'm also finding the need to do a "controlled" Dialog.

Current site has "url driven" dialogs, like @janhoogeveen is describing. Eg.

• List of items
• Click item link /items/:itemId
• Render Dialog with Overlay if itemId present

Accessibility wise, not sure "url driven" dialogs are a good idea, but that's how it's currently designed and programmed.

Not being able to directly link to an item's detail dialog would be a poor experience for a lot of users.

[jjenzz]

it sounds like your link could be the Dialog.Trigger?

<Dialog.Trigger asChild><a href="/items/:itemId"></a></Dialog.Trigger>

or if that link takes you to a new page where the original link becomes unmounted, you can use the open and onOpenChange props to control the dialog on the new page.

[rohanrehman]

Hey @janhoogeveen, generally you want to avoid showing dialogs without any user interactions, that's why the trigger exists as it is an integral part of the accessibility of the pattern (focus management, attributes, etc). I think that's generally a dark pattern UX-wise to open without user intent.

Regardless, in your case, if you don't use it, what you describe sounds like it could be a bug potentially.

Can you send me a quick sandbox reproducing it so I can take a look and see if it's actually a bug or just mis-use of the component?

Thanks 🙏

There are more user triggers than just buttons, or the button / intent was triggered on a different page.
If you'de like further details on use cases, Nexjs intercepting route in login modals is a great one!

[kylemh]

Hey @benoitgrelard you mentioned that dialogs that render without a trigger feel like a dark pattern, but what about beforeunload events, timer-based dialogs, or dialogs that render as a reaction to an API response?

There are countless ways that I've been asked to display a modal without a trigger. I feel like the API of Dialog is really limiting on this front.

[andy-hook]

@kylemh Cheers for expanding on the “timer-based“ uses, 100% agree that more examples would help folks. We even worked on a “Recipes” concept recently as part of an internal hackweek because we feel there’s a missing resource to solve these types of questions. e.g. dialog on async form https://codesandbox.io/s/form-data-async-dialog-ntqgpe?file=/src/App.js

i wonder if the Dialog could log a warning if there is no Dialog.Trigger that instructs user to pass a restoreFocusElement prop to the dialog? it would accept a node and would silence the warning.

@jjenzz Yeah something like this could be helpful.

[kylemh]

I ended up at that solution jen outlined, but I was essentially worried that I was doing something inaccessible. Even if I was confident it was accessible, it feels really confusing to have both explicit (code-written) and implicit (internal Dialog state) controls. I made an abstraction where it's either-or. Dialog.Trigger nor Dialog.Close are not exposed, so it's all driven by props and the render prop for dismissing that I mentioned before. I guess - even here - there's still some implicitness (overlay clicks and hitting escape key).

At the very least it sounds like y'all are okay with another example for Dialog docs regarding async form submission in-Dialog. Mind if I contribute that?

[andy-hook]

At the very least it sounds like y'all are okay with another example for Dialog docs regarding async form submission in-Dialog. Mind if I contribute that?

Absolutely! 🙏

[benoitgrelard]

@jjenzz I don't like the idea of the restoreFocusElement as it doubles what onCloseAutoFocus does already.

[jjenzz]

@benoitgrelard fair, same idea applies tho, just log a warning that tells them to implement onCloseAutoFocus instead.

[cuginoAle]

Hi, I am having a similar issue. I need to show a confirm box if the user tries to navigate away from a page containing an unsaved form.
On route change I set my state var show to true and the modal pops-up. On close I would expect the focus to be restored to the navigation item the user clicked on.. but this doesn't seem to be the case.
Is this because the modal doesn't contain a Trigger?
IS there any way to work around this?

cheers

[kylemh]

What if one uses window.beforeunload? In that situation, wouldn't you not want focus to return to the trigger but rather the previously focused element?

[cuginoAle]

I got that, what I mean is that I shouldn't be forced to use the Trigger to get the focus restored.
Say I have ten possible CTAs to trigger a modal dialog (in my case a nav menu and other links in the footer); in this scenario I am not sure how to write some clean and maintainable code (using the Trigger) to implement a Modal dialog that would restore the focus on close.
On the other hand, if I use the onCloseAutoFocus callback then I need to manually keep track of whateverWasFocusedBeforeRef to restore the focus... which is something the lib could do for me.
Is focus restoration the only reason to have the Trigger?

[benoitgrelard]

Is focus restoration the only reason to have the Trigger?

It isn't the only reason, the trigger also contains other accessibility attributes like aria-haspopup, aria-expanded and aria-controls.

I am not sure how to write some clean and maintainable code (using the Trigger) to implement a Modal dialog that would restore the focus on close.

It's a case of creating a reusable component, rather than trying to reuse a single instance. These are old demos, but take a look at them. You could either:

• reuse the whole dialog: https://codesandbox.io/s/reused-dialog-lwmpj
• reuse the content if you need different triggers: https://codesandbox.io/s/reused-dialogcontent-0oikl

But the possibilities are really endless given they are just React components all the way down.

Hope this help!

[cuginoAle]

Thanks for taking the time to reply and provide examples.
I am still not convinced the API provides the best dev experience but I am sure this is something that has already been discussed between you maintainers.

Once again thanks and keep up with the good work!

[nemethricsi]

@benoitgrelard What is with the situation when I need to use a controlled dialog? I have no trigger exposed. Can I get focus back somehow after closing the dialog?

[NazarK0]

Hi there! I`m having issue with Dialog and Trigger too. In my form I have control panel with saving options, and on click any of this option should open a dialog with progress bar. But it only should appear if form valid, and validation occur also on click this button. Could anyone show how to solve this issue?

[SoftChunck]

Its simple, Dialog require trigger right, pass a button as a trigger and give button some id like "alert", hide the button from ui using CSS, and then when ever you want to trigger an Dialog through a click #1678 by code like, document.getElementById('alert').click()

[kylemh]

Not only is that not simple (very confusing for a dev to come on and figure all that out from existing code), but it's inaccessible for people that use assistive technology and against the spirit of this library.

[jalooc]

Another case in which having this api does not hold up is opening a modal from a popover menu. I.e. you have a button that opens a menu of which an item's click triggers opening a modal. You usually want the menu to hide upon an item click, but if we hide (unmount) that menu, the trigger disappears and so does the entire modal. The only way to solve this with the current api is probably using some hacks around keeping the modal rendered, but not visible, which is pretty dirty.

[jjenzz]

there are examples of how to handle that here #1836

[jalooc]

Thanks for that link @jjenzz , it's got some nice patterns 👍 But I'm afraid it does not really solve the overal problem, only presents particular workarounds for particular aspects of the problem. Applying those patterns would either/and:

1. hinder custom modal reusability (if I have a custom modal that I reuse in other places, I can't reuse it with some of the suggested patterns cause the part of the modal's logic lays inside the menu logic);
2. make it impossible to have different dialog root logic for each modal;
3. hinder atomicity and composability (the suggested patterns make the menu tightly coupled with modal - what if I don't want to use any modal in some instances of the menu).

All the above points are just one, not uncommon real life scenario: A composable popover menu whose items passed through props that can trigger arbitrary logic, a dialog opening being only one of the possibilities.

---

As much as I admire Radix, looking at the number of problems that devs encounter with the Dialog's api and the multitude of workarounds to overcome them depending on particular case, I think the Dialog api is just a pain to work with, making otherwise basic logic really hard to achieve.

I realize that the Dialog's api shape is dictated by accessibility, but can't the Dialog's architecture be based a global manager for opened modals (probably like in most/all other libraries), and have the accessible trigger elements at the same time? I don't think these are exclusive ideas.

I also realize that collocation is behind the choice, but then - modals in general are global beings, so, while I'm a huge defender of collocation myself, imho modals management is a very natural case for a little bit of global state. (although if I understood your article correctly, you'd still consider this kind of global state collocated to the Dialog component, if archtectured properly, so even better 🙂)

[CodeSmith32]

I have yet another situation; I'm hoping the solution's already out there:

I have a modal window that opens by some normal button, etc. Somewhere on this modal is a button.
When clicked, the current modal window closes, and a different modal opens.

In this case, similar to the Dropdown Item, there is a clear trigger that's inside a component that disappears once triggered. Only, in this case, it's in another modal.

Following the same logic in #1836 for the Dropdown, one might think to put the second dialog's Trigger inside the first dialog's Content and then wrap the first dialog inside the second. But if I'm guessing correctly, sticking a trigger inside of a dialog's content will link to that dialog, not one that is wrapping it. Is that correct?

e.g.

<Dialog.Root> {/* second dialog */}

  <Dialog.Root> {/* first dialog*/}

    <Dialog.Trigger> {/* open first dialog */}
      <button>Open first dialog</button>
    </Dialog.Trigger>

    <Dialog.Portal>
      <Dialog.Overlay />
      <Dialog.Content>

        <p>First dialog content</p>

        <Dialog.Trigger> {/* This trigger links to the first dialog, not the second, doesn't it? */}
          <Dialog.Close>
            <button>Open second dialog</button>
          </Dialog.Close>
        </Dialog.Trigger>

      </Dialog.Content>
    </Dialog.Portal>
  </Dialog.Root>

  <Dialog.Portal>
    <Dialog.Overlay />
    <Dialog.Content>
      <p>Second dialog content</p>
    </Dialog.Content>
  </Dialog.Portal>

</Dialog.Root>

If this is the case, how could this situation be handled correctly?

[CodeSmith32]

Or should I just disable the trigger?

It sounds like everyone's recommending against this, but it appears the Trigger can simply be disabled by hiding it. Then the dialog can be opened programmatically with open and onOpenChange.

<Dialog.Trigger style={{display: "none"}} />

// or with Tailwind:
<Dialog.Trigger className="hidden" />

For my situation, this leads to the following possible solution:

const [open, setOpen] = useState(false);

return <>
  {/* first dialog*/}
  <Dialog.Root>
    <Dialog.Trigger> {/* open first dialog */}
      <button>Open first dialog</button>
    </Dialog.Trigger>

    <Dialog.Portal>
      <Dialog.Overlay />
      <Dialog.Content>

        <p>First dialog content</p>

        <Dialog.Close>
          <button onClick={() => setOpen(true)}>
            Open second dialog
          </button>
        </Dialog.Close>

      </Dialog.Content>
    </Dialog.Portal>
  </Dialog.Root>

  {/* second dialog */}
  <Dialog.Root open={open} onOpenChange={setOpen}>
    {/* hide second dialog's trigger */}
    <Dialog.Trigger style={{display: "none"}} />

    <Dialog.Portal>
      <Dialog.Overlay />
      <Dialog.Content>

        <p>Second dialog content</p>

      </Dialog.Content>
    </Dialog.Portal>
  </Dialog.Root>
</>

But again, I'd lean toward a more recommended solution if there is one..

[reillo]

I resorted to use different library such as https://headlessui.com/ for the dialog.

[rohanrehman]

Thanks for sharing the team there is quite talented!

[0x1h]

only one thing that comes in my mind is to make custom ref and apply it to Dialog.Close I know its really bad practice but it works pretty well

<DialogClose ref={closeDialogRef} className="hidden" />

closeDialogRef.current?.click();

[kluplau]

Another approach, quite similar to this, is using useImperativeHandle.

In your Dialog component:

export interface DialogRef {
  open: () => void
  close: () => void
}

export const Dialog = forwardRef<DialogRef, Props>(
  (props, ref) => {
    const [open, setOpen] = useState(false)

    useImperativeHandle(ref, () => ({
      open: () => setOpen(true),
      close: () => setOpen(false),
    }))

    return (
      <RadixDialog.Root open={open} onOpenChange={(open) => setOpen(open)}>
      ....

Where you use your Dialog component

  const dialog = useRef<DialogRef>(null)

  dialog.current?.open() // Call this any where in the scope where the useRef is defined.

  return (
    <Dialog
      ref={dialog}
      ...