nuxt / nuxt/ui

Slider Logical vs. Display Value Ranges

Open
#5,185 6 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

triage
Dominant language
TypeScript
Stars
6.9k
Forks
1.1k
Avg merge
1d 7h
Merged PRs (30d)
57

Description

Package

v4.x

Description

Problem

As a developer, I often need a slider for users to select a value within a 0-100 range. However, there is frequently a logical constraint that makes a subset of this range invalid.

A classic example is selecting a "Battery Save Mode" threshold. The user should understand that the mode activates at a certain battery percentage, which conceptually exists on a scale from 0% to 100%. However, for technical or usability reasons, setting the threshold below 15% might be illogical or unsupported. A slider that only goes from 15 to 100 loses the visual context of the full 0-100 scale, making the selected value (e.g., 20%) feel arbitrary to the user.

Proposal

I propose extending the slider component to decouple its visual display range from its selectable value range. This would allow the slider to display a full conceptual range (e.g., 0-100) while only allowing selection within a valid sub-range (e.g., 20-100).

I see two intuitive ways to implement this:

Approach A: Explicit Display Properties
<u-slider :display-min="0" :min="20" :max="100" />

If provided, displayMin and/or displayMax control the visible track, possibly extending min and max.

Approach B: Constrained Value Properties
<u-slider :min="0" :max="100" :min-value="20" />

If provided, minValue and/or maxValue constrain the selectable thumb within that range.

I can come up with a PR if I get general approval on the idea and on either of approaches. I personally slightly prefer Approach B.

Additional context

For now, I use this:

watchEffect(() => {
  fields.percentage = Math.max(20, fields.percentage)
})

Nevertheless, I believe this option deserves first-class support in the slider widget.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No implementation file or test is named. Start by reviewing the slider component's existing min/max behavior and the two proposed API designs, then confirm the intended approach with maintainers. Done means an agreed display-versus-selectable range API is implemented and covered by relevant slider tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.