Diagram - Overlay templates

#Usage

Keep overlay parts inside Diagram.Viewport and their triggers under the same root. Slots replace content while the runtime supplies placement and shared command ownership. This composition assumes the store from First Diagram.

import { Diagram } from '@primeui/vue-diagram';

<Diagram.Root :store="store" page-id="page">
    <Diagram.TooltipTrigger text="Duplicate the selected step" v-slot="{ getTriggerProps }">
        <button v-bind="getTriggerProps({ type: 'button' })">Help</button>
    </Diagram.TooltipTrigger>
    <Diagram.Viewport label="Workflow" style="height: 24rem">
        <Diagram.UserHandle command-id="duplicate" v-slot="{ command, execute }">
            <button type="button" :disabled="!command.available" :title="command.reason" @click="execute">Duplicate</button>
        </Diagram.UserHandle>
        <Diagram.ContextMenu />
        <Diagram.Tooltip v-slot="{ text }"><span>{{ text }}</span></Diagram.Tooltip>
    </Diagram.Viewport>
</Diagram.Root>

Keep positioned overlays in the viewport and triggers under the same root. Replacement templates preserve their own names, disabled states and focus behavior.

This skeleton assumes an initialized store with page page. Use First Diagram for model creation, style imports and store disposal.

Runtime overlay parts own their context and placement. A template replaces their content. Set :default-presentation="false" on Diagram.ContextMenu or Diagram.Tooltip when the template also supplies its own surface, padding and typography. Structural positioning and interaction behavior remain active. Keep the runtime part around the template so commands, clipping, keyboard dismissal and focus restoration still use the shared root.

#Replace a handle, menu and tooltip

Select a task for the custom Duplicate handle. Open the context menu with a right-click or the Context Menu key. Hover or focus Help for a root-scoped tooltip.

Select a task for Duplicate, right-click or use the Context Menu key, then focus or hover Help. Each control uses the same root's commands and current permissions. Keep names, unavailable reasons and keyboard behavior when replacing its markup.

Slot values are plain readonly snapshots and actions. Components nested within the corresponding part can read useDiagramUserHandleContext, useDiagramContextMenuContext, useDiagramTooltipContext or useDiagramInspectorContext. Their snapshot fields are refs in setup. These accessors throw outside their provider.

#Use the supplied overlay presentation

DiagramContextActionsUI supplies a menu surface and command entries; DiagramTooltipUI supplies a tooltip surface. Both retain the corresponding runtime overlay and opt out of its default visual presentation. Import them from your copied Diagram UI directory and mount only one tooltip renderer per root. Use the runtime parts with replacement definitions for entirely custom UI.

Copied DiagramContextActionsUI and DiagramTooltipUI retain the runtime parts and provide their surfaces. Import them from your application's copied UI directory. Mount one tooltip renderer per root. Use the copied tooltip's default slot to replace its content, or edit the copied part to replace its surface.

Runtime Menu/Tooltip accept defaultPresentation, initially true. Use false when you supply all content yourself. Keep the runtime owner mounted so its lifecycle and dismissal still operate. User-handle content comes from its scoped slot.

#Respect coordinate and visibility ownership

The user handle anchors to the selected node's world bounds. The viewport transforms it; inverse zoom keeps its control size and offset in CSS pixels. Hidden nodes, a clipped anchor or active node rotation suppress its position. Do not apply a second world-to-screen transform in the custom template.

Context-menu and tooltip popovers use client coordinates and clamp to the browser viewport. Menus and tooltips are root-scoped; opening a menu dismisses a tooltip. The tooltip associates its ID with the invoker's aria-describedby and removes that association when hidden or destroyed. Escape/dismissal and disconnected anchors follow the runtime's cleanup.

The handle uses the node's scene bounds and the session's world-to-screen conversion; its offset is in CSS pixels. Do not apply another scene transform. Menus/tooltips position from their client anchor. Keep custom surfaces within the space available in your application and check their placement in constrained containers. UI layout is separate from saved node geometry.

#Keep menu and command behavior intact

Use role="menuitem", tabindex="-1" and aria-disabled for custom menu entries. The part owns roving focus, arrows/Home/End, Enter/Space execution and Escape. Unavailable commands still expose their reason; menu.execute performs the current check. A close action uses menu.close() to restore invoker focus.

A tooltip trigger reacts to hover/focus and Escape. It describes an existing control; it should not be the only place an essential instruction or action appears. See Toolbar and actions, Inspector and UI-parts reference.

Use native buttons with role="menuitem", names, unavailable reasons and appropriate disabled state. Call the supplied execute(id) from the button; execution checks availability again. The runtime handles arrows/Home/End and Escape, while native button activation handles Enter/Space. close() restores invoker focus. Pass trigger attributes and handlers through getTriggerProps; the tooltip owns its aria-describedby association and hover/focus lifecycle. A tooltip should supplement an existing control, not contain its only essential instruction or action.

#Related Docs

• Architecture
• First Diagram
• API