Fabian Iwand

Tabs

Input States

Table Inspector

Search Query Tokenization

Zoomable Element

Optgroups as selection aids

Inputs.table() with Colored Rows

Choices.js Input

Linking Multiple Ranges

inputTemplate

Auto-Sort Inputs

Date and Offset Sliders

Submittable Input Forms

DOM Inspector

Custom Inspectors

Snap A Slider To Values

Checking a version's publish date

Efficient Responsiveness

Sortable Notebook List

Displaying Progress

Range Slider

Search Results Paging

Monitoring Events

Prime Numbers Slider

Mutable Forms

Sticky Positioning

Notebook Teasers

Straight Skeleton - Reference Paths

GIF Converter (canvas & SVG)

Arguments Widget

2D Slider

Monitor

Signature - A Documentation Toolkit

Dashboard with Inputs

Dashboard

Widgets and helpers

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.