Support ipywidget based interactive elements

[parente]

The impl in #1 will not be able to support ipywidgets or declarative widgets yet:

WRT ipywidgets support, there isn't support for jupyter-js-services yet. I'll probably end up moving to the jupyter-js-services comm API and shimming the current API (notebook compatibility), for ipywidgets 5.0 (next release) or 6.0 (depends on how much time I can allocate to 5.0).

From jupyter/dashboards#105 (comment)

Once the ipywidgets support for jupyter-js-services lands, the app here can start to take advantage of it.

[parente]

A shim for using jupyter-js-services is now in the ipywidgets master branch and will appear in the 5.0 release which should coincide with the notebook 4.1 release. @lbustelo has been figuring out how to get declarative widgets working standalone in the associated issue above. That work is pretty much what has to get implemented here.

[parente]

Ref jupyter-widgets/ipywidgets#264

[jhpedemonte]

@jdfreder We're trying to get jupyter-js-widgets working in our dashboard app, but running into problems with the WidgetManager. We adapted the web3 example. Our understanding is that there should be just one WidgetManager instance for the page, managing all of the widgets.

We have a layout similar to the notebook, with individual "cells". Now we need to have WidgetManager properly update the view in the correct cell. However, by the time we get to WidgetManager.display_view(), the incoming message has had most of its information stripped out (see https://github.com/jupyter/jupyter-js-services/blob/2df63c8316a061ea441d81641e5fe6a51d2f16cc/src/kernel.ts#L896). In the notebook, we would have tried to find the relevant cell by the message's parent_header, but we don't have access to that.

Can you advise? Is this an issue with jupyter-js-services or do we now have to do something different outside of the notebook? How can jupyter-js-widgets work with multiple widgets living in different DOM nodes?

[jdfreder]

I think that's something that should be brought to @blink1073 's attention. @blink1073 the widgets, in the context that @jhpedemonte is describing, and in the context of the live notebook, use the full message to look-up the cell via the message header original message id. IIRC one piece of this is already available to us, via KernelFuture, and that is the sent message ID. However the piece that is missing is the original message ID (a way to look-up if the message is in response to another message and if so, what that message's ID was).

Maybe you've already thought of this, and there's another way to do it with the new API.

@jhpedemonte if you're notebook-like app is written completely using jupyter-js-services, you may be able to set something up with the KernelFuture .reply callback, in the area of the code that sends the execution request for a cell. You could maintain a map of replies -> cells.

[blink1073]

@jdfreder, my understanding that whenever the kernel sends a message to the client, it uses the most recent received msgid as the outgoing parent id. We are using the parent msgid as the msgid in the KernelFuture. We could put the current msgid and the parent msgid as two separate fields if that would help.

[parente]

/cc @lbustelo

[blink1073]

@jdfreder, I would say the mapping of msgId -> cell should reside in the notebook itself, not in the Kernel.

[jhpedemonte]

@blink1073:

We could put the current msgid and the parent msgid as two separate fields if that would help.

Yes, I think we need that additional info. We may be able to do something hacky with KernelFuture, but I think it would be cleaner to have the relevant info passed in to us (from _Kernel.handleCommMsg()).

I would say the mapping of msgId -> cell should reside in the notebook itself, not in the Kernel

Agreed. In our case, we would handle that mapping in our app, making use of the message IDs from the Kernel messages.

[jdfreder]

@jdfreder, I would say the mapping of msgId -> cell should reside in the notebook itself, not in the Kernel.

Definitely, that's how it's done now.

We could put the current msgid and the parent msgid as two separate fields if that would help.

I think that would be great!

Basically it needs to be accessible by this callback https://github.com/jupyter/jupyter-js-services/blob/2df63c8316a061ea441d81641e5fe6a51d2f16cc/src/kernel.ts#L896 , in some form or another.

[blink1073]

Ah, it may be that we just need a better docstring for this attribute: it is the msgId of the message from the client. Each message passed to the KernelFuture will have that id as its parent_header.msg_id, and the msg_id from the server as its header.msg_id. It is up to the notebook then to keep track of any additional information required.

[jhpedemonte]

@blink1073 I'm still confused. How can we sync the message coming in to WidgetManager.display_view (which contains only data and no message IDs -- as passed from kernel.ts) with the onReply to the KernelFuture?

[blink1073]

Ah, I see, so, if we passed the full message to the Comm would that be preferable? Then you'd have access to the headers.

[jhpedemonte]

Yes, I think that would work for us (it's how it is done in the older Notebook code).

[blink1073]

Discussion in jupyter/services#64.

[parente]

Full-message passing merged here jupyter/services#66

[jhpedemonte]

Trying to get latest ipywidgets code (293705e7) working against our minimal-kernel Docker container. We've got things building and running like so:

• Build all (non-Notebook dependent) ipywidgets static sources as single module.
• This module is loaded by WidgetManager based on web3 example.
• Install same commit in minimal-kernel container: pip install git+https://github.com/ipython/ipywidgets.git@293705e7

Trying to load some code and don't see any more errors on the client side. But I also don't see a widget. minimal-kernel logs show this warning:

[IPKernelApp] WARNING | Widget Javascript not detected.  It may not be installed properly.

Looks like the server-side code for ipywidgets is expecting some version info in a comm message. And that should be sent from the client by ManagerBase.validateVersion. But that never gets called.

Only call I see is in the (Notebook-dependent) manager.js. So looks like we need to update our WidgetManager code to make a similar call.

@jdfreder @blink1073: Does this make sense? Are there any other calls I'll need to get jupyter-js-widgets working in a non-Notebook env?

[blink1073]

@jhpedemonte, I'm not going to be much help on this one, I haven't followed too closely what @jdfreder has been doing on this front.

[jhpedemonte]

No problem. Enhancing our WidgetManager with that validate code got us through this section. We are now seeing a widget on the page. Now trying to figure out how to handle update messages for the widget.

[jdfreder]

Only call I see is in the (Notebook-dependent) manager.js. So looks like we need to update our WidgetManager code to make a similar call.

Yup

Now trying to figure out how to handle update messages for the widget.

The widget should handle it's own state updates, as it does in web3. IOW you shouldn't need to do anything to get this to work if the comm shim is working properly.

[jhpedemonte]

Pushed code to use latest jupyter-js-widgets. That code hasn't yet been updated to latest jupyter-js-services (passing full message), so currently we are using a fork (see PR jupyter-widgets/ipywidgets#328).

With this code we can display a widget, but not get updates.

The widget should handle it's own state updates, as it does in web3. IOW you shouldn't need to do anything to get this to work if the comm shim is working properly.

@jdfreder: We followed web3 as closely as we can, but we're still having issues. In our test example, we have an interact widget with a string. When updating the string in the text field, it should update in the output.

We see the WS messages coming in, for clear_output and display_data messages. But those aren't handled by anything.

[jhpedemonte]

We've been testing with the interact widget, where we saw issues outlined above. After some changes, though, we have the web3 demo working just fine (uses IntSlider, Text widgets). Will test with other widgets tomorrow.

[jdfreder]

Related to jupyter-widgets/ipywidgets#328

[parente]

ipywidgets are running. web3 demo is initial "proof". Of course, we'll find more problems with ipywidget, declarative widgets, etc. over time as we build out bigger demos. Those are separate tasks.

Styling problem with output area is tracked in #10. (ipywidgets display outside of the gridstack layout).