ModalAction

ModalAction is the small configuration struct that describes one button in a Modal footer.

It exists so modal buttons stay explicit and state-driven. Instead of letting the dialog close itself implicitly, each action carries an ActionEnvelope that re-enters your normal reducer loop. That means "Cancel," "Delete," and "Save" are all just named application intents. The reducer decides what each one really does, including whether the modal should close.

Example

use fission::prelude::*;

let dialog = Modal {
    id: WidgetId::explicit("delete_confirm"),
    title: "Delete draft?".into(),
    content: Text::new("This action cannot be undone.").into(),
    is_open: view.state().show_delete_dialog,
    on_dismiss: Some(close_dialog),
    actions: vec![
        ModalAction {
            label: "Cancel".into(),
            on_press: Some(close_dialog),
            is_primary: false,
        },
        ModalAction {
            label: "Delete".into(),
            on_press: Some(confirm_delete),
            is_primary: true,
        },
    ],
    width: None,
};

In that example, the modal does not close itself. Your reducers decide whether close_dialog or confirm_delete should change the state.

Field table

Field	Type	Meaning	Notes / default behavior
label	String	Visible button text.	Keep it short and action-oriented.
on_press	Option<ActionEnvelope>	Action dispatched when the footer button is pressed.	Defaults to None. A button without an action is visible but inert.
is_primary	bool	Whether this is the main action in the footer.	true uses the filled button style. false uses the outline style.

Specific advice

Keep the footer focused. Most modals should have one primary action and, at most, one secondary escape action. If you find yourself adding many buttons, the problem is usually bigger than a footer can explain and the interaction probably wants a full screen or routed page instead.

Also remember that is_primary is a visual emphasis choice, not business logic. The reducer should still treat every action explicitly.

Production checklist

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

•

Bind on_press 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 ModalAction 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.

Modal, Button, and ButtonVariant.