[WIP] Table view #1834
[WIP] Table view #1834
Conversation
monfera
force-pushed
the
table
branch
2 times, most recently
from
3452db9
to
8f0f78b
Compare
|
Quick memo of our chat : the To allow per cell styling, the attributes for left vs center vs right alignment, font styling, number formatting, background color etc. will admit either a singular value (e.g. the entire table uses the same font) or an array that follows the same nested structure eg. @etpinard specified these options for future consideration: |
|
Feature list: Above example shows these features:
These need development for a MVP (IMO):
Todo before merging:
Todo before merging (from PR feedback items):
Add-on functions:
|
|
The mock that produces the above circus-themed cell smorgasbord: Note: many attribs are inspired by @etpinard's suggestion so that an attrib can be
To add a row semantic, I simply reuse the last value, i.e. if there are 4 rows and an arbitrary number of columns, then this'll produce a red/blue/red/blue stripe for the 4 rows:
Of course, the below version would produce per-column striping: So, due to how it can be mixed and matched, and how the last array value is reused for remaining (unspecified) items, the attribute arrays can look quite heterogeneous. Also, attribute specs don't have to match one another's structure in the JSON. |
|
I'm leaning toward deleting the colorbar. The original idea was that, if the user chooses to color cells by some value, then the colorbar would be handy. But the issue is that there's a combinatorial explosion of possible wishes, eg. the user would use coloring for one column, or multiple columns of the same unit / measure / etc. (comparables); but perhaps it would be rows, or a rectangular area in the table. Heterogeneous coloring can't be done because a colorbar supports one scale only. Yet it's simple to achieve the desired effect, because as with the other cell styling options, a per-row, per-column or per-cell color can be directly specified. If the decision is to retain the colorbar, I could use guidance on how exactly it should behave and how it should interact with possible cell coloring specification that might be in conflict. |
Yes, definitely. The Python table figure factory doesn't have a colorbar either. |
|
I agree with the ✅ 's in the MVP section. It seems like those will get us to parity with the Python table figure factory, which we already know is a success. We can let future features be driven by user and customer demand.
Offering one or the other seems more than sufficient. FWIW, I've seen table pagination with DataTables a fair amount in Shiny apps: |
|
@etpinard @alexcjohnson have you got a preference for styling the header row in the JSON spec? Some options:
|
|
Lets go with (2) - separate spec for the header row, and yes, single-row headers. This is a very common use case so shouldn't require turning all the styles into arrays. Also fits in with the analogous heatmap case - in which axis labels are specified independently from the data. |
|
Yeah (2) sounds good. I'm not a fan of the root-level |
|
Thanks for the answers! Yes some attribs e.g. |
|
|
|
I like |
|
|
Non-garish table example:
|
I don't think we need an option for this (if I'm understanding you right) - this should work just like regular html tables, ie all rows get the same height, which is enough to fit the tallest contents. Otherwise items in a row lose connection to each other.
Lets use |
test/image/mocks/table.json
Outdated
| ["Min H/W"], | ||
| ["Diameter"], | ||
| ["RF block"] | ||
| ], |
There was a problem hiding this comment.
Does header.values need to be 2D, or is 1D sufficient?
There was a problem hiding this comment.
Nope, it handles a 1D array just fine, I'll need to update the mock, thanks for the reminder!
|
@alexcjohnson thanks for your feedback, I'll look into the text wrapping! btw. when I wrote 'heterogeneous row heights' I referred to the possibility that some rows (the entire row ofc.) would be taller than others to wrap long contents into multiple lines - yes an alternative is to make all rows of equal height (the max). Given that we'll have pagination, and the table may have a lot of rows, probably heterogeneous row heights would provide a better user experience as a single outlier long line would make the entire table look weird, pls. let me know if you see otherwise. (I wasn't shooting for broken lines ie. the cells of a specific line would be of equal height, as per the max wrap count in the row). An aside is that HTML tables are rather sophisticated for text wrapping and I'm not currently shooting for feature parity with it. For example, if left unspecified, HTML tables will adjust the table column widths so as to maximize the screen use. For example, a column with more / longer content would end up being wider. I doubt the HTML table does an actual MILP optimization but at the simplest, it may use some heuristic eg. total text length, which would of course be crude, as non-proportional fonts and non-uniformly breakable text (dependent on word length, word count etc.) make it more complex than if text were like sand or water 🚰 |
Ah great, I thought I must have misunderstood you, thanks for clarifying! Yes, I think you're correct that each row should size to its own contents, not the tallest of all contents. I wouldn't bother making that an option, at least not initially. Raises a question about how pagination should work with these variable-length rows, do you go for constant number of rows or (as close as possible) constant total height? If the latter, there will still be a possibility that a single row is bigger than the allotted size. To me that kind of consideration kind of argues for scrolling instead of pagination - and personally I think I kind of prefer scrolling anyway, but it's probably a good deal harder to implement in a performant way.
Way too sophisticated, I've always been confused by the decisions HTML layout engines make there. Simple and explicit is way better for our purposes. |
|
@alexcjohnson thinking about the latter, because otherwise the page height will be overly variable, and the pagination buttons must be kept at place, i.e. there would be too much variance in the gap above the pagination buttons, and a large gap sends the misleading message: I'm the last page! As the user can jump to arbitrary pages, the entire table has to be wrapped upfront... so we're kinda reimplementing the HTML table functionality... scrolling is the same in this regard (all wrapping has to be precomputed). Yet I'm partial for pagination, at least in the 1st version, for some reasons (just a sampler):
So as you can see, wrapping, while it sounds innocent as a feature request, it triggers a whole lot of design and implementation choices and we'll learn of most of them during the work :-) |
|
I agree that pagination will likely be easier to implement - and I'm not particularly strongly opinionated about which we go with - but to your points:
This will be an issue - at least in edge cases - no matter what for a paginated table. But scrolling tables can just show partial rows and fill whatever space they are allotted (unless the whole table is smaller than the given space, which is also fine).
In principle I would imagine a container big enough for all the rows, but then only rendering the visible ones... so then the element count would be only marginally larger for scrolling than for pagination, though the frequency of changing which ones are rendered would be much larger.
We do have scrolling legends and dropdowns...
Not sure I follow... I guess with pagination we could make each column (header included) a group, and move them together, whereas with scrolling it would be easier to make the headers inside one container and the data inside another container, so there would be two things to move in sync whenever a column moves? So pagination does seem simpler but I wouldn't characterize it as much simpler.
Yah for sure, all sorts of issues around wrapping. Just to be clear though, it's not just automatic wrapping that triggers this, but also |
|
btw. if scrolling were needed, we'd probably need to do an infinite revolver to keep element bounded, e.g. https://bl.ocks.org/monfera/8b87a9aade2214fc15ea76bdf7abe11a We'd need to do something similar because in my experience a long SVG surface (multiple k pixels tall or wide) will be slow even if only the visible part is rendered, so basically we'd just mimic the scrolling like in the above example. Thanks for the clarifications on the other points! Brw if we want to initially go with a scroller rather than a paginator pls tell me today so I can pivot early tomorrow my time. |
|
Ah, the infinite revolver is a cool idea, with the two panes trading order! Dunno if @jackparmer or @etpinard have other opinions, but from my perspective scrolling is worth it if:
|
|
I'll do a morning sprint on a crude scroller just to see how it behaves performance and jankiness wise. |
|
now done in #2052 |
As per discussion at #991
Most functions, attributes etc. are not working and not final.
Printing doesn't work as, apparently, nested
fontspecs in an array (dimensions) balk when printing.Test cases aren't added to this branch yet.
Shows a variety of column formats (font options, numeric options) and column rearrangement.