One of the goals of the Jupyter Notebook is to minimize the “distance” the user is from their data. This means allowing the user to quickly view and manipulate the data.
| Before the widgets, this was just the segmentation of code and results from executing those segments. | Widgets further decrease the distance between the user and their data by allowing UI interactions to directly manipulate data in the kernel. |
Jupyter interactive widgets are interactive elements, think sliders, textboxes, buttons, that have representations both in the kernel (place where code is executed) and the front-end (the Notebook web interface). To do this, a clean, well abstracted communication layer must exist.
This is where Jupyter notebook “comms” come into play. The comm API is a symmetric, asynchronous, fire and forget style messaging API. It allows the programmer to send JSON-able blobs between the front-end and the back-end. The comm API hides the complexity of the webserver, ZMQ, and websockets.
Using comms, the widget base layer is designed to keep state in sync. In the kernel, a Widget instance exists. This Widget instance has a corresponding WidgetModel instance in the front-end. The Widget and WidgetModel store the same state. The widget framework ensures both models are kept in sync with eachother. If the WidgetModel is changed in the front-end, the Widget receives the same change in the kernel. Vise versa, if the Widget in the kernel is changed, the WidgetModel in the front-end receives the same change. There is no single source of truth, both models have the same precedence. Although a notebook has the notion of cells, neither Widget or WidgetModel are bound to any single cell.
In order for the user to interact with widgets on a cell by cell basis, the WidgetModels are represented by WidgetViews. Any single WidgetView is bound to a single cell. Multiple WidgetViews can be linked to a single WidgetModel. This is how you can redisplay the same Widget multiple times and it still works. To accomplish this, the widget framework uses Backbone.js. In a traditional MVC framework, the WidgetModel is the (M)odel, and the WidgetView is both the (V)iew and (C)ontroller. Meaning that, the views both display the state of the model and manipulate it. Think about a slider control, it both displays the value and allows the user to change the value by dragging the slide handle.
In [1]:
from ipywidgets import *
from IPython.display import display
w = IntSlider()
display(w, w)
In [2]:
display(w)
The user code required to display a simple FloatSlider widget is:
from ipywidgets import FloatSlider
from IPython.display import display
slider = FloatSlider()
display(slider)
In order to understand how a widget is displayed, one must understand how code is executed in the Notebook. Execution begins in the code cell. A user event triggers the code cell to send an evaluate code message to the kernel, containing all of the code in the code cell. This message is given a GUID, which the front-end associates to the code cell, and remembers it (important).
Once that message is received by the kernel, the kernel immediately sends the front-end an “I’m busy” status message. The kernel then proceeds to execute the code.
When a Widget is constructed in the kernel, the first thing that happens is that a comm is constructed and associated with the widget. When the comm is constructed, it is given a GUID (globally unique identifier). A comm-open message is sent to the front-end, with metadata stating that the comm is a widget comm and what the corresponding WidgetModel class is.
The WidgetModel class is specified by module and name. Require.js is then used to asynchronously load the WidgetModel class. The message triggers a comm to be created in the front-end with same GUID as the back-end. Then, the new comm gets passed into the WidgetManager in the front-end, which creates an instance of the WidgetModel class, linked to the comm. Both the Widget and WidgetModel repurpose the comm GUID as their own.
Asynchronously, the kernel sends an initial state push, containing all of the initial state of the Widget, to the front-end, immediately after the comm-open message. This state message may or may not be received by the time the WidgetModel is constructed. Regardless, the message is cached and gets processed once the WidgetModel has been constructed. The initial state push is what causes the WidgetModel in the front-end to become in sync with the Widget in the kernel.
After the Widget has been constructed, it can be displayed. Calling display(widgetinstance) causes a specially named repr method in the widget to run. This method sends a message to the front-end that tells the front-end to construct and display a widget view. The message is in response to the original code execution message, and the original message’s GUID is stored in the new message’s header. When the front-end receives the message, it uses the original messsage’s GUID to determine what cell the new view should belong to. Then, the view is created, using the WidgetView class specified in the WidgetModel’s state. The same require.js method is used to load the view class. Once the class is loaded, an instance of it is constructed, displayed in the right cell, and registers listeners for changes of the model.
In [3]:
%%javascript
this.model.get('count');
this.model.set('count', 999);
this.touch();
/////////////////////////////////
this.colorpicker = document.createElement('input');
this.colorpicker.setAttribute('type', 'color');
this.el.appendChild(this.colorpicker);
Since widgets exist in both the front-end and kernel, they consist of both Python (if the kernel is IPython) and Javascript code. A boilerplate widget can be seen below:
Python:
from ipywidgets import DOMWidget
from traitlets import Unicode, Int
class MyWidget(DOMWidget):
_view_module = Unicode('mywidget').tag(sync=True)
_view_name = Unicode('MyWidgetView').tag(sync=True)
count = Int().tag(sync=True)
JavaScript:
define(['jupyter-js-widgets'], function(widgets) {
var MyWidgetView = widgets.DOMWidgetView.extend({
render: function() {
MyWidgetView.__super__.render.apply(this, arguments);
this._count_changed();
this.listenTo(this.model, 'change:count', this._count_changed, this);
},
_count_changed: function() {
var old_value = this.model.previous('count');
var new_value = this.model.get('count');
this.el.textContent = String(old_value) + ' -> ' + String(new_value);
}
});
return {
MyWidgetView: MyWidgetView
}
});
Describing the Python:
The base widget classes are DOMWidget and Widget.
_view_module and _view_name are how the front-end knows what view class to construct for the model.
sync=True is what makes the traitlets behave like state.
A similarly named _model_module and _model_name can be used to specify the corresponding WidgetModel.
count is an example of a custom piece of state.
Describing the JavaScript:
The define call asynchronously loads the specified dependencies, and then passes them in as arguments into the callback. Here, the only dependency is the base widget module are loaded.
Custom views inherit from either DOMWidgetView or WidgetView.
Likewise, custom models inherit from WidgetModel.
The render method is what is called to render the view’s contents. If the view is a DOMWidgetView, the .el attribute contains the DOM element that will be displayed on the page.
.listenTo allows the view to listen to properties of the model for changes.
_count_changed is an example of a method that could be used to handle model changes.
this.model is how the corresponding model can be accessed.
this.model.previous will get the previous value of the trait.
this.model.get will get the current value of the trait.
this.model.set followed by this.save_changes(); changes the model. The view method save_changes is needed to associate the changes with the current view, thus associating any response messages with the view’s cell.
The dictionary returned is the public members of the module.
Widget trait attributes tagged with sync=True are synchronized with the JavaScript model instance on the JavaScript side. For this reason, they need to be serialized into json.
By default, basic Python types such as int, float, list and dict are simply be mapped to Number, Array and Object. For more complex types, serializers and de-serializers mustbe specified on both the Python side and the JavaScript side.
In many cases, a custom serialization must be specified for trait attributes. For example
Custom serialization can be specified for a given trait attribute through the to_json and from_json metadata. These must be functions that take two arguments
In most cases, the second argument is not used in the implementation of the serializer.
Example
For example, in the case of the value attribute of the DatePicker widget, the declaration is
value = Datetime(None, allow_none=True).tag(sync=True, to_json=datetime_to_json, from_json=datetime_from_json)
where datetime_to_json(value, widget) and datetime_from_json(value, widget) return or handle json data-structures that are amenable to the front-end.
The case of parent child relationships between widget models
When a widget model holds other widget models, you must use the serializers and deserializers provided in ipywidgets packed into the widget_serialization dictionary.
For example, the HBox widget declares its children attribute in the following fashion:
from .widget import widget_serialization
[...]
children = Tuple().tag(sync=True, **widget_serialization)
The actual result of the serialization of a widget model is a string holding the widget id prefixed with "IPY_MODEL_".
In order to mirror the custom serializer and deserializer of the Python side, symmetric methods must be provided on the JavaScript side.
On the JavaScript side, serializers are specified through the serializers class-level attribute of the widget model.
They are generally specified in the following fashion, extending the dictionary of serializers and serializers of the base class. In the following example, which comes from the DatePicker, the deserializer for the value attribute is specified.
static serializers = _.extend({
value: {
serialize: serialize_datetime,
deserialize: deserialize_datetime
}
}, BaseModel.serializers)
Custom serializers are functions taking two arguments: the value of the object to [de]serialize, and the widget manager. In most cases, the widget manager is actually not used.
The protocol for
Is entirely based upon the Comm section of the Jupyter kernel protocol.
For more details on comms per se, we refer to the relevant section of the specification for the Jupyter kernel protocol.
Jupyter widget libraries built upon ipywidgets tend to have a large part of their code-base in JavaScript, since this is where the logic for drawing and rendering widgets resides. The Python side mostly consists in a declaration of the widget model attributes.
A byproduct of the thin backend of widget libraries is that once the widget protocol is implemented for another kernel, all the widgets and custom widget libraries can be reused in that language.
Therefore, in this documentation, we concentrate on the viewpoint of a kernel author implementing a jupyter widget backend.
jupyter.widget comm targetJupyter interactive widgets define two comm targets
jupyter.widgetjupyter.widget.versionThe first one is the target handling all the widget state synchronization as well as the custom messages. The other target is meant for a version check between the front-end and the backend, and can be ignored from now.
Reception of a comm_open message
Upon reception of the comm_open message for target jupyter.widget
{
'comm_id' : 'u-u-i-d',
'target_name' : 'jupyter.widget',
'data' : {
'widget_class': 'some.string'
}
}
The type of widget to be instanciated is determined with the widget_class string.
In the python implementation, this string is actually the key in a registry of widget types. In the case where the key is not found, it is parsed as a module + class string.
In the Python implementation of the backend, widget types are registered in the dictionary with the register decorator. For example the integral progress bar is registered with register('Jupyter.IntProgress').
Emmission of the comm_open message upon instanciation of a widget
Symmetrically, when instanciating a widget in the backend, a comm_open message is sent to the front-end.
{
'comm_id' : 'u-u-i-d',
'target_name' : 'jupyter.widget',
'data' : {
'[serialized widget state]'
}
}
The type of widget to be instanciated in the front-end is determined by the _model_name, _model_module and _model_module_version keys in the state, which respectively stand for the name of the class that must be instanciated in the frontend, the javascript module where this class is defined, and a semver range for that module.
Sending updates of the state for a widget model
{
'comm_id' : 'u-u-i-d',
'data' : {
'method': 'state',
'state': '[serialized widget state or portion of the serialized widget sate]',
'buffers': '[optional list of keys for attributes sent in the form of binary buffers]'
}
}
Comm messages for state synchonization optionally contain a list binary buffers. If this list is not empty, a corresponding list of strings must be provided in the data message providing the names for these buffers.
The front-end will unpack these buffer and insert them in the state for the specified keys.
Sending custom messages
In the Python implementation, the base widget class provides a means to send raw comm messages directcly. Widget.send(content, buffers=None) will produce a message of the form
{
'comm_id' : 'u-u-i-d',
'data' : {
'method': 'custom',
'content': 'the specified content',
'buffers': 'the provided buffers'
}
}
Receiving data synchronization messages
Up on updates of the JavaScript model state, the front-end emits widget state patches messages
{
'comm_id' : 'u-u-i-d',
'data' : {
'method': 'backbone',
'sync_data': 'the patch to the data',
'buffers': 'optional buffer names list'
}
}
The sync_data contains the serialized state of the changed model attributes in the form of a dictionary.
Optionally, the message may specify a list of buffer names. When provided, the corresponding binary buffers in the zmq message should be appended in the sync_data dictionary with the keys specified in the buffers list.
State requests
In the case of a front-end connecting to a running kernel where widgets have already been instanciated, it may send a request state message, of the form
{
'comm_id' : 'u-u-i-d',
'data' : {
'method': 'request_state'
}
}
The expected response to that message is a regular update message as specified above containining the entirety of the widget model state.
Because the API of any given widget must exist in the kernel, the kernel is the natural place for widgets to be installed. However, kernels, as of now, don’t host static assets. Instead, static assets are hosted by the webserver, which is the entity that sits between the kernel and the front-end. This is a problem, because it means widgets have components that need to be installed both in the webserver and the kernel. The kernel components are easy to install, because you can rely on the language’s built in tools. The static assets for the webserver complicate things, because an extra step is required to let the webserver know where the assets are.
In the case of the classic Jupyter notebook, static assets are made available to the Jupyter notebook in the form of a Jupyter extensions. JavaScript bundles are copied in a directory accessible through the nbextensions/ handler. Nbextensions also have a mechanism for running your code on page load. This can be set using the install-nbextension command.
A template project is available in the form of a cookie cutter: https://github.com/jupyter/widget-cookiecutter
This project is meant to help custom widget authors get started with the packaging and the distribution of Jupyter interactive widgets.
It produces a project for a Jupyter interactive widget library following the current best practices for using interactive widgets. An implementation for a placeholder "Hello World" widget is provided.