Anyway to get all cells' names on a notebook?

I am confused about how Observable works…, especially how a cell’s name is linked to the script file (I guess by the data-node-id, but the fact that there is autofill for cell names seems to indicate that all cells’ names are store somewhere as a list or something)

Is there a way to access this ‘list’ in a cell?

From within an Observable notebook (ie the code that you write), I don’t think there’s a way to access a “list” of cells that are in scope.

But the runtime itself does store that, since the runtime handles cell evaluation and the computation tree. If you had direct access to the “module” of a notebook, you could do something like:

const main = runtime.module();

main.variable().define("a", 1);
main.variable().define("b", 2);
main.variable().define("c", ["a", "b"], (a, b) => a + b);

console.log(Array.from(main._scope.keys())) // ["a", "b", "c"]

Here’s this in action.

But, you don’t have access to a notebook’s runtime from within the notebook itself. The autocomplete works in because the notebook editor has access to the runtime (I assume), but your code that you write does not. If you embed the notebook elsewhere, then you have more control, but not in the typical notebook at

Overall I recommend How Observable Runs to learn more about how the runtime/notebook cells work!

Thanks a lot!
I have spent quite some time trying to get access to the ‘list’ :joy: seems that I have to change my approach

There is no officially-supported way, but you can get access to the notebook module from within the notebook with a kind of hack; see @mootari’s notebook for a demo:


Thanks a lot! I am going to check it out now :slight_smile:

Does anyone know the thinking behind not providing module/runtime access from within a notebook (security issues perhaps) ? Seeing as access is already available, via hacks like @mootari 's, it would be really nice if there was a clean way to do this…

@dhowe That would require providing official support, and would hinder changes to the internals. Same reason there’s no official API.

Seeing as access is already available

Take that statement with truckloads of salt. “Available” is definitely not the right choice of words here, given the nature of the hack, and its various gotchas.

1 Like

This was (less than clearly) in relation to the question about security – that is, if the reason was security, then…

I don’t think that security is a concern, since the notebook iframe is sandboxed and (with some minor exceptions like reporting content height, extracting the title and generating cell downloads) cannot affect the parent frame.

If people were to mess with the Runtime instance it could cause all sorts of stability issues which would be hard to trace, but would still be reported as bugs to the team. Therefore granting direct access to the Runtime would not really be an option.

Exposing this information will require careful planning of the appropriate API, and analysis of the potential side effects for different environments, like embeds. If you want to voice your demand for such a feature, I suggest you open a feature request on Issues · observablehq/feedback · GitHub.