Separate the front-end visualization and back-end data generation for visualization from the web server

[smacleod]

It would be nice to refactor both the front-end javascript and the back-end rendering code of a VisualizationElement, so that they aren't coupled as tightly to the Tornado server setup and its template.

Motivation

The motivation for this issue is to allow the front-end visualizations written in javascript to be used in situations where the webserver is not needed (or wanted). Examples would include the inside of a Jupyter notebook output cell, or a static HTML page where the data for a model run could be saved statically and replayed.

Current Code

Currently the javascript visualization code makes assumptions about the template it is loaded into, injecting into the body tag. Some of the visualizations also send along canvas commands, rather than data which should be left to the javascript to make use of.

Each individual visualization also uses a js_code property to specify initialization code, which must deal with specifying arguments itself.

Proposed Changes

• Make each visualization generate an element which can be injected into any container at the discretion of the caller. This will allow consumers like a jupyter notebook extension to inject into output cells.
• Replace js_code with an initialization function name e.g. ChartModule, and always pass a provided dictionary as the single argument containing any of the options. This will ensure new modules are written in a way which doesn't make assumptions about the type of front-end environment it will be run in and also allows the tornado webserver or notebook extension to change options as needed (possibly change dimensions?).

[dmasad]

I'm definitely in favor of the motivation and concept. Two questions:

1. It seems that right now the websocket connection chokes and slows down if the JSON data being passed is too big; wouldn't that get even worse if we're sending entire serialized HTML elements?
2. One of the strengths of the current system is that it can use third-party JavaScript charting tools (e.g. Charts.js). Is that still possible under this change?

One interim solution is not to refactor the ModualServer architecture, but to create a parallel visualization architecture that does this.

[smacleod]

To answer your questions:

1. I'm not actually proposing that any of the data being sent over the websocket needs to change, the JS side will still deal with generating the markup / updating the visualization. I might have been making some assumptions about what data was being sent before, but this change doesn't need to modify that at all.
2. Yup, that should all still work!

I've hacked together a Visualizer class which can use the current VisualizationElements as is to inject them into the notebook and render using JS. The only change I needed to make to them was having the JS inject the canvas elements into a specific div I create, rather than the body. This can all be fixed though by the refactoring I layout here, and will only require a small update to the ModualServer template.