Auto-display value of cells that define a single variable?

[yurivish]

Something I really liked about the original Observable Notebook is that if you define a named variable, you can see its value right away.

If you say x = f(), then the value of x is displayed above the code. This is very useful while exploring, since you can define variables as you go and see automatic "visualizations" (inspectors, usually) of these intermediate results.

I really like the new semantics of Notebooks 2.0 and greatly appreciate that it's so close to regular JavaScript. But I've found myself missing this auto-display behavior, since to recover it I have to add an extra step to my workflow of explicitly thinking about emitting a value to look at, usually by wrapping the code in display, or, if it's a promise, adding .then(display), or repeating the name of the variable in a new cell below it.

Would it be possible to detect when a cell makes a single variable definition and, if it does, to display that value as the view for the cell? I don't understand the deeper parts of the new system yet so it's possible this interferes with some deep principle in the way things compose, but right now it feels like there's an opportunity to add back some "auto-display" behavior to regain the "visualization by default" feeling of the original notebooks in this case of exploratory step-by-step programming, which gave you automatic inspector views for intermediate named results.

[mbostock]

Thanks for the feedback, Yuri. This resonates with me.

I have been thinking about this as an “inspector” display for a cell; this inspector would display the exposed values of all top-level variables in the cell. It would not special-case cells that define a single top-level variable. I love that in Notebooks 2.0 you can define multiple top-level variables in a single cell (often related), and I wouldn’t want to create an incentive to split a cell just to get the implicit display. You might also want the inspector for cells that call display (or view) explicitly so that you can inspect the exposed values alongside anything displayed. And probably the inspector mode should always use the inspector for DOM content, e.g. showing HTMLDivElement instead of adding the content to the page.

It shouldn’t be technically hard to implement this, but I have design questions.

Is the inspector only supported for JavaScript cells? I think so, because only JavaScript cells can (currently) expose multiple top-level variables. But other cells (notably SQL) can expose a single value using the new output attribute. And Observable JavaScript cells if they are import cells.

Would this inspector subsume the current implicit display for expression cells? Probably? So that means the hidden attribute would turn off the inspector? But implicit display must insert DOM content into the page, not inspect it.

Should the inspector be on by default? If so, would that lead to more “messy” notebooks and bad performance when notebooks are shared? Perhaps the inspector logic should be tied to whether or not the cell is pinned? Should this change affect existing notebooks? Or should Observable Desktop create new cells with an inspect attribute by default?

Should the inspector be a feature of the editor rather than the renderer? I.e., should this be a feature of Observable Desktop rather than Notebook Kit? Would it be better if Desktop could show you the value of top-level variables by hovering the variable? Or if there were some other UI for inspecting the values of a notebook, like the minimap? It’s often nice that the inspector and the code live adjacent, but sometimes it’s also nice to see everything that is defined in the notebook, and to be able to click to jump to definition.

[yurivish]

That's amazing to hear! I really like the direction you're thinking in. I've been keeping all of my requests intentionally somewhat conservative but am very happy that you're taking this opportunity to revisit some fundamental design choices.

I'll think about those directions and whether I might have anything helpful to say... Some quick thoughts below (apologies for rambling)

(edit 2: sorry, this turned out even more rambly than intended; let me know if too much and I can distill it all down tomorrow):

Is the inspector only supported for JavaScript cells?

It would be really cool if one could define custom cell modes as JS template literals -- then I'd definitely want the ability to define multiple values from a single cell (eg. my Clojure experiments from earlier could be a "Clojure" mode that defines multiple variables, each inspectable. Though maybe they'd just be combined into just one JS value by the literal... )

Should the inspector be a feature of the editor rather than the renderer?

One quick thought is, based on my earlier uses of Observable when I was blurring the lines between notebook and app, it was

1. very useful to have DOM elements slotted in to a document rendered outside of observable
2. for app-like notebooks, it was almost never useful to have inspectors when rendered outside -- I came up with some design patterns to make sure those elements were hidden or at least below the fold. As an example, the app described here (towards the end; scroll down until you see screenshots) consisted entirely of ~10 notebooks and was deployed internally at what was then Twitter, pulling data from internal data sources that were updating daily. I think there's a flow to be had where you can prototype in a notebook and then actually also deploy the notebook -- and potentially this is much more straightforward in the "notebook = file" model.

This suggests making inspectors something provided by the editor, so long as there's a way to easily render inspector in a rendered context when you do want it (maybe w/ display? one can always import and use the underlying library but it might be nice if there was a concise answer for how to do this).

Separately, vertical space is valuable and it'd be nice to be able to omit certain variables from being displayed. I think right now Notebooks 2.0 and Mathematica both use a semicolon to "silence" an expression. Not sure how that interacts with code auto-formatting though.

---

• Or if there were some other UI for inspecting the values of a notebook, like the minimap?

  • I really like and already miss the minimap! My notebooks tend to grow, and then it's hard to find stuff. Also, the cell-local find mode is nice but I don't know how to "jump to" a definition since it seems global "find" is currently disabled. (Maybe there could be something like Sublime's popover thingy to jump to a symbol definition?)
  • Seeing a minimap with a little preview of the values would be cool, though I am not immediately sure how useful it would be since I often navigate by name or dependency structure -- though I'd be interested to try it. Might be very useful as an "overview" for the notebook, separate from navigating around it.

• It’s often nice that the inspector and the code live adjacent, but sometimes it’s also nice to see everything that is defined in the notebook, and to be able to click to jump to definition. 👍

---

Random thought: it could be fun to see either a grid of cells with name/preview, or something like Mac's Exposé (https://github.com/user-attachments/assets/6612a303-c147-4cdb-93d0-f939999bd169) as a way to see an overview... But most of the things I'm actually missing right now are tools for better navigation/editing, eg. the dependency minimap, and I'd love it if you could cmd+click a variable to jump to its definition (eg. underline the text when you press cmd+hover, then click treats it conceptually as a hyperlink to the definition). Zed does this and I have a shortcut in Sublime Text to do it and it's awesome - and would be v. cool if it worked across notebooks and editors.