Two Clerk observations today: • Being able to use TeX for table headers is awesome. • I realize that I prefer the map-of-seqs representation for table data. But I can’t (I think?) control header order directly with map-of-seqs, so I convert to seq-of-seqs instead.
Table was made with this code.
Love the sticky table header! Don’t think I’ve seen that before.
Good point - this can be solved and evaluated in userspace.
clerk/col, clerk/row and clerk/vl and clojure data is a huge improvement over last time I did work like this (that time using Excel).
(I know vega supports grids. I haven’t used those yet. Still, I like being able to tile arbitrary Clerk viewers)
been thinking if we should support sorting for the map-of-seqs representation
one of the problems is that you’d then need to specify the keys twice
> one of the problems is that you’d then need to specify the keys twice
>
For me personally, I'd happily do that.
The second key specification could also work as a select-keys, letting me pick the columns that matter. Or "pick which keys show up first", perhaps this idea needs some more time.
you could try this out by changing clerk’s table viewer to do this
one way would be metadata on the seq
I realize that simply adding “let me sort table headers when rendering a clerk table of map of seqs” wouldn’t really have solved my problem, because I wanted to style the headers with TeX anyway.
And in order to control header styles and control header order, seq-of-seqs and clerk/use-headers worked without issues. I converted my data to a different data representation, and Clerk rendered the result nicely.
Because (A) it’s all data, and (B) the table viewer can use another viewer to render the result of a cell, and (C) viewers can be written in userspace, this looks like a solved problem.
If I wanted a reusable steel section profile table viewer, creating a (defn steel-section-profile-table-viewer [,,,] ,,,) is probably the right thing for me to do.