I’m currently experimenting with presets, i.e., controls that change the values of viewof cells. Some of these cells’ inputs derive their valid ranges from other cells.
This has led to a bit of a pickle when a preset sets values on multiple interdependent cells in a single tick. A simplified example can be found here:
Currently I’m using chained promises to assign values after one another. This leads to intermediate and unnecessary computations in other dependent cells which consume the viewof cells’ values.
Which strategies or patterns can be used to handle this situation (and use case) more efficiently?
Here’s a variant that changes the explicit dependence of viewof value on range to a dependence on viewof range (at the cost of having to fiddle with an event handler):
This seems to avoid the specific issue you point out, I guess because it avoids re-evaluating viewof val. My gut tells me that having the Observable runtime re-evaluate view cells ought to be avoided if possible (though I’ve certainly broken this rule many times in the past). I’m not sure I can articulate more constructive advice though. I can certainly envision situations where having to set up a bunch of event handlers like this will lead to pain.
The viewof val is defined dependent on range, so when you cause the value of range to change, a new viewof val is created, and a new Assign button, too!
@bgchen’s solution seems good here. You could also use a side-effect cell to tie the two views together. (I tried this, and it’s still messy because you have to wait for the Observable runtime to evaluate the cells, whereas in @bgchen’s solution the side-effect happens synchronously inside the call to dispatchEvent.) I generally recommend avoiding this, and am hoping we can deprecate it in the future when we support runtime versioning, because it’s so easy to misuse.