🏠 back to Observable

Reusability Improvements


#1

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:


#2

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.


#3

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


#4

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?


#5

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.)


#6

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!)