ButtonVariant

ButtonVariant is the visual emphasis setting for Button.

It answers a simple design question: how loudly should this action speak? In a real app, not every button should look equally important. The variant lets you express primary, secondary, and low-emphasis actions without changing the underlying action flow.

Example

use fission::prelude::*;
let primary = Button {
variant: ButtonVariant::Filled,
child: Some(Text::new("Save").into()),
on_press: Some(save_action),
..Default::default()
};

let secondary = Button {
variant: ButtonVariant::Outline,
child: Some(Text::new("Preview").into()),
on_press: Some(preview_action),
..Default::default()
};

The two buttons do the same kind of work in the runtime: both dispatch actions. The variant only changes how much visual emphasis the user sees.

Choice table

Choice	Type	Meaning	Notes / default behavior
Filled	ButtonVariant	High-emphasis button with a filled surface.	Default. Good for the main action in a section or dialog.
Outline	ButtonVariant	Medium-emphasis button with a bordered surface.	Good for secondary actions that should still look clearly interactive.
Ghost	ButtonVariant	Low-emphasis button that relies mostly on content and hover/press feedback.	Good for toolbars, menus, inline controls, and dense chrome.

How to choose

Use Filled for the action you most want the user to notice right now. Use Outline when the action is important but not dominant. Use Ghost when the action should stay available without pulling visual focus away from the main task.

Do not treat variants as random styling choices. If every action on a screen is filled, nothing feels primary. If every action is ghost, important flows can disappear into the interface.

Specific advice

Keep the meaning of each variant stable across your product. If Filled means "commit the main action" on one screen but "tiny utility action" on another, users have to relearn the hierarchy every time.

Production checklist

For ButtonVariant, review the fields that change behavior before treating the widget as finished: Filled, Outline, Ghost. 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 ButtonVariant 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.

Button, ButtonContentAlign, MenuButton, and SegmentedControl.