RangeSlider

RangeSlider is the dual-thumb range control in the authoring widget set.

Conceptually it represents a range between start and end inside a [min, max] domain. This is useful for things like filter ranges, budget bands, or size windows. The important current reality, though, is that the checked-in implementation is visual first: it draws the track and two thumbs, but it does not yet wire interactive dragging back to reducers.

Example

use fission::prelude::*;

let range_slider: Widget = RangeSlider {
    start: 10.0,
    end: 40.0,
    min: 0.0,
    max: 100.0,
    on_change: None,
    id: None,
}
.into();

This is a good way to show a selected range today, especially inside filter summaries or mockups of a richer future control.

Field table

Field	Type	Meaning	Notes / default behavior
id	Option<WidgetId>	Stable identity for inspection, testing, and future interaction plumbing.	Defaults to None.
start	f32	Lower bound of the displayed range.	Required. Expected to be within [min, max].
end	f32	Upper bound of the displayed range.	Required. Expected to be within [min, max].
min	f32	Minimum domain value.	Required.
max	f32	Maximum domain value.	Required.
on_change	Option<ActionEnvelope>	Intended change action.	Present in the public struct, but not currently wired by the checked-in implementation.

Current behavior

RangeSlider currently behaves as a custom visual widget. It does not expose slider semantics, drag handling, or reducer callbacks the way Slider does. In other words, it looks like a range slider, but it is not yet a finished interactive range editor.

Specific advice

Treat RangeSlider as a visual indicator unless you are extending the implementation yourself. If you need a production-ready editable control today, compose other widgets around two numeric inputs or two single sliders rather than assuming on_change is already live.

Production checklist

For RangeSlider, review the fields that change behavior before treating the widget as finished: id, start, end, min, max, on_change. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

Bind on_change 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 RangeSlider 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.

Slider, NumberInput, DateRangePicker, and TextInput.