seems like window.eval is required to execute in the global/window scope.

Given that this app uses react + redux, and the stored state of the app is fundamentally just a big json object, we can save this in local storage so that this early-stage app can persist for a particular user.

As a starting point, let's simply make a big 'save' button to save the state to local storage. I attempted to save the state to local storage with each state change (which happens with every cell edit right now) and that made the app a little fussy.

We can use #16 to capture the name of the notebook, which can be saved w/ a simple, serialized key-value pair.

Allowing there to be some small state-saving in the title component actually makes it harder to update the title from the main redux state object.

for parity with jupyter, we should wrap both the input and output from each cell in a div that is clickable without entering edit mode (in jupyter you can click to the left of the edit box to select a cell while in command mode). a click target like this is useful for editing/deleting/adding/moving cells.

We need to have a markdown cell type that renders the text into - you guessed it - markdown.

We can integrate marked.

Should we figure out a way of integrating advanced text editing shortcuts that come with codemirror?

for example, sublime text keybindings are available
http://codemirror.net/demo/sublime.html

(more narrowly, i noticed this because i tried to use Ctrl-/ to comment out a line and noticed missing that)

Given that we're using redux, and have the entire state saved, we can very easily move back and forth between states - that is, we can implement forward / backward state buttons.

We need a DOMCell, which allows you to simply have a cell displayed as an active DOM element. It needs the following options:

• id, which allows for css selection.
• element type, such as div, svg, canvas, etc
• some way of saving the last render state of the enclosed dom element, which will make translating to a static report easier in many cases.

We want to maintain a running list of chunks of code that are executed. Cell execution and external script additions should be appended to this list.

want the cell that was being edited to be selected when returning to command mode

we should come up with a way of truncating/hiding very long outputs

discovered this while doing

targetDiv2 = document.body.querySelector("#targetDiv2")
p = document.createElement("p");
p.innerHTML = "a paragraph";
targetDiv2.appendChild(p)

two paragraphs upon during ctrl+enter, only when when pressing the play button

("#targetDiv2" defined in a markdown cell)

These should live in an exampleNotebooks.jsx type file, but can simply be json files read by the bundle.

As discussed, we want a cell type for loading external scripts. In terms of UI, the proposal at this point is to have an input in which you can list URLs for external scripts to be loaded, and upon execution of the cell, the scripts will be added to the document head. This should also update the execution history list (see #46)

I put together an mvp cell design to simply get all the underlying logic in-place. Ultimately getting the actual result displays looking closer to a well-formulated document (like RMarkdown) is the goal. Will update this list w/ more points as I tweak / commit.

• move buttons to right of cell
• tweak the CodeMirror instances for cleanup
• keep buttons invisible until cell hover

The aim of a serverless notebook is to create a client-based computational "kernel" that can live in the browser. This removes the need for a server to do the heavy lifting. Removing the server opens the door for a truly portable (thus reproducible) scientific computing environment.

There are many challenges with this approach, but from a low-level / technical point of view, one very important challenge will be how to manipulate the dom from the kernel layer.

as of this filing, we have no great way to make sure the scope feels consistent. Using var in a cell block, for instance, will not perpetuate across cells, because the declaration will be made within the scope of the Function call. So var b = 10 will not make b available to all cells, whereas b=10 will. This seems like merely a nuisance, but this issue will track all discussion re: how we want to approach scope in case others have strong opinions.

maybe this is something as simple as firing the SELECT_CELL action on mousedown rather than mouseclick, i have no idea...

"a" seems to insert below, "b" seems to insert above

At the moment we're just putting the js-interpreter properties out there but it's not particularly usable or useful. This needs to be wrapped in some functional language to pull out before it even hits that component.

they overflow past the window width when i shrink my browser to take up half the screen

This is now necessary for #19 to be resolved.

This includes the requisite action, reducer, and UI element. The first two will be reusable across the app in other ways, while the UI piece will likely change.

i attempted to put in a tiny bit of error help with a simple try/catch that writes some error info to a string, but maybe the lib used to display other outputs can be extended to handle error objects.

We need to implement jupyter-style keybindings for:

• entering / exiting command mode (lifted directly from jupyter)
• selecting the next / previous cell
• moving a selected cell up and down
• adding / inserting a cell
• deleting a cell
• running a cell
• switching between cell types

Given that these are Page-specific, we can implement the keybindings in that component.

Eventually we want to address the compute kernel issue, but for the sake of expediency (and easy DOM manipulation #13) we're going to keep everything tractable so we can begin showing others a demo version. This requires removing js-interpreter (already considered a stopgap) with Function, which gives us the app's scope.

problem: breaks function declaration, see #34

confused myself for a few minutes trying to return Math.pi ... of course, that should be Math.PI. In the browser console, that returns shows "undefined". Might be hard to capture, but maybe we can give similar feedback

Our demo version (for now) keeps everything saved / stored in the current thread. So when we switch notebooks, we still have the global namespace of whatever has been run so far.

Really, this is a deeper question about WHERE notebooks live, WHAT a notebook represents, and HOW we manage state.

For a demo, this won't be an issue. But we will need to eventually come to some major decisions.

For the demo notebooks will be saved in local storage. Build some functionality to recall them. Relies on #3

hmmm, this is a big problem.

with the following cells:
%% function add(a,b){return a+b) return add(1,2) %% add(3,4) %%

from the first cell, you correctly get 3; but from the second cell, there is no output, and the console reports "ReferenceError: add is not defined".

So crapola, the scoping issues involved in executing code with Function are getting us. Gonna play with a branch using vanilla eval, which may operate differently wrt scope-- https://stackoverflow.com/questions/4599857/are-eval-and-new-function-the-same-thing

A cell is selected if it is clicked, or currently being edited. This allows us to supply keybindings for running a cell, moving a cell, adding / deleting, and inserting a cell before or after the selected.

This should be as easy as providing an action called SELECT_CELL which takes the cellID.