Here’s a dilemma I encountered while making a little sketch today:
Suppose you want to make an interactive SVG sketch, in which you can drag a number of dots around, and then perform additional operations on the coordinates of these dots. So, we have the data: interactive SVG sketch svg
, and dot coordinates a
, b
, c
. There are a number of ways to doing this ‘Observable-style’ (instead of putting everything in a single big cell):
-
Make cells for
a
,b
andc
, and then letsvg
depend on these. We won’t be able to updatea
,b
andc
from withinsvg
though. -
Make
a
,b
andc
mutable
, so that we can update them from withinsvg
. This is good, except that if you want to make all nodes draggable with a single call to sayd3.drag().on("drag", ondrag)
, then you can’t really choose dynamically which of the mutables to update, because of the syntacticality of the semantics ofmutable
. The best you can do is something like:function ondrag (d) { switch (d.key) { // check which point we're dealing with case 'a': mutable a = ...; break; case 'b': mutable b = ...; break; ... } }
-
So, we would have to combine the cells in a single
mutable
, saymutable abc = {a: ..., b: ..., c: ... }
, and then we can write something likefunction ondrag (d) { const data = mutable data; data[d.key] = ...; mutable abc = data; }
This is actually very reasonable, but especially in the case that we have an unspecified number of dots. If we know we have say 3 or 6 dots or so (as in my own doodle) and want to talk about them specifically, them this can get cumbersome and awkward.
-
A final option would be to make the SVG a view of the node’s data:
viewof abc = { ... }
, however, a drawback here is that we can’t have the SVG be interestingly dependent (and hence recomputed) on other cells anymore insofar as we want to save our values ofabc
between these recomputes ofsvg
(now dubbedviewof abc
).
I settled for option (3) today, but this gets a bit cumbersome when, say, you want to interactively edit three triangles with each 3 dots, and have to pack it all into a single mutable
cell.
The general dilemma here, is how to setup a cycle of interactivity between a determinate number of reactive datapoints (hopefully cells) and an interactive cell, and specifically the awkwardness of being able to write complex mutable
-setting logic (see 2 and 3), although in essence mutable
-setting is a single-cell operation (maybe mutable
-setting should be rethought?).
Not looking for an answer, just bringing it up as an example of a notebook-writing dilemma’s