TreeView

TreeView is the hierarchy widget for folder-like or outline-like structures.

Use it when the product needs parent-child relationships to stay visible, such as file trees, navigation trees, nested categories, or expandable sidebars. A tree is about structure first and selection second.

Example

use fission::prelude::*;
use std::collections::HashSet;

let widget: Widget = TreeView {
    items: view.state().sidebar_tree.clone(),
    expanded_ids: view.state().expanded_tree_ids.clone(),
    selected_id: view.state().selected_tree_id.clone(),
}
.into();

Field table

Field	Type	Meaning	Notes / default behavior
items	Vec<TreeItem>	Root items in the hierarchy.	Required.
expanded_ids	HashSet<String>	Item ids whose children should currently be shown.	Controlled by app state.
selected_id	Option<String>	Currently selected item id.	Controlled by app state.

State ownership and current behavior

TreeView is another explicitly controlled widget. It does not own expansion state, selection state, or navigation rules. It simply reads expanded_ids and selected_id and renders the tree accordingly.

The checked-in renderer is strongest today as a hierarchical selection view: it indents children, highlights the selected row, and can show nested structure clearly. One important limitation is that while TreeItem has an on_toggle field, the current renderer does not provide a built-in expansion toggle control that dispatches it. If you need full interactive expand-collapse behavior today, validate the exact user experience carefully and be prepared to compose around that limitation.

Specific advice

Trees can become deep quickly. If the hierarchy is only one or two levels deep, a simpler list or grouped navigation often reads better. Use a tree when the structure itself is important for orientation.

Production checklist

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

TreeItem, Breadcrumb, Accordion, and Scroll.