feat(unstable): add Deno.jupyter.display API

[rgbkrk]

This brings in display as part of the Deno.jupyter namespace. I went ahead and hooked up our execute_result handling to use Deno.jupyter.format so that DataFrames, Canvas, and other objects can be displayed nicely (even without implementation in the respective libraries).

• Write the types in cli/tsc/dts/lib.deno.unstable.d.ts
• Emit execute result
• Write tests (port over from https://github.com/rgbkrk/display.js)

[bartlomieju]

How can I keep the type information around? Also, I'd love to be able to have documentation of these functions, which is not clear to me on how we expose it for these conditionally hidden functions (since they're only available when running the deno jupyter kernel).

Could you elaborate what do you mean by type information here? In general when new APIs are added then the type declarations shipped with Deno should be updated - the Deno.jupyter namespace is defined in cli/tsc/dts/lib.deno.unstable.d.ts around line 2080.

Could we migrate to emitting the execute result inside of the evaluation result handling directly? Then we wouldn't have to do the extra serializing and deserializing of the media bundles.

Yes, I think we can do that with Deno.jupyter.broadcast API.

How can I includes tests for display, format, etc? I wrote tests for them in https://github.com/rgbkrk/display.js as deno package development itself makes it really simple.

We can add Deno.jupyter.format to internals symbol and then use it in a test file. This is already done in 40_jupyter.js:

internals.enableJupyter = enableJupyter;

Then in a test file you can do: const jupyterFormat = Deno[Deno.internal].jupyterFormat to get access to this function.

[rgbkrk]

In general when new APIs are added then the type declarations shipped with Deno should be updated - the Deno.jupyter namespace is defined in cli/tsc/dts/lib.deno.unstable.d.ts around line 2080.

I can update the type definitions. Are we not able to write typescript that would get transpiled and then included in the resulting Deno binary?

Could we migrate to emitting the execute result inside of the evaluation result handling directly? Then we wouldn't have to do the extra serializing and deserializing of the media bundles.

Yes, I think we can do that with Deno.jupyter.broadcast API.

What's the best way for me to pass the execution count into the Runtime.callFunctionOn call?

Then in a test file you can do: const jupyterFormat = Deno[Deno.internal].jupyterFormat to get access to this function.

Awesome, I'll do that.

[bartlomieju]

I can update the type definitions. Are we not able to write typescript that would get transpiled and then included in the resulting Deno binary?

You can write TypeScript in internal code and it will get transpiled automatically, but for public APIs (think all Deno.* APIs) we need to write these type defs manually anyway.

What's the best way for me to pass the execution count into the Runtime.callFunctionOn call?

Create a CallArgument like so:

CallArgument {
  value: Some(Value::Number(execution_count)),
  ..Default::default()
}

and pass it in arguments vector to Runtime.callFunctionOn.

[rgbkrk]

cc @manzt -- bringing display.js into Deno.jupyter. I'd love your perspectives as we seek to include display as a built in to Deno.

[manzt]

Super exciting! Thanks for pinging me. Maybe there is a way anywidget could also integrate more deeply but for now I think it makes sense to keep the APIs in userland.

[rgbkrk]

Maybe there is a way anywidget could also integrate more deeply but for now I think it makes sense to keep the APIs in userland.

The big piece we likely need for anywidget is going to be the comm sending and receiving piece. Given deno's commitment to web standards it seems like we'd build on EventTarget and likely expose both a CommManager (Registry?) as well as a simple Comm class. Some portion of it probably belongs in userland for speed of iteration and minimalism in the kernel, however I think the Comm stuff is a bit inescapable for needing kernel side implementation.

[bartlomieju]

LGTM, this is a fantastic functionality @rgbkrk 🚀