Alert

Alert is the inline message surface for important feedback that should stay visible in the page layout.

Use it when the message belongs to the current screen and should remain present until the user moves past the condition or changes state. That is the main difference from a Toast: a toast is brief overlay feedback, while an alert is part of the page content.

Example

use fission::prelude::*;

let widget: Widget = Alert {
    kind: AlertKind::Error,
    title: "Could not save draft".into(),
    description: Some("Check your connection and try again.".into()),
}
.into();

This is a good fit because the failure matters to the current workflow and should remain visible until the user responds.

Field table

Field	Type	Meaning	Notes / default behavior
kind	AlertKind	Severity and visual tone of the message.	Required. Controls icon and background color.
title	String	Main alert message.	Required. Keep it specific and action-oriented.
description	Option<String>	Supporting explanation under the title.	Defaults to None. Use it when the title alone is not enough.

User experience intent

A good alert explains both what happened and what the user should do next. The title should carry the main meaning. The description should add context, not repeat the title in different words.

The checked-in widget is purely presentational. It does not include dismissal controls, retry buttons, or live region settings. If the alert needs actions, compose those around it in the surrounding layout.

Specific advice

Avoid using inline alerts for routine empty states or tiny confirmations. Overuse makes real problems blend into the background. Reach for an alert when the message changes the user's next decision.

Production checklist

For Alert, review the fields that change behavior before treating the widget as finished: kind, title, description. 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 Alert 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.

AlertKind, Toast, Badge, and EmptyState.