Diagram - Toolbar and actions

#Usage

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

<Diagram.Root :store="store" page-id="page">
    <Diagram.CommandButton command-id="undo" v-slot="{ getButtonProps }">
        <button v-bind="getButtonProps({ type: 'button' })">Undo</button>
    </Diagram.CommandButton>
    <Diagram.CommandButton command-id="redo" v-slot="{ getButtonProps }">
        <button v-bind="getButtonProps({ type: 'button' })">Redo</button>
    </Diagram.CommandButton>
    <Diagram.Viewport label="Review 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.Viewport>
</Diagram.Root>

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

#UI Composition

Use the root's commands for toolbar, selection and menu actions so each surface uses current policy. This fragment assumes the store from First Diagram.

import { Diagram } from '@primeui/vue-diagram';
import { DiagramToolbarUI, DiagramSelectionActionsUI, DiagramContextActionsUI } from '@ui/diagram';

<Diagram.Root :store="store" page-id="page">
    <DiagramToolbarUI />
    <Diagram.CommandButton command-id="undo" v-slot="{ getButtonProps }">
        <button v-bind="getButtonProps({ type: 'button' })">Undo</button>
    </Diagram.CommandButton>
    <Diagram.Viewport label="Workflow" style="height: 24rem">
        <DiagramSelectionActionsUI />
        <DiagramContextActionsUI />
    </Diagram.Viewport>
</Diagram.Root>

Toolbar and floating actions share root command state. Use DiagramQuickActionsUI instead of mounting both action parts when you want its combined defaults.

Use the copied toolbar for common tools and history. Use a command group for a short application-specific set. Floating selection actions and context menus can use those same command IDs, so availability stays consistent across surfaces.

#Share command state across controls

Select Request and compare Duplicate in the toolbar, selected-node handle and context menu. Enable Read only: editing actions become unavailable while view commands remain useful. New link chooses the path for future connections.

DiagramToolbarUI.title defaults to Workflow editor. drawingOptions defaults to an empty array; each choice is { label, spec: DiagramDrawingSpec }. Supply unique spec types. Drawing still uses the runtime preview/commit flow. The toolbar's default slot appends controls. To replace it, put your own composition in DiagramEditorUI's toolbar slot.

Diagram.CommandButton supplies getButtonProps through its slot. Bind those props to a native button to retain disabled state, policy reason and execution. Pass application handlers into the getter; they run first and can prevent the Diagram handler. Do not bind a second independent click command.

DiagramToolbarUI consumes the surrounding root. Its title defaults to Workflow editor; drawingOptions defaults to an empty array. Each drawing option is { label, spec: DiagramDrawingSpec }. Supply unique spec types for the choices; the part resolves its active drawing choice by type. Draw uses the current runtime preview/commit flow, not an application-created rectangle transaction.

Projected toolbar content appends to its own controls. To replace the toolbar, use the toolbar named slot with your chosen command buttons/groups. Diagram.CommandButton is a slot provider. Bind getButtonProps({ type: 'button' }) to the button you render; it supplies current availability, reason and execution. The slot's content supplies the visible label. The getter also accepts application handlers and refs. Returned ref handlers resolve a Vue component instance through its $el to the native host. Handlers run first and can cancel Diagram handling with event.preventDefault(). The default Diagram.ContextMenu retains menu roles, focus and dismissal; custom menu content must preserve those behaviors.

#Place individual controls

Use the complete DiagramToolbarUI for its supplied composition, or choose the groups your application needs. The independent groups share the surrounding root's DiagramToolbarModel; mounting a second control does not create another editor or command registry.

DiagramToolsUI provides Select/Pan/Connect. DiagramConnectionPathUI chooses the path of future connections. DiagramDrawingUI requires installed shape types in its supplied choices and renders no control when the list is empty. Zoom/Fit and aids are separate so they can live in a status bar or another application region. See the controls without a shell example.

Choose copied DiagramToolsUI, DiagramConnectionPathUI, DiagramDrawingUI, DiagramCommandGroupUI, DiagramZoomControlsUI and DiagramAidsUI for an independent composition. Each uses the surrounding root; extra controls create no second editor. Tools offer Select/Pan/Connect. Path chooses future geometry. Drawing renders no choice when drawingOptions is empty.

useDiagramToolbar() in a descendant component exposes readonly refs such as activeTool, connectionType, selectedCount, zoom, feedback and pending, and actions run, setConnectionType and setDrawing. Use .value in setup; destructure top-level refs for templates. Never assign to those snapshots.

#Bind view preferences to their owner

Copied DiagramAidsUI and DiagramViewControlsUI receive aidOptions and emit aidOptionsChange. Store the emitted options in a parent ref and pass them to both root and control. They do not have an invented v-model contract. Grid, Snap, Rulers, zoom and Fit are runtime preferences outside model history.

#Choose action surfaces deliberately

Use the combined part instead of mounting its constituent surfaces twice. Retain accessible names, disabled reasons and dismissal in custom markup. session.commands.state(id) reports current availability; execution checks again. Store canUndo alone does not include editor policy. Direct host transactions remain legitimate application authority and must enforce their own rules.

Context menus keep unavailable items with a reason. The runtime guards execution; a custom menu must preserve its menu roles, roving focus and close action. Selection handles use the selected node's scene geometry, clip and current zoom.

Application commands belong in root commands or the public registry. Use the existing custom command example to register an action with label, availability and execution, and clean up the owned registration. Reusing an ID on several surfaces does not duplicate its engine. Command IDs are stable application identities; display wording can change.

See Overlays for replacement templates and Commands for shortcuts, results and permission/history semantics. Clipboard operations also need the corresponding browser permission or event path; a menu entry does not grant clipboard access.

#Related Docs

• Architecture
• First Diagram
• API
• Commands
• Overlays
• Editor composition
• History