Don't assume a global WebIO instance in JS code (fix JupyterLab).

[twavv]

This is a fix for now. In the short run, we should expose a way to load this kind of thing from within handlers (possibly via existing Asset stuff - but we'd need a way to do it synchronously probably).

Changes

• Mark the built JS file as binary to exclude it from command line diffs :^)
• Change the output target to be UMD module so that it is importable via SystemJS (this makes the export ... bits work)
• Call the JS init function on scope mount with the current WebIO instance (it's available in onimport but not as part of the global scope).

Fixes JuliaGizmos/WebIO.jl#339.

[sglyon]

Thanks @travigd -- I appreciate your continued help here.

The js code that I have been attaching to WebIO really doesn't need to be there. My goal is only to define a couple js functions that don't lean on WebIO in any way so that I can reference them in callbacks from the Julia side.

Can you think of a better way to make that happen across all platforms?

[twavv]

At this time, no - I think this is going to be the best workaround. What I'd like to do is make our existing asset-loading also include a synchronous (i.e. non-promise-based) API.

Currently, you can do this:

using WebIO
mybundle = Asset("./path/to/bundle.js")
# Setup the nodes and whatnot
onjs(foo, js"""
async function() {
  const bundle = await $mybundle;
  // Assuming bundle exports a function called foo
  bundle.foo();
}
""")

The issue is that it currently has to be async - which isn't the end of the world, but we could probably (I have to look into SystemJS internals to guarantee this) expose a synchronous API (it would throw an error if the asset hasn't already been loaded). Something like

onjs(foo, js"""
function bar() {
  const bundle = WebIO.loadSync($mybundle);
  bundle.foo();
}
""")

For right now, I think adding onto the WebIO instance is a good stopgap until we implement something like the above.