Accordion

Accordion is the widget for progressive disclosure in a vertical stack.

Use it when a screen has secondary details that should stay available without overwhelming the first read. Common examples are advanced filters, shipping details, frequently asked questions, or email metadata that should not occupy full height all the time.

Example

use fission::prelude::*;

let widget: Widget = Accordion {
    items: vec![
        AccordionItem {
            title: "Details".into(),
            content: details_node,
            is_expanded: view.state().details_open,
            on_toggle: Some(toggle_details_action),
        },
        AccordionItem {
            title: "History".into(),
            content: history_node,
            is_expanded: view.state().history_open,
            on_toggle: Some(toggle_history_action),
        },
    ],
}
.into();

The widget only reflects state. If your product wants exactly one section open at a time, that rule belongs in the reducer. If your product wants several sections open together, that also belongs in the reducer.

Field table

Field	Type	Meaning	Notes / default behavior
items	Vec<AccordionItem>	The sections to render from top to bottom.	Defaults to an empty list.

State ownership and behavior

Accordion does not own expansion state. Each item brings its own is_expanded flag and on_toggle action. That means the widget does not enforce a single-open pattern, does not remember the last opened section, and does not silently mutate anything on its own.

The checked-in renderer builds each header as a ghost button and places the expanded content in a second container underneath it. This produces a clear stacked presentation, but it also means each expanded item is two visible blocks rather than one animated height transition.

Specific advice

An accordion should reduce scanning cost, not hide essential content. If users must open every section just to finish the main task, the layout probably wants tabs, a stepper, or a simpler single-column flow instead.

Production checklist

For Accordion, review the fields that change behavior before treating the widget as finished: items. 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.

•

When child widgets are generated from data, give reordered or filtered rows an explicit WidgetId so retained local state and scroll behavior do not drift between items.

•

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

AccordionItem, Tabs, Stepper, and Card.