I think it would be cool to be able to get and modify the text content of cells in response to user actions.
This feature would allow custom userspace find and replace commands, userspace jump to/lookup definition, etc., solving most of the problems brought up in Feedback after making a very large notebook. A user could keep commands like these in an “editor” notebook for easy access. Advanced users could define more involved refactoring tools.
The ability to write out objects that automatically talk with the objects around them is a lot more powerful than that, though. I’m not sure what shape that would take in the context of an Observable notebook. I understand why your team doesn’t want the user to modify the layout and format of the notebook, and I think that’s smart. I’d be very curious to see what an API under those constraints would enable.
A full API might also include (read-only) access to the dependency graph so there’s a single source of truth when a user wants to write his own visualization of that. (Including the graph’s cell in the graph sounds like a fun problem.)
Of course this project is still young and this is asking for a lot of stuff which is not a part of the spec. But I would be interested in your thoughts.
Very cool ideas, let me respond to them one-by-one because there’s a lot here:
I think it would be cool to be able to get and modify the text content of cells in response to user actions.
Yep, we’ve been kicking around the idea of an operator like viewof or mutable that would allow access to individual cell definitions. I think implementing it right now would be kind of cart-before-horse: Observable notebooks are, as you’ve probably noted, written in a dialect of JavaScript that doesn’t parse in Acorn, Babylon, or any of the currently-available parsers. So launching a feature that allows access to that code wouldn’t be super useful - instead of getting the full power of reflection you’d instead basically have an opaque string, which would be a bummer. We’re actively working on modularizing/documenting/releasing the parts that would make those strings usable, and then the feature would start to make sense.
This feature would allow custom userspace find and replace commands, userspace jump to/lookup definition, etc., solving most of the problems brought up in Feedback after making a very large notebook.
Possibly, but
Find, replace, jump to definition - these will all be implemented as part of the main product, as first-class maintained features. They shouldn’t need to be implemented in userspace.
Implementing these things in userspace would require user scripts access to the top frame (to the code editor and other parts of the editing UI), which we specifically disallow, because that’s where the security implications arise. Observable is architected as two spaces: the top frame, which is locked-down with CSP rules and such and has only very limited user content, and the notebook iframe, which is completely under user control.
A full API might also include (read-only) access to the dependency graph so there’s a single source of truth when a user wants to write his own visualization of that.
This is probably the first part that will launch! Mike’s super hyped on visualizing this graph, and we really want to make that kind of visualization easily accessible to everyone (also also part of the default notebook API, though hopefully in a format that isn’t graphviz )
reflection