Builder

Fission

Product

▾

Setup

›

›

Builder is a convenience widget for a small piece of user interface that is clearer as an inline closure than as a named component.

Most Fission UI should still be written as a struct with impl From<MyComponent> for Widget. That keeps screens, reusable components, and product concepts easy to name and test. Builder is for short local fragments, especially in tests, demos, or narrow conditional sections where a named type would add ceremony without adding clarity.

The closure receives scoped build handles and returns a Widget. It is still part of the normal build model: read state through view, bind actions through ctx, and return a widget tree. Do not fetch data, mutate state, or perform outside work from the closure.

Example

use fission::prelude::*;

let greeting = Builder::<MyState>::new(|_ctx, view| {
    let label = if view.state().is_signed_in {
        "Welcome back"
    } else {
        "Please sign in"
    };

    Text::new(label).into()
});

Field table

Field	Type	Meaning	Notes / default behavior
Builder::new(...)	Fn(BuildCtxHandle<S>, ViewHandle<S>) -> Widget	Creates the inline widget from a pure build closure.	The closure must be Send + Sync + 'static.

When to use it

Use Builder when the closure is small and local. If the closure starts to contain product logic, several branches, or repeated layout, move that code into a named component. The named component path is the primary API and is what examples should use for production structure.

Production checklist

For Builder, review the fields that change behavior before treating the widget as finished: Builder::new(...). 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 Builder 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.

LayoutBuilder, Widget, and State system.