Toast

Fission

Product

▾

Setup

›

Navigation and overlays

›

Toast

Toast is the transient notification surface.

Use it when the app needs to acknowledge something quickly without interrupting the main task flow. Good examples are "Message sent", "Copied", or "Upload failed" when the full context already exists elsewhere on screen.

Example

use fission::prelude::*;

let widget: Widget = Toast {
    id: WidgetId::explicit("reply_sent_toast"),
    kind: ToastKind::Success,
    message: "Reply sent".into(),
    on_close: Some(dismiss_reply_sent_toast_action),
}
.into();

Field table

Field	Type	Meaning	Notes / default behavior
id	WidgetId	Stable toast identity.	Present in the public struct, but the checked-in widget does not currently use it internally. It is still useful in surrounding app state and overlay lists.
kind	ToastKind	Severity and visual tone of the message.	Required. Controls icon and accent treatment.
message	String	Main toast text.	Required. Keep it short.
on_close	Option<ActionEnvelope>	Action fired when the close button is pressed.	Defaults to None.

Lifecycle guidance

The checked-in toast is a visual surface only. It does not auto-dismiss itself. Your app decides when it appears and when it leaves state. If you want timed dismissal, trigger that with an explicit timer or service-driven flow rather than expecting the widget to manage its own lifetime.

Also remember that a toast is not a good place for dense recovery instructions. If the user needs to read, compare, or act carefully, an inline alert or dialog is usually the better fit.

Production checklist

For Toast, review the fields that change behavior before treating the widget as finished: id, kind, message, on_close. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

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

•

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

ToastKind, Alert, Modal, and Resources and async.