Notebook Display Outputs Unrenderable in Conversion

[MSeal]

A replication from github.com/plotly/plotly.R/issues/1763 where the issue could not be addressed directly.

When using R Plotly in a Jupyter Notebook, the interactive widgets will not appear in the output when using nbconvert to transform it to html.
Console in the browser says: Uncaught ReferenceError: Plotly is not defined.

More details from that thread led to posting in this project, but essentially the html outputs in the cell aren't renderable without javascript extensions present, which on a plain html file don't exist.

Furthermore, looking through the file it seems like every script associated has a the png embeded into the html, causing the rendering to be duplicated on every media type including text. You likely want to only render the PNG on the image output and leave the other with the raw data to reproduce to PNG. This causes a multi-kilobyte display output to take megabytes of space.

I'm cross posting this with https://github.com/IRkernel/repr as I'm not familiar enough the packages here to know where changes would need to be made.

[MSeal]

IRkernel/repr#129

[jcheng5]

If I'm understanding correctly, the issue is manifesting with R Plotly but I'm guessing would apply to any R HTML Widget? Is the desired functionality here that a non-interactive version is included in the nbconvert output, or that the JS dependencies be automatically included in nbconvert output thus letting the fully interactive widgets work?

(I personally know almost nothing about Jupyter/JupyterLab so please ELI5)

[MSeal]

If I'm understanding correctly, the issue is manifesting with R Plotly but I'm guessing would apply to any R HTML Widget?

Correct.

Is the desired functionality here that a non-interactive version is included in the nbconvert output, or that the JS dependencies be automatically included in nbconvert output thus letting the fully interactive widgets work?

It may be hard to have the headless execution output the proper JS dependencies because it's just exporting a single html file and you'd have to map some script dependencies to non-local files.

You can think of nbconvert as a tool to convert a notebooks document (an .ipynb extension file) to another single file format, e.g. a PDF, an HTML page, etc. Notebooks are self-contained files so the tooling tries to preserve that in translation, sacrificing dynamic elements for static ones when it's not possible to keep them dynamic in the given format. For html this is a little awkward because it could preserve interactivity, but unless it's highly reliable it's probably better to just have the static results imo.

[jcheng5]

Does this mean that all Jupyter widgets are written to provide two types of output, one interactive and one non-interactive?

[MSeal]

Somewhat yes. The way Jupyter handles outputs is to have clients emit a display message with the output in one or many media formats (e.g. plaintext, image/png, html, etc). Client interfaces then choose the output format to use in rendering that makes the most sense given the situation. Often this is a simple choice of preferring the format most native to the environment (usually a browser). Oftentimes when there is a dynamic media type for interacting with the data a static version is sent along as well in case it can't render.

In regards to

You likely want to only render the PNG on the image output and leave the other with the raw data to reproduce to PNG. This causes a multi-kilobyte display output to take megabytes of space.

In this case instead of sending data that can be translated to different formats the image data as a base64 PNG is shipped in each media format embeded which somewhat defeats the purpose of having multiple media types and causes large filesize bloat issues.

Let me know if any of those details needs more explanation.

[jcheng5]

Thanks, that's very helpful. Are these the most relevant docs?

https://ipypublish.readthedocs.io/en/latest/code_cells.html#object-output-formats
https://ipython.readthedocs.io/en/stable/config/integrating.html#rich-display

From the second link, html and javascript are different flavors, where html expects static HTML and javascript expects potentially interactive HTML?

[jcheng5]

Or have I been thinking about this all wrong... maybe it's the case that Jupyter widgets are mostly interactive when actually using the notebook, and there's just not generally a strong expectation that nbconvert/ipypublish rendered output should be interactive, even if it's HTML?

[MSeal]

Yes those are links for how this is published in the IPython kernel. At the end of the day these become d https://jupyter-client.readthedocs.io/en/stable/messaging.html?highlight=display#messages-on-the-iopub-pub-sub-channel.

From the second link, html and javascript are different flavors, where html expects static HTML and javascript expects potentially interactive HTML?

Yes though I see people shoving javascript snippets into HTML display outputs all the time so it's not uncommon to just do that. https://jakevdp.github.io/blog/2013/06/01/ipython-notebook-javascript-python-communication/ has a good walk-through.

Or have I been thinking about this all wrong... maybe it's the case that Jupyter widgets are mostly interactive when actually using the notebook, and there's just not generally a strong expectation that nbconvert/ipypublish rendered output should be interactive, even if it's HTML?

It's not formally defined. But yes I think they're generally only active when actually using the notebook and non-interactive when exported. In this case if it's HTML and it could be interactive I don't think it'd hurt to do so. But if so then the javascript that's needed to execute has to be injected (or a reference injected) as well.