MenuItem

MenuItem is a data type, not a standalone widget.

You encounter it when building a Menu or MenuButton. Each item describes one visible row in the menu, and it may also carry an icon source such as scalable vector graphics (SVG) content plus the action that should fire when the user selects it.

Example

use fission::prelude::*;

let items = vec![
MenuItem {
    label: "Rename".into(),
    icon: None,
    on_select: Some(rename_action),
},
MenuItem {
    label: "Duplicate".into(),
    icon: None,
    on_select: Some(duplicate_action),
},
];

These items are only data until a parent widget such as Menu turns them into visible rows.

Field table

Field	Type	Meaning	Notes / default behavior
label	String	Visible text for the menu row.	Required. Keep labels short and action-oriented.
icon	Option<String>	Optional icon source shown before the label.	Defaults to None. Typically a scalable vector graphics (SVG) string used by the icon helper.
on_select	Option<ActionEnvelope>	Action dispatched when the row is chosen.	Defaults to None. An item with no action is visually present but effectively inert.

How action flow works here

Unlike Combobox or SegmentedControl, MenuItem does not generate actions from a closure. You hand it the final ActionEnvelope up front. That makes it a good fit for a fixed set of known actions.

If the selected value must vary per item, build a different payload for each item when you construct the vector.

Specific advice

There is no built-in disabled item styling in the checked-in Menu implementation. If you set on_select to None, the row still appears but does not behave like a real selectable action. For production UIs, prefer explicit affordances rather than relying on a silent inert row.

Production checklist

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

•

Bind on_select to explicit reducer actions and test that the reducer handles unavailable, duplicate, or invalid input safely.

•

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 MenuItem 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.

Menu, MenuButton, SelectItem, and Button.