Tooltip

Fission

Product

▾

Setup

›

Navigation and overlays

›

Tooltip

Tooltip shows a small text hint near another widget.

It is best for short, non-essential explanations such as clarifying an icon button or revealing a keyboard shortcut. A tooltip is not a good place for required instructions, form validation, or workflow-critical information because it may only appear on hover and it disappears quickly.

Fission keeps the state model straightforward here. The widget can become visible because the runtime reports that its trigger is hovered, or because you explicitly force is_visible to true. The tooltip itself does not own any hidden text state or timing state.

Example

use fission::WidgetId;
use fission::prelude::*;

let help = Tooltip {
    id: WidgetId::explicit("save_tooltip"),
    child: Button {
        child: Some(Text::new("Save").into()),
        on_press: Some(save_changes),
        ..Default::default()
    }
    .into(),
    text: "Save your draft without publishing".into(),
    is_visible: false,
}
.into();

Field table

Field	Type	Meaning	Notes / default behavior
id	WidgetId	Stable identity for the trigger anchor and portal entry.	Required. The widget derives its hover anchor from this id.
child	Widget	Trigger content rendered inline.	Required. This is the thing the tooltip is attached to.
text	String	Tooltip message text.	Required. Keep it short. The current implementation caps width at 220.0 logical pixels.
is_visible	bool	Force the tooltip visible even without hover.	Defaults to false. Useful for demos, audits, or non-hover-driven reveal logic.

Overlay behavior

The trigger stays in the normal layout tree. When the tooltip should appear, the widget constructs a small card during component conversion and registers it in the flyout portal layer. The same anchor-positioning rules used by other flyout-based overlays keep it near the trigger and inside the viewport.

Specific advice

Use tooltips sparingly. If many controls need tooltips before they make sense, the underlying user interface probably needs stronger labels or clearer structure.

Also be realistic about targets. Hover is a desktop and pointer-heavy web concept. On touch-first screens, a tooltip is often the wrong pattern entirely. Prefer inline helper text, a Popover, or a clearly labeled control.

Production checklist

For Tooltip, review the fields that change behavior before treating the widget as finished: id, child, text, is_visible. 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.

•

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 Tooltip 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, flyout, Button, and FormControl.