Is ?v=3 correct when requesting notebook js?

Community Help
1

Hi! My goal is to get a notebook running on a static webpage. I’ve been poking around, but I’m wondering if I can confirm a thing or two about the observable runtime.

While working through the runtime example I made the mistake of removing ?v=3 from a request to https://api.observablehq.com/@tmcw/hello-world.js?v=3, having mistakenly thought maybe v corresponded to the runtime version. Am I correct in understanding:

  • ?v=1: returns a deprecated notebook format (requires runtime.load()?)
  • ?v=3: returns the currently preferred format
  • ?[blank]: equivalent to ?v=1

Long story short, is it correct to use runtime v4 along with ?v=3?

1 Like
2

Yep! Use the v=3 format with the latest version of the runtime. Sorry for the confusion—we are in a slightly awkward spot where we haven’t quite finished the migration to the new format.

1 Like
3

Just curious: do you plan to keep v1 API support for the foreseeable future? Just debating whether to build on it (it’s a bit easier at the moment) or whether to figure out v3 now to prevent breakage. Thanks!

4

It’ll keep working for the foreseeable future, but we’d love to understand your use case better. What makes v1 easier for you?

5

Sorry to jump in here on this thread with a similar issue for v1 versus v3 runtime API troubleshooting. Much gratitude for implementing v3 for tgz!

Granted our collaborative notebook is excessively sprawling, but I would welcome any tips on how to mitigate Uncaught RangeError: Maximum call stack size exceeded so e.g. d3 and/or barRangeSlider can load in an untarballed localhost-hosted v3 version of this notebook: https://observablehq.com/@thadk/windfall-awareness-notebook-prototype (really, I think this holds the issue: https://observablehq.com/@bumbeishvili/data-driven-range-sliders )

I will soon try using NPM again with the v3 tgz, which is our main use for the tarball. Still, it was comforting (if not necessarily essential) with v1 to see even index.html unhosted (file://) html load the full notebook when uncompressed in both Firefox, Safari and Chrome. Now, running a server is required and only works in Safari/Chrome yet.

After further testing, it seems like barRangeSlider is using up the call stack in a different order in v3 than it was in v1 (though that part also didn’t work in v1 of the independent runtime). If I edit the v3 .js and pull d3, fastxml, and form above that, no problem:

const child1 = runtime.module(define1);
  main.variable(observer("fastXml")).define("fastXml", ["require"], function(require){return(
    require('https://bundle.run/fast-xml-parser@3.12.16')
    )});
      main.variable(observer("d3")).define("d3", ["require"], function(require){return(
    require("d3@5")
    )}); const child5 = runtime.module(define5);
 main.import("form", child5); main.import("table", child1);
    const child2 = runtime.module(define2);
  main.import("select", child2);
  main.import("textarea", child2);
  main.import("file", child2);
  main.import("input", child2);
  main.import("slider", child2);
  main.import("date", child2);
  main.import("radio", child2);
  main.import("checkbox", child2);
  main.import("number", child2);
  const child3 = runtime.module(define3);
  main.import("NumberParser", child3);
  const child4 = runtime.module(define4);
  main.import("barRangeSlider", child4);
6

This has been fixed in release 4.2.1 of the Observable runtime (which should be live in tarball downloads in a few minutes). Thanks for the report!

2 Likes
7

Sorry for such a delayed response! In short, if I recall correctly, v1 bundles imported code with the notebook where v3 relies on import to resolve it. I’ve dragged my feet for a long time about embracing yield, generators, import, and ES6 in general, but I’m making an effort to get on board with it.

The particular use-case was for downloading, caching, and exposing notebook cells in an idyll document. Since the code may get bundled with non-import-aware tools, I think external imports means doing some of that resolution ourselves instead of being able to get away with having everything simply available from a single fetch.

So in that sense it’s just a convenient side effect that makes things a bit easier to process.

Do correct me if I’m mistaken about any of this though. Like I said, I have a bit of a loose grasp of the specific details of import support—both implications and current status in different environments.

8

Even with v=3, you’ll get the complete code (meaning including all transitive notebook dependencies) when you download the tarball. So I’d use that instead of the .js endpoint if you want to download everything.

1 Like