Fabian Iwand

Widgets and helpers

Is there a way to use this one with Dates?

Andres Snitcofsky

something like this? https://observablehq.com/@easz/range-slider#timeRangeSelected

Not to second guess you, but is it worth the trouble?

If the majority of importers are importing rangeSlider, which depends on @jashkenas/inputs anyway, it seems like a shame to use a dynamic import here and load a duplicate version of the runtime. Not to mention the hassle the require conflicts.

And if you used a static import, importers of this notebook could use Observable version locking and have control over what version of @jashkenas/inputs is loaded. And if they’re using @jashkenas/inputs too (which isn’t unlikely), they could avoid loading a duplicate version of it, too.

And in the near future, it’s more than likely that standard static imports will be lazily evaluated in Observable also, as you suggested here:

https://github.com/observablehq/feedback/issues/74

Mike Bostock

> If the majority of importers are importing rangeSlider, which depends on @jashkenas/inputs anyway, it seems like a shame to use a dynamic import here and load a duplicate version of the runtime

Agreed. I've inlined `input` and removed the dependency on @jashkenas/inputs entirely. The docs also received a major overhaul so that the other inputs widgets are no longer needed.

> importers of this notebook could use Observable version locking and have control over what version of @jashkenas/inputs is loaded. And if they’re using @jashkenas/inputs too (which isn’t unlikely), they could avoid loading a duplicate version of it, too

That seems unlikely, because I had it pinned anyway. Unless the locking options allow one to override transitive pinned versions.

Some background:
The idea behind lazyImport() has always been to enhance a notebook's documentation without adding bloat to imports. An extreme example is `@tomlarkworthy/view`, where prior to adding lazyImport() the notebook would always import 4+ additional notebooks for its tests, docs and footer.
In this case I tried to hit two birds with one stone, because I intended to deprecate rangeSlider() in favor of interval() anyway.

> And in the near future, it’s more than likely that standard static imports will be lazily evaluated in Observable also

That's great news, and once it's in I'm more than happy to rip out lazyImport().

Stay tuned. I’ve got it working and if I can get it reviewed it should be available this week.

That's amazing news!

Can you ping me as soon as it's published? I expect I'll have to update https://observablehq.com/@mootari/observable-ast to match the new source structure.

the lazyImports approach was great for dev dependencies like unit testing, by lazy importing it you avoid at least one network round trip to the API endpoint. But you still ended up shipping the actual unit test code and documentation in the module though, so it was not totally ideal still, just better than static imports.

Tom Larkworthy

when `submit` is true, the range value label won't get update when a user drag the slider.
This is probably intended but lose the ability to "preview" the current  range. It would be more intuitive to preview the range while using slider even the final value can only take effect after submit button is pressed.

Is it possible to separate "update slider value label" and "assign final range (e.g. either via submit button or mouse release event"?

@easz rangeSlider() uses the input widget from https://observablehq.com/@jashkenas/inputs which handles both the submit button and the text output. So unfortunately it's not possible to change the current behavior without reimplementing input().

For what it's worth, you can built your own widget around rangeInput() (like I did in https://observablehq.com/@mootari/gen-what-goes-up). I also plan to add a version that matches Observable's Inputs library. Don't know when I'll get to that, though.

@mootari thanks for the suggestion. I will try to make one. :p

Let me know if you run into any problems, or if the documentation is unclear. :)

a quick attempt: https://observablehq.com/@easz/range-slider#cautious

I think the cautious option should be implemented in rangeInput(), as rangeSlider() merely decorates it.

yes, that would be much cleaner and elegant. My current "fix" is to directly manipulate `action` parameter from `@jashkenas/inputs` object which is declared in rangeSlider().   It is not the best way... :(

On second thought, rangeSlider() is the right place, but rangeInput() should dispatch a synthetic "change" event on release.

Once I had the 'cautious' option implemented, I found out that the "mouseup" event or handleDragStop() is not fired if I release mouse outside the input elements. Of course it is not relevant without 'cautious' feature. Just a comment.

Purpose-built for displays of data