My 1.0 notebook https://observablehq.com/@mootari/github-diff contains an HTML cell that currently fails to render due to a syntax error caused by the viewof chartOptions reference.
The code in question:
<div style="font: 13px/18px var(--sans-serif)">
<a href="?${new URLSearchParams({
url,
...chartOptions,
filter: viewof chartOptions.querySelector("input[type=search]").value // We want the query
})}">Share link</a> · <a href="?">Reset to defaults</a>
</div>
Yes, I’m aware of this issue. Only Observable JavaScript cells support Observable JavaScript syntax, so you’ll have to use viewof$foo instead of viewof foo to fix this issue.
Right, but any notebook with the same issue appears broken in the new UI, and I have no way to identify them. Which basically means that a bunch of my notebooks that had been perfectly fine for months or years are currently erroring through no fault of my own, and I don’t know which ones.
Yes, sorry, I know that’s not ideal and we do try to maintain backwards compatibility. The challenge here is that viewof interpolation is a fairly uncommon technique, and my first (and only) thought on how to fix it is to introduce duplicate cell nodes for every non-JavaScript cell mode, which has a high implementation cost and a significant burden on users to manage these very rarely needed variants (html+ojs, md+ojs, sql+ojs, etc.). I suppose we could do it via the standard library setting, but that’s only supposed to affect runtime behavior and not syntax. Or we could add another setting to control interpolation syntax in non-JavaScript cells, but again, that’s a lot of work for something so rare. So I don’t have a great answer for you now except to apologize for the disruption to your notebooks. Perhaps that last option is the best approach. I can try to get to it but there is a lot of other stuff I need to build urgently, too.
I’m not sure that’s true, actually. Over the years I’ve seen several notebooks that pull viewof outputs out into a combined dashboard by referencing them together in an HTML cell.
Would it be possible to determine the impact by querying the DB directly?
Fwiw, this seems sensible to me since (in a way) most cell modes are syntactic sugar over the library’s template tag functions.
