Switch

Switch is the boolean control for immediate settings.
Use it when the user is turning a behavior on or off right now, such as enabling notifications or muting audio. That is the main difference from a Checkbox: a switch usually implies an immediate setting, while a checkbox often implies inclusion in a later submit or selection set.

Example

use fission::prelude::*;
let widget: Widget = Switch {
checked: view.state().notifications_enabled,
on_toggle: Some(ctx.bind(
    ToggleNotifications,
    reduce_with!((|state: &mut SettingsState, _action: ToggleNotifications, _| {
        state.notifications_enabled = !state.notifications_enabled;
    })),
)),
..Default::default()
}
.into();
As with other controlled widgets, the switch only reflects checked. The reducer owns the state transition.

Field table

Field
Type
Meaning
Notes / default behavior
id
Option<WidgetId>
Stable widget identity.
Defaults to None.
checked
bool
Whether the switch is currently on.
Defaults to false.
on_toggle
Option<ActionEnvelope>
Action dispatched when the switch is pressed.
Defaults to None.

Semantics and state flow

Switch lowers a semantic switch role with the current checked state. That makes it a better accessibility match than styling a generic button to look like a switch.
The action flow is straightforward: press the switch, dispatch on_toggle, update the boolean in the reducer, reconvert with the new checked value.

Specific advice

Pair a switch with clear nearby text so the user knows what is being turned on or off. If the choice is part of a multi-select form or agreement checklist rather than an immediate setting, a checkbox is usually clearer.

Production checklist

For Switch, review the fields that change behavior before treating the widget as finished: id, checked, on_toggle. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.
•
Bind on_toggle to explicit reducer actions and test that the reducer handles unavailable, duplicate, or invalid input safely.
•
Set id only when identity must be stable across filtering, reordering, diagnostics, or tests; otherwise let Fission derive identity from structure.
•
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 Switch 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.
Previous
Slider