###################################################### Ashley Davis and I are moving our conversation from email to this issue concerning the implementation of Dark-Light Mode Styling with DataForge Notebook (DFN) The below email is from Ash to Me for contextual purposes (see below) ###################################################### (Email from Ash to me...)

I thought of something you might like to help with on DFN.

I'd love to get darkmode working.

Simple part will be to enable dark theme on Blueprintjs.

The harder part will be to make all the plugins (which don't use Blueprintjs) look nice in dark mode.

You can learn about Blueprint js here: https://blueprintjs.com/

If you are interested, open an issue on the DFN repo called "Dark mode" where we can discuss the implementation:

https://github.com/data-forge-notebook/editor-core

Cheers Ash

###################################################### Disclaimer: ###################################################### For the record, this will be my first open-source contribution

I couldn't be any happier than contributing to the DataForgeNotebook (DFN) project!

This is a "kick the bucket" event in my life.

A little brown-nosing but I think it's cool how Ash is bringing DataScience to the JavaScript community.

The JavaScript-DataScience community NEEDS DataForge Notebook!

AGAIN... I've never done this before, so I'm eager to get started.

###################################################### Quick STAR method map of feature implementation.. ######################################################

Situation: DFN currently doesn't have a Dark-and-Light-Mode-Theme (D&LMT) feature Task: Implement D&LMT feature into DFN with either existing or new CSS architecture Action:

• Discovery: Learn about current project CSS architecture, 3rd party components like blueprintjs, etc. & other plugins styling...
• Questions: Has this been done before? How'd they do it?
• Brainstorm: Find & compare potential CSS styling solutions that will support the on-going development of DFN
• Fork: Implement an agreed upon CSS styling architecture
• Pull request: Merge our Fork into Master Result: We successfully implemented Dark-and-Light-Theme (D&LMT) feature throughout the DFN component tree

###################################################### A few different possible solutions that come to mind... ###################################################### Context provider wrapper around the root component that passes state to sub-components to change styling when button toggled

TailwindCSS Dark Mode pseudo class i.e. dark:text-black-100 or classic classes i.e. .darkmode {color: black}, .lightmode{color: white} or SASS (it's my understanding that blueprintjs uses SASS for their component styling..) .block-element-modifier {color: $pt-dark-icon-color} https://blueprintjs.com/docs/#core/variables.dark-theme-styles or styled-components div(blueprintjs)${props => props.dark && css background: white; color: black; } or

###################################################### Blueprintjs Components & Styling ###################################################### Resource: https://blueprintjs.com/docs/#core/variables.dark-theme-styles

It looks as though Blueprintjs uses SASS styling to style their components

###################################################### Closing thoughts and feature discussion kickoff ######################################################

This is the beginning of what's to come! I'm excited to start. There are SO many ways to implement this. The floor is open to discussion. I'm an open-book. Officially submitting this issue!

Cheers, Josh

Data-Forge Notebook is designed to evaluate code.

In DFN v1 code was evaluated in a separate Node.js process that was spun up by the main process. One evaluation engine was started per notebook the user has open in the editor, allowing multiple notebooks to be evaluated simultaneously. The main process and evaluation engine maintain bidirectional communication using node-ipc. Whenever the evaluation engine has output or results to report it would send them directly to the main process and they would be routed back to the particular notebook editor running the evaluation.

The evaluation engine should change in DFN v2. Under the hood it will basically do the same thing: assembly a JavaScript or TypeScript file from a notebook's data, run the code and the report the results back to the notebook editor for display to the user.

However in v2 I'd like to make the following changes:

• The evaluation engine should use HTTP as it's communication protocol instead of node-ipc.
  • This makes it easier to implement DFN over the web (running the evaluation engine in the backend).
  • It also makes it easier to replace the evaluation engine with pluggable languages, for example a replacement evaluation engineer could be written in Python allowing DFN to execute Python code. Given that the display format for DFN is general purpose JSON, any language that can produce JSON could be used.
  • Bi directional communication will no longer work, therefore the client will have to poll the evaluation engine (using HTTP GET requests) to pick up current status (evaluating/not evaluating) and any outputs that have been generated since the last poll. This method isn't ideal but it is does work for both online DFN and desktop DFN and allows the evaluation engine to break it's dependency to node-ipc allowing it to be implemented for other languages.

Data-Forge Notebook is designed to run on multiple platforms.

To support this the main body of code for the notebook editor is designed to be included as a library to be used in other projects that customize it to the needs of particular platforms.

For example DFN can be rendered in the browser or it can be rendered in Electron on various operating systems. So the way DFN handles "files" must be different in various circumstances.

This code repository is intended to be a code library to be included in other projects to create a full "build" of DFN. Other projects will create a DFN "shell" to house the notebook editor. The shell project will typically provide configuration and dependency injected services to customise the workings of the editor code.

The following "shell" projects are planned for the release of DFN v2:

• DFN Online (implements the Online version of DFN that will rely on the editor-core and evaluation-engine).
• DFN Desktop (the official cross platform Electron implememtation of DVN v2)
• Storybook (It might be nice to remove Storybook from editor-core to it's own "shell" repo to clean up the editor-core repo).

At this stage though the editor-code is a project unto itself that has not yet been included in any shell project.

So the main question at the moment is how will editor-core be included in a shell project?

Here are some options on how that might be achieved:

• Editor-core is included in each "shell" project via a meta repo.
• It is shared by being a package shared through npm.
  • This might work well if the editor-core is a mono repo itself that contains all the packages that are planned (model, evaluation engine, etc)

These are notes on "pluggable visualizations" (cell outputs) that will be added to DFN v2.

Work on this is in progress and partially complete.

Core plugins can be found under the plugins directory in the mono repo.

• A visualization plugin is a simple web page hosted in DFN via an iframe. Anyone who can make a static web page can upgrade DFN v2 with custom visualisation capabilities.
• DFN automatically chooses a particular plugin by matching data against a set or rules. The data to be rendered by the plugin is passed to the display function.
• A user can then override the automatic plugin selection and choose a different visualization plugin.
• DFN controls what the plugin displays by sending it a JSON file that contains configuration and data to initialise the plugin.
• There will be a sequence of messages (a handshake) to initialise a plugin (this is yet to be spec'd out).
• There will also be communication between DFN and the plugin where one side wants to inform the other of an event (e.g. DFN informing the plugin that the window size has changed).
• It is my hope that all current output components in DFN v1 will be rewritten using the new plugin system.
• A dependency injected PluginRepo is responsible for providing the PluggableVisualization UI component with a plugin to render. That way the rules of how plugins are found can be provided differently depending on the environment (e.g. browser or Electron).
• PluginRepo should be able to hand PluggableVisualization a URL for a plugin (which could be file:// for the Electron build) or it can give it the plugin content directly (allowing plugins to be embedded directly in the Electron build).
• In the current implementation plugins can be loaded from URL (allowing local plugins to be loaded) or inline (HTML for plugins are compiled into the bundle).
• DFN needs to provide a UI for choosing a plugin (output will go to the default, but the user can choose any output plugin they like) and configuring a plugin (a simple settings UI). A plugin must be able to expose the settings it supports and their data types to allow them to be edits. Plugin settings should be stored in the notebook for each cell output.
• It is also possible that each plugin might want to allow itself to be visually configured in the plugin UI. For this to happen there needs to be a way to communicate edited settings from the plugin to the "visualization host" (eg DFN) so they can be saved against the notebook.

Long term

• Want some kind of "plugin registry" that allows other people to more easily contribute viz plugins.
• Want a "plugin playground" that's a way to search for and play with configuration for viz plugins.

Prototype code

• There is a prototype here showing how a user pluggable visualization can be embedded in an iframe:
  • https://github.com/data-forge-notebook/pluggable-output-prototype
• Here is the first official plugin (for visualizing structured JavaScript data):
  • https://github.com/data-forge-notebook/output-plugin-structured-data
• The editor-core repository shows an example of this plugin in action to visualization a small set of JavaScript data:
  • https://github.com/data-forge-notebook/editor-core/
• The core plugins are now included in the editor-core mono-repo. This means a plugin registry is not needed in the early days of v2.

Backward compatibility

• The old method of having displayType and data for each cell output still works. Although I'd like to to factor displayType out to displayType and dataType. So data type could be array and display type could be table.
• Old notebooks still need to work. This means functions like display.plot must still work. Plugins should be able to register functions on the display method. This means that plugins need some kind of queryable API that's independent of he visualization. How will this be structured?
  • I could potentially polyfill the old methods using an npm installed library.

Open questions

• How will DFN determine which plugin to use for a particular data blog? Ideally the plugin itself would publish some code to determine if it is appropriate for a particular data blob.
• How will DFN know which plugins are available/published? (Maybe some kind of manifest file?)

Todo

• Create a plugin authors guide.
• Create a template plugin.