Slider Logical vs. Display Value Ranges
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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