Popover
Popover is an anchored overlay widget. It renders a trigger in the normal layout tree and, when open, renders popup content in the flyout portal layer next to that trigger.
Use it for contextual controls such as filter menus, formatting pickers, account menus, or compact inspectors. A popover is larger and more interactive than a tooltip, but less disruptive than a modal dialog.
The important state rule is that the popover does not decide when it is open. Your app state owns is_open. The widget's job is to keep the trigger in the normal layout flow, give it a stable anchor id, and position the popup content relative to that anchor when the state says it should be visible.
Example
use fission::prelude::*;
let popover = Popover {
id: WidgetId::explicit("sort_popover"),
is_open: view.state().show_sort_menu,
on_toggle: None,
on_close: Some(ctx.bind(
ToggleSortMenu(false),
reduce_with!((|state: &mut GlobalState, action: ToggleSortMenu, _| {
state.show_sort_menu = action.0;
})),
)),
trigger:
Button {
child: Some(Text::new("Sort").into()),
on_press: Some(toggle_sort_menu),
..Default::default()
}
.into(),
content:
Menu {
items: vec![
MenuItem::action("Newest", choose_newest),
MenuItem::action("Oldest", choose_oldest),
],
..Default::default()
}
.into(),
}
.into();
Notice that the trigger's own button handles the open and close action. That keeps the event flow explicit.
Field table
| | | |
|---|
| | Stable identity for the anchor and portal entry. | Required. The widget derives an internal anchor id from this value. |
| | Whether the popup content should be visible. | When false, only the trigger is rendered. |
| | Intended toggle action for the trigger. | Present on the public struct, but the current implementation does not invoke it for you. Wire trigger presses on the trigger widget itself. |
| | Action dispatched when the optional backdrop is tapped. | If set, the widget adds a transparent full-screen backdrop behind the popup. |
| | | Always rendered in normal layout. |
| | Popup body shown in the flyout layer when open. | Positioned relative to the trigger and clamped within the viewport. |
Overlay behavior
Popover uses the same flyout layout machinery as menus and tooltips. That means the popup is measured normally, then positioned next to the trigger after layout. Because the popup is portaled, it is not clipped by parent scroll containers or stacking contexts in the way an inline child would be.
This is why popovers are a good fit for controls inside toolbars, tables, and dense panels. The trigger stays exactly where the layout puts it, while the overlay content gets room to escape.
Specific advice
Keep a popover focused on one local task. If it grows into a long workflow, a modal or routed page is usually clearer. Also do not hide essential instructions inside a popover that only appears after an extra click.
The current implementation assumes the trigger already knows how to open the popover. In practice, that means using a button or gesture-aware widget inside trigger and dispatching your own toggle action from there.
Production checklist
For Popover, review the fields that change behavior before treating the widget as finished: id, is_open, on_toggle, on_close, trigger, content. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.
Bind on_toggle, on_close to explicit reducer actions and test that the reducer handles unavailable, duplicate, or invalid input safely.
When child widgets are generated from data, give reordered or filtered rows an explicit WidgetId so retained local state and scroll behavior do not drift between items.
Set id only when identity must be stable across filtering, reordering, diagnostics, or tests; otherwise let Fission derive identity from structure.
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 Popover 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.
flyout, Tooltip, MenuButton, Select, and Combobox.