carbon-components-svelte
carbon-components-svelte copied to clipboard
Slider component does not round value when on key [Shift]+[Arrow]
Hi. I believe some rounding logic is missed here:
https://github.com/carbon-design-system/carbon-components-svelte/blob/ea7c0d446e989a9435788a9edacdc0542b683da0/src/Slider/Slider.svelte#L166
whereas another part has the rounding logic properly done:
https://github.com/carbon-design-system/carbon-components-svelte/blob/ea7c0d446e989a9435788a9edacdc0542b683da0/src/Slider/Slider.svelte#L87
For instance with the [Shift] key decimal values may appear even when we have step = 1
.
Can you provide a minimal repro?
Can you provide a minimal repro?
Please see https://svelte.dev/repl/ae98c84714d448a799c59a40dbccdc50?version=3.47.0
Basically it's just
<Slider
min={0}
max={10}
value={0}
step={1}
/>
A step multiplier is applied if the shift key. The default value is 4
, which is what is causing the decimal values.
In your REPL, I've added a custom step multiplier prop: https://svelte.dev/repl/6403b71d10024cedbd9729eef319482e?version=3.47.0
<Slider
min={0}
max={10}
value={0}
step={1}
stepMultiplier={10}
/>
<Slider
min={0}
max={100}
value={0}
step={10}
stepMultiplier={10}
/>
It's a bit confusing the default multiplier would produce values outside of the valid steps. But if the contract is that it's up to the client to provide a good multiplier to avoid invalid values, then please close the issue.
However another interesting thing I discovered is that different framework implementations of the Carbon Design System treat stepMultiplier
differently.
In the live demo here of Carbon itself, given
<Slider min={0} max={100} step={1} stepMultiplier={4} />
the shift key makes the change 4 times as large as the normal step of 1, which gives 4. This also seems to be how Vue's
implementation do it, where the shift key changes the value by 10 given the props
min: -50, max: 150, step: 1, stepMultiplier: 10
.
In contrast, the implementations for svelte and web components are that the shift key changes the value by (max - min) / stepMultiplier
. (Although the latter does perform rounding to valid steps on shift key.)
Just some difference that I spotted.
Let's keep this open for now. I'll investigate to see if we can improve the API.