range-num, a useful little web vanilla web component
I'm working on a few small demos and a thing I often find myself needing is a combination
input[type="range"] with some sort of label, or even an
input[type="number"] showing the same value. I decided to package
those together in a tiny vanilla web component called range-num, and I've made
it publicly available via
npm and
github.
Demo
Setup
// somewhere in your code
import RangeNum from "@potch/range-num";
RangeNum.register();
// wanna use a different tag name?
RangeNum.register("other-tag-name");
or, for the beautifully lazy among us:
<script type="module">
import RangeNum from "//unpkg.com/@potch/range-num";
RangeNum.register();
</script>
Basic Use
<range-num min="0" max="5" value="3" step=".5"></range-num>
Programmatic use
const el = document.createElement("range-num");
el.min = 1;
el.max = 10;
container.append(el);
Form control examples
Details
For simplicity's sake, the component itself is a vanilla JS module. I fully agree with Nolan Lawson that the best use case for Custom Elements is client-rendered leaf components. These have the best shot of integrating well with the framework you're likely using to build something larger, and reduce suffering from a lack of server-rendering to a minimum. As for the vanilla bit, I think the richest components might benefit from some library to help structure them (or perhaps just signals!)- but generally if you're pulling in a full framework to build a web component it's a sign it's Doing Too Much™ and you should see what you can accomplish without it. Not to mention the added complexity of mixing library dependencies.
The component uses Shadow Dom, but only in light mode. I don't think I knew much about the
slotchange event until recently but as a "cheaper mutation observer"
it's truly incredible and I can't wait to take more advantage of it.
I've included some extremely minimal styles in the package, but they're not required for the component to work properly and in most situations you should do your own thing.
I also made the decision to not auto-register the component in the script itself, and that's something I might revisit. I like the idea of letting people choose their own tag name if that's what they desire, at the slight reduction in the true DHTML joy of just including a script and running with it. But if in my own use I'm like "dang why didn't I just register this thing" I may change it.
As with all my open source, it's released with a strong attitude of "no maintenance intended". If I spot bugs or get a nice compact PR, I'll probably ship an update, but realistically I'm not going to take a lot of feature requests. Forks don't offend me in the slightest- just pass on a little credit!
I hope you find it useful! I have demos already depending on it, hopefully I'll publish those soon.