Dialog

Installation

Install @kamod-ch/ui, then compose Dialog, DialogTrigger, and DialogContent as in the snippet below. The default modal is centered; for immersive full-viewport layouts use presentation="slot" and apply overlay + panel classes on DialogContent yourself (see Usage). Motion is optional — see With Motion for @kamod-ch/ui-motion.

pnpm add @kamod-ch/ui

The @/components/kamod-ui/… imports in these examples refer to local source files. Configure that alias when copying source, or use the corresponding exports from @kamod-ch/ui when installing the package. Connect the global theme CSS and Tailwind source detection before your first render.

Usage

Default DialogContent is presentation="modal" (backdrop + centered panel). If your code used to put **fixed inset-0**, **flex items-center justify-center**, and **bg-black/50** on DialogContent itself, you must set **presentation="slot"** — otherwise you get two backdrops and a nested centered shell. Same pattern as AlertDialogContent and the docs “View Markdown” dialog. Width-only classes like sm:max-w-md on modal are fine without slot. lockBodyScroll defaults to true on Dialog.

import { Dialog } from "@/components/kamod-ui/dialog";

Accessibility

Build the complete interaction, including the parts outside Dialog. The notes below distinguish the current implementation from the labels, content and behavior your application supplies. Start with the live preview, check the props and data reference, and test the finished composition with real content rather than assuming that an unchanged visual example covers every use case.

import {
  Button, Dialog, DialogTrigger, DialogContent,
  DialogHeader, DialogTitle, DialogDescription,
} from "@kamod-ch/ui";

export function ExportDetails() {
  return (
    <Dialog>
      <DialogTrigger asChild><Button type="button">Export details</Button></DialogTrigger>
      <DialogContent>
        <DialogHeader>
          <DialogTitle>About this export</DialogTitle>
          <DialogDescription>The export includes the currently visible records.</DialogDescription>
        </DialogHeader>
      </DialogContent>
    </Dialog>
  );
}

Verify the complete interaction

Check behavior as well as markup. Work through these scenarios in the application where the component will be used. Automated checks can help find structural problems; also review the reading experience with a screen reader, keyboard focus and the actual feedback from your application.

1. Open, traverse and close without a pointer; confirm focus does not escape into the background.
2. Inspect the dialog's name and description, including content with long text or validation errors.
3. Submit, dismiss and remove the opener in separate flows; verify return focus and body scrolling recover.

Recheck the result after changing theme tokens, translations or class overrides. Include text enlargement, narrow layouts and reduced-motion settings where animation is present. Inspect the component source when a behavior differs from your expectation; a role or state attribute does not implement keyboard interaction by itself.

For background, read the WAI-ARIA authoring guidance and keyboard interface guidance. These explain the patterns; verify browser and assistive-technology behavior for the implementation and audience you actually support.

Build it into your interface

Use the Dialog examples as a starting point, then review the behavior in the context of your own screen. Layout, state and content should work together.

import type { ComponentChildren } from "preact";

export function ExampleSurface({ children }: { children: ComponentChildren }) {
  return (
    <div class="grid min-w-0 gap-4 rounded-lg border border-border bg-card p-4 text-card-foreground sm:p-6">
      {children}
    </div>
  );
}

Sources & design references

Follow Dialog from its implementation to the ideas behind your own composition. Start with the local API, explore a visual direction, then bring the result back to your app’s shared styles.