Pattern for calling dialogs as functions (no useState)

[Junnis0123]

I keep seeing variations of the same question: how to open
a dialog from an event handler without wiring useState +
isOpen + onOpenChange every time (#8730, #929, #1504).

We ran into this at work and ended up building a small helper:

const confirmed = await overlay.openAsync<boolean>(({ isOpen, close }) => (
  <AlertDialog open={isOpen} onOpenChange={() => close(false)}>
    ...
  </AlertDialog>
))

Renders inside the React tree, so shadcn themes and context
still work. ~3KB, MIT.

https://overlay-kit.slash.page/en/docs/more/with-design-systems/shadcn
https://github.com/toss/overlay-kit

Curious if anyone else has run into this and how you solved it.

[rajputomsingh]

We've run into the same issue on larger dashboards. The useState + open + onOpenChange pattern is fine for a couple of dialogs, but it starts getting repetitive when every destructive action, invite flow, or confirmation modal needs its own state.

I like the idea of an async API because it keeps the action flow linear:

const confirmed = await confirm()
if (!confirmed) return
await deleteProject()

That said, I can also see why shadcn/ui doesn't include something like this directly. It feels more like an application-level pattern than a component primitive.

Curious how others are handling this today custom dialog providers, Overlay Kit, or some other approach?

[dolanoadriano]

The other half of this shows up once dialogs can be opened from anywhere: two or three of them fire at the same time (a confirm, "session expired", "new version available") and they just stack on top of each other.

I built managed-modals for that part. You wrap the Radix import in components/ui/dialog.tsx (and alert-dialog.tsx) once, give the dialogs a name, and they go through a priority queue: one on screen, the rest wait, and a more important one takes over while the interrupted one comes back as it was.

I haven't tried it with overlay-kit specifically, but it only goes through the open prop, so an <AlertDialog name="confirm" open={isOpen}> returned from overlay.openAsync should be queued like any other, as long as the overlay provider sits inside <ModalProvider>.