Range Slider

The <x-wirekit::range-slider> component provides a dual-handle slider for selecting a numeric range. Both handles are draggable via pointer and keyboard, and the filled track between them visualizes the selected range. A click or tap on the track brings the nearer handle to that point.

Basic Usage

<x-wirekit::range-slider style="width: 32rem; max-width: 100%"
    label="Price range"
    name="price"
    :min="0"
    :max="1000"
    :min-value="200"
    :max-value="800"
/>

With Step

<x-wirekit::range-slider style="width: 32rem; max-width: 100%"
    label="Weight (kg)"
    name="weight"
    :min="0"
    :max="100"
    :step="5"
    :min-value="20"
    :max-value="60"
    hint="Adjust in 5 kg increments"
/>

With Hint

<x-wirekit::range-slider style="width: 32rem; max-width: 100%"
    label="Age range"
    name="age"
    :min="18"
    :max="65"
    :min-value="25"
    :max-value="45"
    hint="Filter candidates by age"
/>

Without Value Bubbles

Set :show-values="false" to hide the floating numeric badges above each handle. The min/max bounds under the track and the aria-live region for screen readers stay in place — only the tooltip-style bubbles are removed.

<x-wirekit::range-slider style="width: 32rem; max-width: 100%"
    label="Price range"
    name="price"
    :min="0"
    :max="1000"
    :min-value="200"
    :max-value="800"
    :show-values="false"
/>

To hide the bubbles globally for every <x-wirekit::range-slider> in your app, set the default in config/wirekit.php:

'components' => [
    'range-slider' => ['show_values' => false],
],

Livewire Integration

Pass a single wire:model[.modifiers]="propName" directive on the component tag — the slider re-emits it on each hidden input as propName.min / propName.max so a Livewire array property gets live two-way binding. The slider keeps both thumbs in internal state seeded from min-value and max-value, so pass the bound range there as well:

public array $budget = ['min' => 1000, 'max' => 5000];

<x-wirekit::range-slider
    label="Budget"
    name="budget"
    :min="0"
    :max="10000"
    :step="100"
    :min-value="$budget['min']"
    :max-value="$budget['max']"
    wire:model.live="budget"
/>

Dragging either handle updates $budget['min'] / $budget['max'] on the server, and a range the server sets moves the thumbs. Without min-value and max-value the thumbs start at min and max rather than at the stored range, do not follow the server, and the first move sends a range counted from there, which replaces the stored one. A stored range outside the scale is held inside it: the thumbs stand at its ends, and the next move sends the range they show.

All wire:model modifiers (.live, .lazy, .debounce.500ms, .blur) flow through unchanged — the component re-emits them on both hidden inputs identically. Bound to an object whose min and max are declared int or float, such as a form object, each end is read as a number: wire:model.live goes out as wire:model.number.live, so the server's typed answer is not taken for a change that overwrites a newer position. An array property keeps the text it receives, as above.

For form submission without Livewire, the component still renders two hidden inputs ({name}[min] and {name}[max]) so a $_POST['budget'] (or Request::input('budget')) lands as a nested array.

An x-model on the tag is dropped, because the range reaches Alpine through neither handle: see An x-model on a WireKit component.

Width

The range slider fills its parent width. Constrain it via the parent element:

<div class="max-w-md">
    <x-wirekit::range-slider label="Price" name="price" :min="0" :max="500" />
</div>

Mobile & Touch

On touch devices the thumb grows to a comfortable 28px (via @media (pointer: coarse)) and touch-action: none keeps a horizontal drag from scrolling the page. A tap on the track brings the nearer handle to that point, and the track takes the tap across a 24px band although it is drawn 8px tall. Discrete sliders (step > 1) with a readable step count render snap tick-marks.

<x-wirekit::range-slider style="width: 32rem; max-width: 100%" label="Rating" :min="0" :max="10" :step="1" :min-value="3" :max-value="7" />

Form Submission

Two hidden inputs are rendered:

• <input type="hidden" name="{name}[min]"> — lower handle value
• <input type="hidden" name="{name}[max]"> — upper handle value

Reading the values server-side

The two thumbs submit as one array rather than two flat keys:

// 1. The request body a range-slider named "price" produces:
//    price%5Bmin%5D=10&price%5Bmax%5D=250

// 2. Read either half with dot notation — NOT `price_min`.
$request->input('price.min');   // "10"
$request->input('price.max');   // "250"

// 3. Or take the pair at once.
$request->input('price');       // ['min' => '10', 'max' => '250']

Validate it the same way:

// 1. Each half is its own rule path.
$request->validate([
    'price.min' => ['required', 'integer', 'min:0'],
    'price.max' => ['required', 'integer', 'gte:price.min'],
]);

Named values

A range handle reads as its number. For a price that is exactly right; for a tier it is meaningless — "0 to 100" says nothing about Free or Enterprise. value-text-map gives each stop the word it deserves, and the word is what everyone gets: the handle badges show it, the bounds beneath the track show it, and a screen reader announces it.

<x-wirekit::range-slider
    style="width: 32rem; max-width: 100%"
    label="Plan range"
    :min="0"
    :max="100"
    :step="25"
    :min-value="25"
    :max-value="75"
    :value-text-map="[0 => 'Free', 25 => 'Starter', 50 => 'Pro', 75 => 'Business', 100 => 'Enterprise']"
/>

Stops the map does not name fall back to the number, so a partial map is safe — inventing a word for the gaps would be worse than showing the digit.

Optimistic UI

Pass the name of the Livewire method the slider should call and the range is sent the moment the gesture ends, then confirms or undoes itself when the server answers:

The method receives the pair, not the handle that moved:

<x-wirekit::range-slider
    name="budget"
    label="Budget"
    :min="0"
    :max="1000"
    :min-value="$from"
    :max-value="$to"
    optimistic="saveBudget"
/>

public function saveBudget(array $range): void
{
    [$this->from, $this->to] = $range;
}

Load wirekit-optimistic.js alongside whichever bundle you already use — below it, in your layout:

@wirekitScripts
<script src="{{ asset('vendor/wirekit/wirekit-optimistic.js') }}" defer></script>

Try it

The demo below runs the real path: the change shows immediately, the outline says it is provisional, and the server's answer either confirms it silently or takes it back.

{{-- In your app there is no host: your own Livewire component owns the method. --}}
<x-wirekit::range-slider
    name="budget"
    label="Budget"
    :min="0"
    :max="1000"
    :min-value="$from"
    :max-value="$to"
    optimistic="saveBudget"
/>

The <livewire:demos.…> wrapper above exists only on this site — it supplies the demo methods so the page can show a real round trip. The block under it is what you write.

When the value is sent is the part worth knowing. A drag produces a value on every frame, and sending each one would be a request storm; sending only the last would let the thumb run ahead of anything the server was ever told, so an undo would take back a value that was never on its way. So the send happens when the gesture is over — on release for a drag, and on each keypress for the keyboard, where one press is already a finished decision. Nothing is timed; the boundary is the event that ends the input.

The range is one value. If only one handle moved, an undo still restores both — the untouched one to what it already holds, which changes nothing. There is no per-handle bookkeeping to get out of step.

<x-wirekit::range-slider style="width: 32rem; max-width: 100%"
    label="Price range"
    name="price"
    :min="0"
    :max="1000"
    :min-value="200"
    :max-value="800"
    error="The upper bound has to stay under your plan's limit."
/>

Props

Slots

Accessibility

• Each handle: role="slider" with aria-valuenow, aria-valuemin, aria-valuemax, and an aria-label that carries the group's own name — "Price range minimum" / "Price range maximum" when you pass label="Price range", and "Minimum" / "Maximum" when you pass no name at all
• The group is wrapped with role="group", named by aria-labelledby pointing at the visible label (so the name on screen and the name announced are the same string)
• Value changes are announced via aria-valuenow updates (native slider behavior)
• Each handle's announced range is the range it can actually hold, not the whole track. The two handles never meet, so the lower one reports aria-valuemax one step below the upper handle's current value and the upper one reports aria-valuemin one step above the lower — both live, so they track as the handles move. On a 0–100 slider with step="10" the lower handle announces a maximum of 90, and pressing End lands it exactly there
• A click or tap on the track brings the nearer handle to that point and focuses it, so a value can be set with a single pointer and no drag (WCAG 2.2 SC 2.5.7). The click that ends a drag does not count: releasing a handle over the track never moves the other one
• Both handles have visible focus rings via focus-visible styling
• An autofocus written on the tag goes to the lower handle, unless the slider is disabled
• The filled track between handles is aria-hidden="true" — purely decorative
• Disabled state sets native disabled on the hidden inputs (so the range is left out of a submitted form), aria-disabled="true" on the group and on both handles, and tabindex="-1" on the handles — they leave the tab order, the pointer and keyboard handlers are not rendered at all, and the whole group dims via --opacity-wk-disabled
• A disabled <fieldset> around the slider locks it the same way while the page runs: both handles take aria-disabled="true" and tabindex="-1", ignore keys, presses and clicks on the track, and the slider dims. They come back when the fieldset is enabled again — see A Disabled Group

Keyboard Interaction

Each handle is independently focusable via Tab:

Handles cannot cross each other, and they cannot meet: the lower handle stops one step below the upper handle's value, and the upper handle stops one step above the lower one. Home and End land on the ends of the handle's own travel, which is the same bound the arrow keys clamp to.

Dragging a handle with a pointer also focuses it, and so does a click on the track, so either can be followed immediately by an arrow key to fine-tune the value.

Pitfalls

• Don't use range-slider for two unrelated values. It's specifically for a min/max range over a shared scale. For two independent values pair two <x-wirekit::slider> instances.

Design Tokens

Customization

Override defaults in config/wirekit.php:

'components' => [
    'range-slider' => ['min' => 0, 'max' => 100, 'step' => 1],
],

Further Reading

• WAI-ARIA: Slider (Multi-Thumb) Pattern
• MDN: role="slider"
• MDN: aria-valuenow
• MDN: aria-valuemin
• MDN: aria-valuemax