🏠 back to Observable

Reusability Improvements


I have the following 2 reusability improvement ideas.

  1. Automatically override cell values from query string
  2. Automatically create functions from cell blocks

I know they may sound utopian, but I think they will be a good addition for the platform.

See the notebook for details:


Hi David, thanks for the feedback!

We can’t implement the first one for security reasons: it would allow someone to inject code (through the URL) that runs on your domain. For this reason we think the best approach is to make parameters explicit, as shown here:

As in:

params = new URLSearchParams(new URL(document.baseURI).search)

Your second suggestion is very interesting. We’ve considered a few approaches to parameterizing cells in the past, like import-with but within a notebook. I like the idea of cells-as-functions, though there are some details to work out so it’ll require further thought.


For the first one , I was just thinking about simple cell values - string, boolean, number , I think it’ll be pretty easy to sanitize. I don’t know if this still will pose security issues, I haven’t thought about security regarding this matter at all.

For the second one - Yeah, agree , It’ll require more thinking , but I hope this feature(or similar, which allows parameterized cells) will end up implemented in Observable in future


Personally I’d prefer an stdlib helper over something that can screw up any named cell and gives me no chance for further sanitization.

Since cells are already functions, perhaps a keyword similar to mutable and viewof could be introduced to get a reference to the cell’s outer function?


Unfortunately it’s not enough to just restrict the input types. Imagine you have a notebook that’s like

enforceAccess = true

And then someone can override that by setting ?enforceAccess=false in the URL. You would lessen the attack surface by restricting what values could be set by URL, but you could still change the behavior of a notebook in unexpected ways. (And, as Fabian points out, if this override happens at the platform layer it doesn’t give the author an opportunity to control what happens.)


Yep, exposing the cell’s definition function as functionof foo or something might be possible. The challenge is that you’d have to supply everything that foo references, which is a little brittle and perhaps non-obvious with larger cells; it’d be more robust if you could explicitly tell it which parameters you want to specify and left the others as implicit. Like:

k = 5
x = 8
y = 10 * k * x + 11

Then maybe:

functionof y({x: 42}) // k = 5 is implicit

(Just a sketch; don’t get attached to the syntax!)