Ensure binary data is a DataView

[manzt]

Partially addresses #151.

Widgets using the model.on API expect the second argument for the msg:custom callback to be an an array of DataView not Array<ArrayBuffer>. This data comes from the unpacking of the comm message data in jsonParse.

https://github.com/jupyter-widgets/ipywidgets/blob/c579fcd1265af77a0d793aa47a7b9a401d952550/packages/base/src/widget.ts#L318-L321

This PR should address sending binary to the front end, but not the reverse. Also it would be awesome if there was a way to avoid base64 encoding the binary data... but I assume that requires many more changes at a deeper, Shiny level. This is a starting point.

That said... quak doesn't transfer very much data and it seems to work reasonably well (locally).

Screen.Recording.2024-07-30.at.22.02.33.mov

[cpsievert]

Aha, thanks so much for this!

I added some logic to do that base64 encoding before sending client -> server. Although now I'm realizing that shinywidgets' backend should probably also be going base64 string -> bytes when it handles messages.

Any chance you know off hand of an example that would need to send buffers client -> server? The one I've been using doesn't seem to need that.

import polars as pl
import quak
import shiny.express

from shinywidgets import render_widget

df = pl.read_parquet("https://github.com/uwdata/mosaic/raw/main/data/athletes.parquet")

@render_widget
def df_widget():
    return quak.Widget(df)

[manzt]

Any chance you know off hand of an example that would need to send buffers client -> server? The one I've been using doesn't seem to need that.

Off the top of my head, not that I can think of. Could probably put together an example of exporting canvas data to binary blob.

[cpsievert]

Ok thanks, I'll revert 30aedcf for now, then start another PR with a reminder to look more into this