Fabian Iwand

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.