Improved `%%javascript` cell magic.

[ellisonbg]

I have been working on am improved %%javascript cell magic and I wanted to run the idea by others to gauge interest. The existing %%javascript magic uses eval on a string of JavaScript code. While this works, it is relatively difficult to load external JavaScript packages and it is awkward to work with the DOM. I have developed a prototype with the following features:

• Uses the sucrase library to allow a use to write modern JS, JSX or even TypeScript.
• Run the code by appending a script tag to the page with type=module. This allows users to directly import modules from CDNs that support modules, such as Skypack.
• Includes a JS implementation of a display function that takes a React element, native DOM element or list of thereof and renders it into the output of that cell.

The result of all this is that a user can write code that looks like the following:

%%typescript

display(<h1>Hello World</h1>);

And it will "just work". I would propose that this improved magic replaces the existing javascript magic. We might also want to have multiple variants that handle plain javascript, typescript, etc. At this point, I mostly want to get feedback on this directly to see if there is interest in this being in IPython. Here are a couple of example of this in action:

[ellisonbg]

ping @Carreau

[Carreau]

I'm happy to deprecate the current javascript magic before 8.0, but I think that if anything a magic like that should be in a separate package to move at its own speed.

Even in a separate package, we can make IPython depend on it, or auto load it when present.

I also want to be really careful about "just swapping" as it may break a lot of existing code.

[ellisonbg]

Good points, I think it makes sense to be in a separate package, are you open to that package being in the IPython org?

[ellisonbg]

I should note that the entire code base for this is in a single notebook and the core code is 60 lines (Obviously the final version with tests/docs will be more). All that to say I don't have this in an existing repo that could be transferred over and would need a repo to exist that I could submit a PR to.

[Carreau]

are you open to that package being in the IPython org

Of course. The main question is wether it is the best place for people to find it. Will it work only with Lab ? Or also nteract/vscode/... ? Is the approach generic enough that pieces of it cold be reused by other kernels ?

I'll trust you with the location, once you've decided I'm happy to add deprecation warnings to %%javascript

[ellisonbg]

The implementation uses the HTML MIME type and should be reasonably portable across frontends that render the HTML output type. It should also be fairly straightforward to port to work with other kernels as the main logic is two string templates.

In terms of location I propose we create an ipython/javascript_magic repository for this.

[Carreau]

In terms of location I propose we create an ipython/javascript_magic repository for this.

That sounds great !

[Carreau]

BTW, the %%javascript is "just"

    @cell_magic
    def javascript(self, line, cell):
        """Run the cell block of Javascript code"""
        display(Javascript(cell))

Should we also start deprecate the Javascript object ?

[ellisonbg]

Not sure yet, I need to see if it makes sense to use a corresponding class in the new implementation. Will report back.

…

On Wed, Dec 8, 2021 at 9:17 AM Matthias Bussonnier ***@***.***> wrote: BTW, the %%javascript is "just" @cell_magic def javascript(self, line, cell): """Run the cell block of Javascript code""" display(Javascript(cell)) Should we also start deprecate the Javascript object ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13376 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUCC35BOQ4X4L2DXFPTUP6HJXANCNFSM5JSKIUXQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[blois]

In the scope of this I think it would also be good to think about how to expose an API from the host application to the Javascript module. The goal would be to enable these Javascript outputs to leverage Comms and possibly other APIs with a standardized API.

There's a bit of discussion on this general idea in https://github.com/Quansight-Labs/jupyter-output-spec.

For implementation and end user ease-of-use it should be as simple as the user optionally adding a export function render(args) {} to the module which would be invoked if present.

I did a very primitive exploration of this in JupyterLab at https://github.com/blois/js-module-renderer/.