Min or max property prevents expected update from input when using two handle slider

[aandrews-dsit]

Describe the bug

When using a double range slider variation, alongside an input box as an alternative for entering values, setting the 'min' or 'max' property on the range slider causes unexpected behaviour with the slider handle and the input box - i.e., attempting to update the slider handle position not by dragging but by entering a new number in the input box fails.

Link To Reproduce

https://svelte.dev/playground/c27ebb1263d34311b15516c7aa055fb9?version=5.34.7

Versions

• svelte: v5.34.7
• svelte-range-slider-pips: v4.0.0

Steps to reproduce the behavior:

No explicit error

Expected behavior

Like in this example I expected both handles to respond to input smoothly by adjusting to new positions on the slider track.

Screenshots

N/A

Device/Environtment

N/A, reproducible on svelte playground.

Additional context

Add any other context about the problem here.

[simeydotme]

Hi!

Thanks for the report.

I see the issue, I think it's because when you type in the box, if the value is > max || < min then it seems to throw an error which stops the handle positions from updating...

Like in your example, if you delete the value and then type 11... after you type the first 1 it's trying to bind the value to 1 which is less than 10 (min) and therefore it wont work.

However, that should not be causing the handles to break.
As you can see the values are still bound correctly!

---

https://svelte.dev/playground/c27ebb1263d34311b15516c7aa055fb9?version=5.34.7#H4sIAAAAAAAACoVQTWsCMRD9K8NQsAWtK3had4X-g9IejYesjhKYzYZkYpVl-9ubuNJ6EHoJ5M28j3k9Wt0Slvih7ZHgk82ePLwbF-AbWmPnrT6D850jLxdo4hGMhX0XGyYI47LjGBLqouAUD4YpYLnpUS4u62Yg4TeXN-dew4lYMtboQI_wXWeFrCQZrMLOGydrZZWY1nVe4Br0lvPguxYUjsyZz5PZmGrm0gkKV8oCMAmcNEcKUMNTEC30vFkU02WxfVll5byQ7_ydLosiT6r5n72t7o0bY_flTTM75arqvhiyTN2nZwDNXE9YN8QTmCeF6lrRHbPuR4FNsR0gt1UrtLFtyCv8h7F4yEjVCZ0FS_GRhm36acNfiY3lQXOg4Qcs4OXn7QEAAA==

^ here's an example with min/max set very low/high which doesn't have this problem

---

I will look at this as soon as I can

[simeydotme]

hmmm....

this is only happening in Runes mode.

https://svelte.dev/playground/c27ebb1263d34311b15516c7aa055fb9?version=5.34.7#H4sIAAAAAAAACoVQzYqDMBB-lWHOdVXoyerCvsGye1QPsY4lEGNIJt0Wsc_eRIXtYWEvgXzz_c3MqMVIWOCX0BeCbyV7svApjYMHjFKno7iBsZMhy3fo_AWkhn7ynSJwG9ko7wJqPOMBB6nIYVHPyHcTfSMQ8D3lw5g3dyXFEeuEo7_w86SZNAcbLN3ZSsPvjW5YjmayDGvRvedgpxEa3JSJjZNka5WYsEKDp0YDKGK4CuXJQQV1nh2OWXuKjnEQ96vgmAWgTH_TdPma00ndF7tFNI6XqeY8W6K8msOzQBpk5XqGF3o1b6o6a_9j5CsjrM90YyzYelra8BNS_QQ2FoNQjpYndlX3AbEBAAA=

^^ fine without $state() ...

I think that this might be a Svelte internal problem :/

[simeydotme]

I'm getting into a deep rabbit hole on this one... The deeper I go the more it looks like the $: ... Syntax has some major problems in Svelte 5.

I might have to back out my changes in currently doing and state this library is only semi-compatible with svelte5... Until I can rewrite it. (https://github.com/simeydotme/svelte-range-slider-pips?tab=readme-ov-file#in-a-svelte-5-project)

I'm just really afraid rewriting it in a Svelte5 will break it's multi-framework compatibility

[simeydotme]

ok, confirmed.

Under Runes mode this code is failing to be recognised as reactive after the user has tried to update the value below/above the min/max.

I've tried many ways to refactor the code to make this work, but I think it's just a issue with Svelte5 translating $state() into $: in certain scenarios.

[simeydotme]

Here's a way around it by unbinding the values, and manually applying them when editing the input boxes;

https://svelte.dev/playground/c27ebb1263d34311b15516c7aa055fb9?version=5.34.7#H4sIAAAAAAAACpVSQW7bMBD8yoIoEAmQLQnISbYCpLceWhTt0fKBitcOAYoiSEp1IKhv75KUHSPJIb2JM8Od2REnpniHrGK_uDoh_JbigAZ-Cm3hL3RC5R0_gza9RuNeoB1OIBQc-qGVCDaKtRwsoXpwLGNHIdGyajcx96L9XA8Qvrg8ar22I0rnsZZb_Ah_6pVD5WgM29onI7R7aFTjRKd74yAEXXIeTd9Bw-LNlfHMKqZaaVqhYZtGAUh0MHI5oIUavljHHSa7ssjui3268ZO9gHZ9ZcvihqACrsR9JIiikNbBM1cHid_88iRKMAORQv0Ak5fE-1OwfrQ_hq5FU8E4kxLXjpsTuk3UjQR95-55TSkSMsyWEz8nY-ajpelFGfbYiT3dGBcsz6_z1oG_cvP7rF_lYD6K-n7CxekyaZu__gy1vf0NrVCHamnY9x4B32j8oAa5lPWd5C3KO8jjhPBkwD-TumEqtNOwaFtPi3uxn8Hb9yqo6ynBEPqmd9qkSC-qlrZ7I_ILL5r_MC4_ZVx-wrgMxvSsHZ4dq5wZcN7TiQv5h9ph1ZFLi_M_LT2TsokDAAA=

For now, I think this is the safest way to handle binding <input /> elements in Runes Mode

[simeydotme]

also you should add a min and max to your inputs

[aandrews-dsit]

Hi @simeydotme ,

Thanks for going down the rabbit hole on this one and taking a look!

Makes sense that it's a svelte5 translation for reactivity issue.

Unfortunately your last example above doesn't solve the issue for me; if you adjust the max value with the slider, then attempt to re-adjust with the input box, the value resolves to the max and stops being reactive.

There isn't urgency on this resolution from my account - I will also continue to experiment and post if I find anything.

[simeydotme]

Unfortunately your last example above doesn't solve the issue for me;

Oh, ok I think that's just because I was performing only a min/max math check and not checking for "undefined"... Just set the value to min if it's falsey "", undefined, null

Because ofcourse a "number" field would be "not a number" if it's empty 🙄

... Updated the demo you linked here 🙏

[simeydotme]

ok @aandrews-dsit I'm super happy to say I've resolved this specific issue!

you can check out 4.0.4 here, with the slider still working after entering invalid numbers

Something to note; you MUST use a type=number on the inputs if you expect to change them .. because the value attribute of a type=text is 'string', and the slider requires numbers, not strings. The other option is like in one of the previous examples; don't bind and instead use an oninput= to convert the value to a number then assign the value to the parseFloat(textFieldValue).

Generally speaking, as I mentioned before, you should try to make your inputs mimic the range as much as possible (min, step, max) so that the user is not accidentally inputting invalid values.

Thank you so much!

[aandrews-dsit]

Hi @simeydotme - thanks very much for this - I'm happy to leave this here, appreciate you've done a lot to debug - unfortunately the behaviour still doesn't quite match what I'd expect. To be clear, to reproduce the buggy behaviour, you just need to type the number in one of the input boxes, and this jumps to the max/min. Using the arrows of the input box does work, but not type input.

Thanks again for looking at this.

[simeydotme]

Hi @simeydotme - thanks very much for this - I'm happy to leave this here, appreciate you've done a lot to debug - unfortunately the behaviour still doesn't quite match what I'd expect. To be clear, to reproduce the buggy behaviour, you just need to type the number in one of the input boxes, and this jumps to the max/min. Using the arrows of the input box does work, but not type input.

Thanks again for looking at this.

Awesome!

Glad we fixed the issue and I'll close it now 🙏

To be clear; the behaviour you are expecting is not ”buggy", and it is not the responsibility of the slider UI... You are (incorrectly) expecting that putting "" or 2 (for example) as an input into a box does some validation.

But that is the input box's responsibility (IE: you need to manage that yourself using validation in input/change)... I can't be modifying the behaviour of an input box.

What I have done is made sure that a value bound to the slider is constrained within the min/max/limits ... And if your input box is allowing the user to type a value that is not within those limits (or is not a float type), then the slider is going to try and constrain/fix it because it is bound.

I think you're not understanding that; your min is 10... There is no number on your keyboard that is above 10... If you try to type 20, well you have to type the character 2 first, and that is less than 10. So the constraint kicks in and sets the value to 10. At that point the box, which is bound, updates to 10 and if you try to enter the second digit of 20 (which is 0)... Well you're actually changing 10->100, so the handle will fly up to the max constraint (40)

This is a not-uncommon issue with reactive bonding of form fields, and I've had to solve it many times. Especially prevalent with numbers and prices that have constraints.

---

I hope that clears up your personal situation and understanding of the binding issue. 🙏

I really suggest you switch to using the onchange() method to achieve the behaviour you're expecting 👍