Open FelixBenning opened 1 year ago
Maybe this transform
approach is a bad idea. Another idea could be, to let the Slider look for the nextElementSibling
but do not define the Sibling itself. Or more generally look for a specific document.getElementById($(outputID))
and pass it the value.
<script>
const input_el = currentScript.previousElementSibling
const output_el = document.getElementById($(slider.show_value))
const displays = $(string.(slider.values))
input_el.addEventListener("input", () => {
output_el.value = displays[input_el.valueAsNumber - 1]
})
</script>
Usage would be
@htl("$(@bind x Slider(1:10, show_value="my-output")) $(PlutoUI.outputs.log("my-output"))")
Then this output element could define a setter for its value and choose its own display style. So you could have a set of input elements seperated from a set of output elements and mix and match
show_value
is used differentlyelement.value
would have to try thatI just realized that my use case is achieved by Slider(exp.(1:10), show_value)
So only the formatting use case remains
Good idea to make this customizable! What about an API like this?
Slider(1:10; show_value=true) # default
Slider(1:10; show_value=(x -> @sprintf("%.2f kN", 5))) # custom formatter
Allowing you to customize the position of the output is something we should look into in a separate issue perhaps?
I want to create a slider on a
log
scale. Of course I would also want the Slider to show the correct value then. Other use cases are Scientific Notation, etc.The current Implementation looks like this:
Transform Approach
So one could do the following: