flyout

Fission

Product

▾

Setup

›

Navigation and overlays

›

Flyout

flyout(...) is the low-level helper behind anchored overlays such as popovers, menus, and tooltips.

It does one job: it takes an anchor WidgetId and a popup Widget, then asks the layout engine to place that popup next to the anchor. The popup prefers to appear below the anchor, flips upward if there is not enough room, and stays clamped within the viewport bounds.

Use flyout(...) when the higher-level overlay widgets are too opinionated for your case and you need direct control over the popup content. Most application code should not start here. Popover, Menu, Select, and Tooltip already solve the common anchored-overlay cases and are easier to reason about.

Example

use fission::prelude::*;

let anchor_widget_id = WidgetId::explicit("help_button");
let anchor_id = WidgetId::derived(anchor_widget_id.as_u128(), &[]);

let trigger = Button {
    child: Some(Text::new("Help").into()),
    on_press: Some(toggle_help),
    ..Default::default()
}
.id(anchor_widget_id);

if view.state.show_help {
    let popup = Container::new(Text::new("Keyboard shortcuts live here"))
        .padding_all(12.0)
        .into();

    ctx.register_portal_with_layer(
        PortalLayer::Flyout,
        Some(WidgetId::explicit("help_popup")),
        flyout(anchor_id, popup),
    );
}

The open state still belongs to your app model. flyout(...) only handles the geometry.

Argument table

Argument	Type	Meaning	Notes / default behavior
anchor	WidgetId	The already-laid-out node to position the popup against.	The anchor must exist in the normal layout tree for the current frame.
content	Widget	The popup subtree to place near the anchor.	flyout(...) does not add a backdrop, border, or dismissal logic. Those stay under your control.

Layout behavior

The helper lowers to a special LayoutOp::Flyout marker. During layout, Fission measures the popup content, looks up the anchor's visual rectangle, and computes a viewport-safe placement. This matters for tests and cross-platform parity because the same geometry rules apply regardless of whether the popup is a menu, a tooltip, or a custom panel.

Specific advice

Prefer higher-level widgets when they fit. flyout(...) is easy to misuse if you forget one of the surrounding responsibilities: open state, dismissal behavior, portal layering, and accessibility. In many products, the correct implementation is not just "show a box near a button." It is "show a labeled, dismissible, keyboard-reachable overlay near a button." Popover and menu widgets already cover more of that work.

If you do use flyout(...) directly, give the anchor a stable id, register the popup in the flyout portal layer, and test edge placement near the corners of the viewport.

Production checklist

For flyout, review the fields that change behavior before treating the widget as finished: the fields in the table. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

If this widget appears inside an interactive flow, keep the surrounding action binding in the parent component and test that the flow still has one clear reducer path.

•

Check the semantics tree for the user-facing label or role that makes this widget understandable without relying only on pixels.

•

Add at least one component or harness test that confirms the visible text, semantic role, action dispatch, and layout constraint that matter for this widget in context.

If a screen starts repeating the same flyout setup, extract a named component around this widget. That keeps the reference API small while making product code easier to read and safer for generated code to copy.

Popover, Tooltip, Menu, Select, and Portal.