Closed zampino closed 4 months ago
@zampino This happens in the expression:
var-name (symbol (namespace id) (str (name id) "-table"))
Apparently the wrapped-value that comes in doesn't have an id. What to do in that case?
I'll try to repro tomorrow
yeah, the cell id appears to be nil
(or missing) in some cases, would be cool to know for which cells. Probably some recursive call of apply-viewers on some nested structure which are not cells.
Probably some recursive call of apply-viewers on some nested structure which are not cells.
In fact, as expected, here's a repro https://github.com/nextjournal/clerk-table-stats/blob/739123acf3c1af086190b84cdb91ab22f27b4fea/notebooks/missing_id_repro.clj#L16-L20
Now while we could propagate the cell id at deeper children, what would that imply in the specific case of the stats-table? How does it handle nested tabular data? If we want interactive header controls at deeper levels then the sync-atom names should be a combination of the parent's cell-id and the path (see repro), but I doubt deeply nested controls make sense?
@zampino Isn't the table viewer only really interested in top level forms?
I would say so, but the predicate matches at deeper levels. I think you can fix that if you use the :wrapped
form of the predicate and argue on the count of :path
from the wrapped value. Path of length 1 correspond to top-level forms.
Isn't the table viewer only really interested in top level forms?
No. Tables nested inside other viewers is a use case we have and should be supported.
Ok then we‘ll propagate the cell id down to presented children and use the path to disambiguate.
Andrea and I discussed this on a huddle yesterday and we thought nested "stats" tables might be a bit messy, so another possibility is to just render nested tables using the default table viewer rather than the stats table, but I don't have a strong opinion on this.
To reproduce, uncomment the viewer in this notebook, simply starting ductile with
bb dev
.