Sign up (with export icon)

OverlayHostOptions

Api-interface iconinterface

The configuration of an OverlayHost: callbacks resolving where the feature UI lives, called on every sync, and optional borrowed collaborators.

Properties

  • Chevron-right icon

    An existing body collection to host instead of creating one – used by EditorUI, whose collection belongs to the EditorUIView. A borrowed collection is not destroyed by destroy; its owner destroys it.

  • Chevron-right icon

    resolveInlineContainer?: () => ( ShadowRoot | HTMLElement | null | undefined )

    Resolves the DOM node holding the feature's inline UI – the parts the feature renders directly into its own container (buttons, badges, and similar), as opposed to the floating views it puts into the bodyCollection. Usually the container element itself, but it may also be a shadow root, when that root is all the feature knows of the tree its inline UI lives in.

    The host registers this node with its shadowRootRegistry so the shared TooltipManager can drive the tooltips of that inline UI. This matters when the inline UI sits inside a shadow root: in events observed at the document level the elements inside the root are hidden behind their shadow host, so the tooltip manager has to attach its listeners inside each registered root – without this node being registered, the tooltips of the feature's inline UI would never fire. The node is re-resolved on every sync, so the registration follows the feature if it moves to a different container.

    Omit it when the feature has no tooltip-bearing UI outside the body collection, or when those nodes are registered directly with the shadowRootRegistry instead.

  • Chevron-right icon

    resolveMountTarget: () => ( ShadowRoot | HTMLElement | null )

    Resolves the element or shadow root the bodyCollection should be mounted in – that is, where the feature's floating views end up in the DOM. The collection is appended as a top-level child of this target, which should meet two requirements at once:

    • it adopts the same styles as the root the feature's UI lives in – typically a shadow root sharing that root's adopted stylesheets – so the floating views are styled like the rest of the feature's UI;
    • it sits at the end of document.body, both so that overflow on the ancestors between the feature and the document body cannot clip the floating UI, and so that it paints above the rest of the UI (DOM order decides paint order within a stacking context) instead of below it.

    A dedicated shadow root appended at the end of document.body that mirrors those styles satisfies both. The target is therefore not required to be the feature's own root, and to stay unclipped and on top it usually should not be nested inside the feature's container.

    Return null to keep the collection unmounted – for example while the feature's container is not connected to the document yet, so there is no root to resolve. The target is re-resolved on every sync, so the collection is re-mounted if the feature moves to a different root and unmounted once its container goes away.

    getOverlayMountRoot covers the common resolution from an anchor node (the feature's container): the anchor's shadow root when it lives in one, document.body in the light DOM, or null while the anchor is detached.

  • An existing shadow root registry to use instead of creating one – used by EditorUI, which feeds its registry from many places (editables, toolbars, the menu bar) and shares it with other features. A borrowed registry is not destroyed by destroy; its owner destroys it.

  • Chevron-right icon

    A borrowed reference to the shared tooltip manager to register the body collection with, instead of the host acquiring (and on destroy releasing) a reference of its own – used by EditorUI, so an editor keeps counting as a single holder of the singleton. The holder of the borrowed reference releases it.

  • Chevron-right icon

    An emitter whose update event signals that the UI may have moved or re-rendered (an editor passes its EditorUI). The host re-syncs on every such event and the shared tooltip manager repositions a pinned tooltip.