# Dialog > Modal dialogs via a service that wraps @angular/cdk/dialog. Open any component as a dialog and read its close result as a Promise. Source: https://ngwr.dev/reference/components/dialog Kind: Service, Directives, CDK Dialog ## Installation ```angular-ts // The component that OPENS a dialog injects the service. import { WrDialog } from 'ngwr/dialog'; @Component({...}) export class MyComponent { private readonly dialog = inject(WrDialog); } // The component OPENED as a dialog imports the layout directives it uses. // Selector -> class: [wrDialogTitle] -> WrDialogTitle, and so on. import { WrDialogClose, WrDialogContent, WrDialogFooter, WrDialogTitle } from 'ngwr/dialog'; @Component({ imports: [WrDialogTitle, WrDialogContent, WrDialogFooter, WrDialogClose], templateUrl: './confirm.html', }) export class ConfirmComponent {} ``` ## Open a dialog ```angular-ts const ref = dialog.open(ConfirmComponent, { data: { title: 'Delete', message: 'Are you sure?' }, width: '24rem', }); const ok = await ref.awaitClose(); // result from ``` ```angular-html // Inside the opened component. Every attribute below is a directive: // imports: [WrDialogTitle, WrDialogContent, WrDialogFooter, WrDialogClose]

Delete

Are you sure?

Cancel

Delete

``` ```html dialog.open(ConfirmComponent, { data, width: '24rem' }) ``` ## Closing from the content `[wrDialogClose]` covers close-on-click. When the dialog has to dismiss itself — after a save resolves, or when a store signal flips — inject its `WrDialogRef` and call `close(result)`. ```angular-ts // Inside the opened component — close without a click. import { WR_DIALOG_DATA, WrDialogRef } from 'ngwr/dialog'; @Component({...}) export class EditUserComponent { private readonly ref = inject(WrDialogRef); protected readonly data = inject(WR_DIALOG_DATA); save(): void { this.store.saveUser(this.form.value); this.ref.close(true); // the caller's awaitClose() resolves } } // The class token already types the generics — no cast, no WR_DIALOG_REF needed: private readonly ref = inject>(WR_DIALOG_REF); ``` ## Lifetime — the dialog outlives its opener `WrDialog` is root-provided, so a dialog is not tied to the component that opened it: destroy that component and the panel, its backdrop and the `cdk-global-scrollblock` stay on the page. Navigation is the one case handled for you — `closeOnNavigation` is on by default. Everything else (an `@if` that removes the opener, a row dropped from a list) is the caller's job. ```angular-ts // A dialog outlives the component that opened it. `WrDialog` is root-provided // and the panel's injector hangs off the root environment injector, so an // `@if` that removes the opener leaves the panel, its backdrop and the // `cdk-global-scrollblock` on the page. (Navigation is the one exception: // `closeOnNavigation` is on by default.) Close the ref when you go away. import { DestroyRef, inject } from '@angular/core'; @Component({...}) export class MyComponent { private readonly dialog = inject(WrDialog); private readonly destroyRef = inject(DestroyRef); async confirmDelete(): Promise { const ref = this.dialog.open(ConfirmComponent); const stop = this.destroyRef.onDestroy(() => ref.close()); // awaitClose() is a Promise, so takeUntilDestroyed() does not apply to it — // that operator takes an Observable. Two ways to not act on a stale result: const ok = await ref.awaitClose(); stop(); // nothing left to cancel if (ok) this.store.remove(); } } // Or subscribe instead of awaiting, and takeUntilDestroyed() does apply — // `ref.closed` is an Observable, and the ref is the same one either way. import { takeUntilDestroyed } from '@angular/core/rxjs-interop'; ref.closed.pipe(takeUntilDestroyed(this.destroyRef)).subscribe(ok => { … }); ``` ## The close button Dialogs render a dismiss (×) in the top-right corner by default, on top of closing via backdrop click, Escape, and any element carrying `[wrDialogClose]`. Opt out per dialog with `closable: false`. `` and `WrDrawerManager` take the same `closable` / `closeLabel` pair. ```typescript // The × comes for free — nothing to add. It sits in the panel's top-right // corner, is labelled from the `dialog.close` i18n key, and the title row // reserves the gutter so a long heading wraps instead of running under it. dialog.open(EditUserComponent); // Turn it off when the content already owns its dismiss, or when the dialog // must be resolved through its own actions: dialog.open(EditUserComponent, { closable: false }); // Override just the accessible name: dialog.open(EditUserComponent, { closeLabel: 'Discard changes' }); ``` ## Where focus goes, and where it comes back On open, focus moves into the panel: to whatever carries `cdkFocusInitial` if anything does, and otherwise to the first tabbable element in DOM order. The built-in ✕ is appended after your content, so it is the LAST tabbable element rather than the first — a dialog whose content starts with a text field opens with the caret in that field. A panel with nothing tabbable in it takes no focus at all; Escape still closes it, because the key is handled by the overlay rather than by whatever is focused. ```angular-html

Rename project

Cancel

Save

``` On close, focus returns to the element that was active when `open()` was called — captured then, restored after the panel is disposed. All four dismissal paths go through the same `WrDialogRef.close()`, so Escape, the ✕, a `[wrDialogClose]` button and a backdrop click all restore it. The one case it cannot cover is a trigger that no longer exists: if the button that opened the dialog has been removed from the DOM meanwhile, focus lands on `` and the next Tab starts from the top of the document. Move focus yourself after `awaitClose()` when the dialog's own result removes its trigger. Focus is trapped inside the panel while it is open, and the panel announces itself with `role="dialog"` plus `aria-modal="true"`. The rest of the page is _not_ marked `inert` and carries no `aria-hidden` — the modality is the focus trap and the `aria-modal` claim, which is what screen readers act on, and the backdrop, which takes every pointer event aimed at the page. What is not covered is everything that ignores both — find-in-page, and a reading mode that walks the DOM rather than the accessibility tree. If your app needs the harder guarantee, set `inert` on your own root element for as long as the dialog is open; the library does not, because choosing which subtree to freeze is not something it can know. ## Overlays are in the top layer, so z-index cannot reach them CDK 22 promotes every overlay by calling `showPopover()` on its host, which puts the panel and its backdrop in the browser's top layer. The top layer is ordered by the moment of promotion and sits above the whole page — no `z-index`, stacking context or DOM order in your application can put anything over it. A sticky header at `z-index: 100000` still renders under a dialog backdrop, and a click where it appears goes to the backdrop and closes the dialog. ```typescript // The overlay container is isolated, and that is what `provideWrOverlay()` // promises — not a place in your z-index scale. These do nothing: // // .wr-overlay-container .cdk-overlay-pane { z-index: 1100; } // header { z-index: 100000; } // // To opt the whole application out of the top layer and back into ordinary // stacking, configure the CDK itself at bootstrap: import { OVERLAY_DEFAULT_CONFIG } from '@angular/cdk/overlay'; bootstrapApplication(AppComponent, { providers: [ { provide: OVERLAY_DEFAULT_CONFIG, useValue: { usePopover: false } }, ], }); // Opting out is a real trade: overlays go back to being clipped by an // ancestor's `overflow` and to competing on z-index with everything else. ``` Two consequences worth knowing before you spend an afternoon on CSS. Chrome that must stay above a dialog — a cookie bar, a support widget — has to be in the top layer itself (its own `popover` or native `