Pluto.jl: DOM interaction mechanism

[fonsp]

A way to define a cell like:

t = Saturn.animated(5fps, :loop, 1:100)

Restarts when (reactively) reevaluated.

but what about multiple animators in one notebook? using the same fps for all makes sense.

[fonsp]

Could reuse Julia syntax, like returning a generator. But then you can't return generators anymore...

[fonsp]

Also, plotting in julia is not up to the task by default. UnicodePlots and Plotly are the fastest, but theoretically it could be even better. (What about a D3.js wrapper? 🙂🙂🙂)

[kolia]

How about using Observables instead of Generators for this?

Users can write @async blocks to update the observable's value on the julia side.

The rendering of values can then be polled at a fixed fps, independently of how many notebook values are Observables and when they've last been updated. Pluto could add a listener to each Observable to track whether it's been updated since the last render.

[fonsp]

Hey @kolia, thanks for your suggestion!

This issue was a little outdated, but we now see animation as just a special case of _DOM interactivity_: allowing cells to display live sliders, buttons and other cool things. (An animated value is a "slider that advances itself".)

For DOM interactivity, the philosophy is that Pluto _already has interactivity_ in some sense: you can define a parameter in a cell, like

t = 3

and changing the code for that cell updates all dependent cells. Like the example GIF in the README.

Turning this interactivity into one with DOM elements should be super easy, and hopefully accessible to users who don't understand JS, callback functions, @async, generators or Observables (using Observables inside Pluto is confusing, since they are not reactive (Pluto works using static code analysis, not using Observable wrapping)). Ideally, the syntax would go from t = 3 to something like

@pluto_interact t = Slider(1:9)

with the option to give a callback function instead of a direct assignment:

t_slider = @pluto_interact Slider(1:9) do val
    global t = val^2
end

I am doing some experiments on how to implement this - the question is how built-in to Pluto it will be. Ideally, we could add functionality to Pluto so that any package could define a new kind of interactivity for Pluto.

You are welcome to collaborate, if you have time this week! I will post updates in this Issue.

[kolia]

@fonsp thanks for working on this awesome project, you have made amazing progress in just a few weeks!

Indeed, pluto already has interactivity, and interactive widgets with an interface resembling what observablehq has would be ideal.

One way or another, you're going to need to bridge between julia and js/DOM in both directions. WebIO.jl is one impl of that, though it does look like there's overlap with bits and pieces that pluto already has implemented. Might make sense to either use WebIO or find inspiration from it?

I'd love to help, though it'll be hard for me to put in many hours. I'll be monitoring to see what plan you come up with for this.

[fonsp]

That's right - the bridge between JS and your code isn't fully there yet. Right now it's one-way-ish: your code can output a HTML(<script>toDoSomething()</script>), and this is plenty fast. A more direct method to send things to JS from your code might be useful, but is too niche to work on in these early stages.

Pluto already has bidirectional communication between julia and JS - the catch is that this communication is between JS and the Pluto.jl server, and the server communicates in turn with your code.

The extension can be quite simple: add a websocket endpoint for callfunction_reactive(funcname, args...) that can be called from JS, to directly influence your code.

[kolia]

Does removing the help wanted label mean you're planning on doing this yourself soon?

I've been chipping away at this very slowly, planning on pushing something in a few days...

[fonsp]

Yes it did - today actually! But let's talk in private about what we have? My email address is in my github profile.

Or you could push what you have so far and send me a link. I'm curious to see your approach!

[fonsp]

And apologies for not updating this thread in time!

[fonsp]

Sneak peek:

Still an experiment right now, but I'll try to make it more stable today.

I am trying to make this UI package work without "special treatment" from Pluto - it would hook into the Pluto module and the JS front-end when loaded.

[fonsp]

I was going about this the wrong way - the @bind macro will be built into Pluto (taking care to keep saved files executable), which takes a symbol and _any object that can show to text/html_.

This will create a Bond object, which renders to

<bond def="your_symbol"> [your object as HTML] </bond>

The JS front-end will use the stdlib from ObservableHQ ❤❤ to turn the contained DOM into a javascript _Generator_ using observablehq.Generator.input, which is the javascript equivalent of julia's Observables. These are pushed to your notebook, and the reactivity fairies do the rest.

---

This makes it super easy to create nice HTML/JS-based interaction elements - a package creator simply has to write a show method for MIME type text/html that creates a DOM object that triggers the input event. In other words, _Pluto's @bind will behave exactly like viewof in observablehq_.

For example, the Slider struct will be defined in a separate package, perhaps Hyperscript.jl.

[fonsp]

Sneak peek number 2:

[fonsp]

There's a detailed demo about @bind built into Pluto 0.7.0, which includes these demos! Go to the new _sample gallery_ from the main menu.

🎈