Add example capturing and displaying output of htmlwidget.

[seanbirchall]

Trying to wrap my head how best to capture outputs between looking here and the quarto-live repo. A small snippet in example/ would help tremendously. Also it seems like the best route is to capture outputs from within R?

From quarto-live we use R and evaluate to eval the code wrapped in webR.captureR
https://github.com/r-wasm/quarto-live/blob/bfd6811e6dc804a7b8bc8653ff5d20dee67bb103/live-runtime/src/evaluate-webr.ts#L210

We then loop through our result object after evaluating our R code and handle each case, one worth noting is using replayPlot to capture plot outputs
https://github.com/r-wasm/quarto-live/blob/bfd6811e6dc804a7b8bc8653ff5d20dee67bb103/live-runtime/src/evaluate-webr.ts#L439

And have a handful of helper functions to append html output via asHtml
https://github.com/r-wasm/quarto-live/blob/bfd6811e6dc804a7b8bc8653ff5d20dee67bb103/live-runtime/src/evaluate-webr.ts#L248

Then for widgets knitr is required and I must be using knit_asis to capture widgets using staticRender()?
https://github.com/r-wasm/quarto-live/blob/bfd6811e6dc804a7b8bc8653ff5d20dee67bb103/live-runtime/src/evaluate-webr.ts#L571
https://github.com/r-wasm/quarto-live/blob/bfd6811e6dc804a7b8bc8653ff5d20dee67bb103/live-runtime/src/evaluate-webr.ts#L496

From webR examples appears I can handle this all natively
https://github.com/r-wasm/webr/blob/04cdbae6795fcaa20f01c2bf48a35d51b23643b5/src/examples/plot/plot.js#L16:L25

https://github.com/r-wasm/webr/blob/04cdbae6795fcaa20f01c2bf48a35d51b23643b5/src/examples/plot-multiple/plots.js#L24:L47

So I guess my follow would be is there a way to handle widgets similarly from webR without knitr? Also this is all in the context of say a repl app for example I want to eval R code and capture what it returns.

[georgestagg]

For the webR REPL we try to avoid R package dependencies, to keep the initial download size as small as possible. As such, we avoid using the evaluate or knitr packages directly in the webR repo.

On the other hand, we allow ourselves to use them with Quarto Live and take the hit on download size as the Quarto pages load.

I would say both approaches are reasonable, but doing things without capturing with evaluate and rendering with knitr functions makes things more difficult.

A small [capturing htmlwidgets] snippet in example/ would help tremendously.

I agree this would be useful. I have tagged the issue with the "feature" tag to remind us to take a look at that when we can.

Even with an example, the snippet will probably not be small even if minimal. Managing htmlwidgets is difficult because the JS and CSS files required are stored on the Emscripten VFS, so the htmlwidget HTML code, when shown for example using browse(), will need to be modified to find required JS/CSS files on the VFS, read the file's content, and re-inject the result into the HTML to be shown in an <iframe> element. The code to do this work will need to be included in the example, and our existing code is probably not so robust to handle every use case.

For the webR REPL, you can see an example of such code here:

webr/src/repl/App.tsx

Lines 97 to 153 in 8895ef0

	async function handleBrowseMessage(msg: BrowseMessage) {
	const { url } = msg.data;
	const root = url.split('/').slice(0, -1).join('/');
	const decoder = new TextDecoder('utf8');
	let content = decoder.decode(await webR.FS.readFile(url));
	// Replace relative URLs in HTML output with the contents of the VFS.
	/* TODO: This should really be handled by a custom print method sending the
	* entire R object reference to the main thread, rather than performing
	* regex on HTML -- famously a bad idea because HTML is context-free.
	* Saying that, this does seem to work reasonably well for now.
	*
	* Since we don't load the `webr` support package by default, the
	* alternative looks to be using hacks to register a bunch of custom S3
	* generics like `print.htmlwidget` in the "webr_shim" namespace, and
	* then maintain the `search()` order as other packages are loaded so
	* that our namespace is always at the front, messy.
	*/
	const jsRegex = /<script.*src=["'`](.+\.js)["'`].*>.*<\/script>/g;
	const jsMatches = Array.from(content.matchAll(jsRegex) || []);
	const jsContent: { [idx: number]: string } = {};
	await Promise.all(jsMatches.map((match, idx) => {
	return webR.FS.readFile(`${root}/${match[1]}`)
	.then((file) => bufferToBase64(file))
	.then((enc) => {
	jsContent[idx] = "data:text/javascript;base64," + enc;
	});
	}));
	jsMatches.forEach((match, idx) => {
	content = content.replace(match[0], `
	<script type="text/javascript" src="${jsContent[idx]}"></script>
	`);
	});
	let injectedBaseStyle = false;
	const cssBaseStyle = `<style>body{font-family: sans-serif;}</style>`;
	const cssRegex = /<link.*href=["'`](.+\.css)["'`].*>/g;
	const cssMatches = Array.from(content.matchAll(cssRegex) || []);
	const cssContent: { [idx: number]: string } = {};
	await Promise.all(cssMatches.map((match, idx) => {
	return webR.FS.readFile(`${root}/${match[1]}`)
	.then((file) => bufferToBase64(file))
	.then((enc) => {
	cssContent[idx] = "data:text/css;base64," + enc;
	});
	}));
	cssMatches.forEach((match, idx) => {
	let cssHtml = `<link rel="stylesheet" href="${cssContent[idx]}"/>`;
	if (!injectedBaseStyle) {
	cssHtml = cssBaseStyle + cssHtml;
	injectedBaseStyle = true;
	}
	content = content.replace(match[0], cssHtml);
	});
	filesInterface.openHtmlInEditor(content, url);
	}