Allowing export in JS cells

[yurivish]

Edit: I suppose I could just use an IIFE and that might be a clearer expression of the same idea... 💡. Closing!

I've been working with some increasingly sophisticated notebooks and had a random idea for a way to make reasoning about them a little bit simpler. The basic idea is to add support for the export keyword in a cell to restrict which variables are accessible from outside the cell.

Background

With the ability for a cell to define multiple values, I'm noticing myself co-locating a variable or function with its supporting variables or functions.

For example:

function inner() { ... }
function outer() { inner(...) }

where the outer function is referenced from outside the cell, but inner is not.

Or

const res = await fetch(...)
const raw = await res.json()
const computed = raw.filter(d => d.type == 'input')

where computed is used outside of this cell, but res and raw are not.

The idea

Right now, all of the variables defined inside of a cell are accessible from the outside, but I'm wondering if it could make sense to allow specifying certain variables as exported to restrict a cell to exposing only those variables as outside references.

This would ease the understanding of complex notebooks (since you can tell which values are or aren't exported) and would also ease the path towards abstracting a cell into an externally-imported JavaScript file since you can centralize the library-to-be in a cell before moving the code to a file.

With this proposal, the code above would look like

function inner() { ... }
export function outer() { inner(...) }

and

const res = await fetch(...)
const raw = await res.json()
export const computed = raw.filter(d => d.type === 'input')

With the above, only the outer and computed variables would be accessible outside of their defining cell.

In a cell with no explicit exports, all variables would be treated as exported.

Downsides

One downside of this proposal would be that it is no longer obvious by looking purely at a variable definition whether or not that variable is accessible from other cells. I don't know if this would be a problem in practice, and if it is then one way to potentially address it would be to use syntax coloring to show the "cell-private" names differently from the exported names.

I'm not sure if this one is an upside or a downside, but this idea feels strongly linked to a compilation strategy that treats each cell as an independent JS module.

[mbostock]

Glad you found an acceptable alternative. Another way you can hide variables from other cells is to use a block statement to make them local (non-top-level) variables; however, this can prevent you from using const for top-level variables. For example:

let outer;
{
  function inner() { ... }
  outer = function outer() { inner(...) };
}

I’ve been thinking export might be useful once we support notebook imports again in Notebooks 2.0; perhaps we’ll want to be more explicit about what’s importable from another notebook (just like we use export for vanilla modules).

[yurivish]

Thanks!