A JupyterLab architecture walkthrough from June 16, 2016, provides an overview of the notebook architecture.
The most complicated plugin included in the JupyterLab application is the Notebook plugin.
Structure of the Notebook plugin¶
The Notebook plugin provides a model and widgets for dealing with notebook files.
The NotebookModel contains an observable list of cells.
A cell model can be:
- a code cell
- a markdown cell
- raw cell
A code cell contains a list of output models. The list of cells and the list of outputs can be observed for changes.
The NotebookModel cell list supports single-step operations such as moving, adding, or deleting cells. Compound cell list operations, such as undo/redo, are also supported by the NotebookModel. Right now, undo/redo is only supported on cells and is not supported on notebook attributes, such as notebook metadata. Currently, undo/redo for individual cell input content is supported by the CodeMirror editor’s undo feature. (Note: CodeMirror editor’s undo does not cover cell metadata changes.)
After the NotebookModel is created, the NotebookWidgetFactory constructs a new NotebookPanel from the model. The NotebookPanel widget is added to the DockPanel. The NotebookPanel contains:
The NotebookPanel also adds completion logic.
The NotebookToolbar maintains a list of widgets to add to the toolbar. The Notebook widget contains the rendering of the notebook and handles most of the interaction logic with the notebook itself (such as keeping track of interactions such as selected and active cells and also the current edit/command mode).
The NotebookModel cell list provides ways to do fine-grained changes to the cell list.
Higher level actions using NotebookActions¶
Higher-level actions are contained in the NotebookActions namespace, which has functions, when given a notebook widget, to run a cell and select the next cell, merge or split cells at the cursor, delete selected cells, etc.
A Notebook widget contains a list of cell widgets, corresponding to the cell models in its cell list.
- Each cell widget contains an
- which contains n
- which contains n CodeEditorWrapper,
also contains an
An OutputArea is responsible for rendering the outputs in the
list. An OutputArea uses a notebook-specific
object to render
display_data output messages.
The cells are rendered based on a Virtual Notebook logic. A minimun number of cells will be rendered directly, then an intersection observer will render any cells being in the observed area (default is the complete notebook panel), and then any other non-rendered cells will be rendered when the browser is idle. This ensure that the user has access to cells as soon as possible. This is particulary useful for large notebooks.
Rendering output messages¶
A Rendermime plugin provides a pluggable system for rendering output messages. Default renderers are provided for markdown, html, images, text, etc. Extensions can register renderers to be used across the entire application by registering a handler and mimetype in the rendermime registry. When a notebook is created, it copies the global Rendermime singleton so that notebook-specific renderers can be added. The ipywidgets widget manager is an example of an extension that adds a notebook-specific renderer, since rendering a widget depends on notebook-specific widget state.
How to extend the Notebook plugin¶
We’ll walk through two notebook extensions:
- adding a button to the toolbar
- adding an ipywidgets extension
The ipywidgets third party extension¶
This discussion will be a bit confusing since we’ve been using the term widget to refer to lumino widgets. In the discussion below, ipython widgets will be referred to as ipywidgets. There is no intrinsic relation between lumino widgets and ipython widgets.
The ipywidgets extension registers a factory for a notebook widget
extension using the Document
createNew() function is called with a NotebookPanel and
The plugin then creates a ipywidget manager (which uses the context to
interact the kernel and kernel’s comm manager). The plugin then
registers an ipywidget renderer with the notebook instance’s rendermime
(which is specific to that particular notebook).
When an ipywidget model is created in the kernel, a comm message is sent
to the browser and handled by the ipywidget manager to create a
browser-side ipywidget model. When the model is displayed in the kernel,
display_data output is sent to the browser with the ipywidget
model id. The renderer registered in that notebook’s rendermime is asked
to render the output. The renderer asks the ipywidget manager instance
The renderer creates a container lumino widget which it hands back
synchronously to the OutputArea, and then fills the container with the
rendered ipywidget when the promise resolves.
Note: The ipywidgets third party extension has not yet been released.