~/ Dual Range Input
I recently had a need for an
<input type='range'> with start and end buttons, so I built one:
I made a few API and design decisions that I wanted to think through here for the next npm package I might build.
Functional UI From the Start
The hello world example (above) demonstrates how the package depends on two existing
I'm happy with requiring the user to provide them. This has the added benefit of being able to attach event listeners to and modify the values of the underling
inputs with no conflict issues.
Browser Native Module Support
Using ES Modules means not having to deal with a build system:
import DualRangeInput from 'https://unpkg.com/dual-range-input@latest/script.js';
The source code is the distributed code, which means I don't have to worry about compilation before distribution.
Sane Default Behavior
The first action I implemented was making each slider "push" the other when a particular minimum or maximum value was exceeded.
e.g. dragging the start past the end should also drag the end with it.
I also added in
:active states to match the browser-native styles, and made
it so that the active button appears above the inactive button.
Lastly, I had started with always showing the values but realized this created problems when the start and end were very close together - the numbers would overlap! I decided to only show the value of the range during dragging, which in my humble opinion is an enhancement to how the browser-native range input should behave.
Default Export is a Function
The default export from the package is a function, which allows users to call the library whatever they want:
import customRange from 'https://unpkg.com/dual-range-input@latest/script.js'
but also binds each invocation to a particular UI element - the set of browser-native
You can do
which is short for:
I did this because I suspect most consumers will use the input without configuration.
Inlined, Overridable CSS
I wanted to avoid asking consumers to add a
<link /> tag to import the custom styles required, and so I decided to just write the CSS inside the main script tag.
This has the added benefit (to me) of coupling the UI markup with the UI styles. That is, users don't have control over the UI markup (yet), and so each new release can safely modify the markup and styles without worrying about breaking previous implementations.
I'm super curious about adding in a third button, like a gradient generator might have and am wondering if I've made a mistake by adding "dual" to the package name from the start.
Interested in contributing? Check it out on GitHub.
~/ Posted by Jesse Shawl on 2022-09-20