EmptyState

EmptyState is the guided placeholder for screens or panels with no content yet.

In a real app, an empty region should answer three questions quickly: what is missing, why it is missing, and what the user can do next. This widget packages those ideas into one centered block.

Example

use fission::prelude::*;

let widget: Widget = EmptyState {
    icon: None,
    title: "No drafts yet".into(),
    description: Some("Create your first draft to start writing.".into()),
    action: Some(
        Button {
            child: Some(Text::new("New draft").into()),
            on_press: Some(create_draft_action),
            ..Default::default()
        }
        .into(),
    ),
}
.into();

This is much more helpful than leaving a large blank panel with no explanation.

Field table

Field	Type	Meaning	Notes / default behavior
icon	Option<Widget>	Optional decorative or explanatory visual.	Defaults to None.
title	String	Main message for the empty state.	Required.
description	Option<String>	Supporting explanation below the title.	Defaults to None.
action	Option<Widget>	Optional primary action, often a button.	Defaults to None. Can be any node.

user experience intent

An empty state should teach, not apologize. The best ones describe the missing content in product language and offer a next step when one exists.

The checked-in widget centers its content, which makes it work best for empty screens, side panels, and major content regions. If you need an inline "no results" hint inside a dense list, a smaller custom message often fits better.

Specific advice

Avoid vague titles like "Nothing here". A user usually wants to know what is missing and what they can do about it.

Production checklist

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

•

Bind action 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 EmptyState 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.

Alert, Card, Button, and Spinner.