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.
Related
Slider, NumberInput, DateRangePicker, and TextInput.
Previous
Radio
Next
SegmentedControl