Livewire Range Slider Laravel Package

Getting Started

1. Install and register.

   composer require dashed/livewire-range-slider
   

   Then publish any bundled assets/config if the README calls for it:

   php artisan vendor:publish --tag=livewire-range-slider-assets
   php artisan vendor:publish --tag=livewire-range-slider-config
   

   (Confirm the exact tag names in the repo's README — small packages often ship a single vendor:publish prompt instead.)

2. Where to look first. Open src/ for the Livewire component class (likely RangeSlider.php) and resources/views/ for the Blade view. That tells you the public properties (min, max, step, and the bound value(s)), the emitted events, and whether it wraps a JS library like noUiSlider or ion-rangeslider. Read the view before writing any markup — the prop names and wire:model target are defined there, not in prose docs.

3. First use case: a price filter. The fastest win is a listing page where users narrow results by a numeric range. Set the slider's bounds from the actual data, bind the selected value(s) to a Livewire property, and re-query in updated():

   <livewire:range-slider
       wire:model.live.debounce.400ms="priceRange"
       :min="0"
       :max="2000"
       :step="50"
   />
   

   public array $priceRange = [0, 2000];
   
   public function updatedPriceRange(): void
   {
       $this->results = Product::whereBetween('price', $this->priceRange)->get();
   }
   

   Because this package has zero stars and zero dependents, treat the README as the source of truth and prototype the above in a throwaway route before committing to it.

Implementation Patterns

• Dual-handle range. Bind an array property ([min, max]) rather than two scalars so the whole selection updates atomically and you avoid double re-renders. If the component uses two props instead, keep them in sync in a single updated* handler.
• Debounced live binding. Use wire:model.live.debounce.300ms (or .blur for cheaper UX) on the slider. Dragging a handle fires continuously; without debounce you'll flood the server with requests and see visible lag.
• Query-string persistence. Combine with Livewire's #[Url] attribute so filters survive refresh and are shareable:

  #[Url(as: 'price')]
  public array $priceRange = [0, 2000];
  

• Compose with other filters. Keep range state in the parent component and pass it down; treat the slider as a dumb input. This lets you build a "reset filters" button that just reassigns defaults on the parent.
• Wrap for reuse. If you use the slider in several places, create a thin Blade component in resources/views/components/ that forwards props and applies your design-system styling, so upstream changes to the package's markup don't ripple through every view.
• Eager-load and cache. Recomputing whereBetween on every debounce is fine for small tables; for large ones, cache the min/max bounds (Product::min('price')) rather than querying them per render.

Gotchas and Tips

• Asset registration. Most slider packages need their JS/CSS pushed to the page. If the handles don't appear or drag, check whether the service provider auto-registers assets or whether you must add a @push in your layout. This is the single most common failure with small Livewire UI packages.
• DOM morphing kills slider state. When Livewire re-renders, the underlying JS instance can detach from the DOM. Add a stable wire:key to the component (and to any list item containing one) and confirm the package re-initialises on livewire:navigated / morph.updated; if not, you'll need to hook Alpine's x-init or a MutationObserver.
• Null and initial values. Arrays bound to a dual-handle slider often need an initial value matching [min, max]. Passing null or a single scalar can silently render a broken handle — set defaults in mount().
• Version drift. Last release was March 2024; verify it against your Livewire 3 version. If it was written for Livewire 2's wire:model semantics, wire:model.live and $wire calls may not behave as expected. Pin the version and note it in your project.
• Debugging checklist. Confirm the bound property is public; check the network payload for the slider value; use Livewire DevTools to inspect the re-render; then check the browser console for the JS library's own errors (usually "container not found").
• Extension point. If the package wraps noUiSlider/ion-rangeslider, the cleanest customisation is passing through the underlying options (tooltips, step snapping, formatting) via a config or :options prop rather than forking. If no passthrough exists, overriding the published Blade view is the lighter-touch fork.
• Vet before relying on it. With no dependents, plan an exit: keep the slider behind your own wrapper component so swapping it for a hand-rolled Alpine + noUiSlider implementation is a contained change.