Blueprint: Add option to table to stretch to fill

[tgreenwatts]

The current ghostCell version of the table looks great for spreadsheet style tables - where users know that the table could grow for example. But if apps know the size of their table, and it's not going to change often, it would look better to have that table stretched to fill the available space. For example, if you have only 3 columns, make each column 1/3 the width of the table.

Apps can set this themselves too though

Should Blueprint Table support this?
Thoughts from @llorca , @cmslewis, @themadcreator

[cmslewis]

Seems reasonable at first glance that Table should support pt-fill. (For my future reference: a potential trickiness is that in the table implementation, the virtual rendering works by caching the width of each column and the height of each row, so it can know how many cells to render in the current viewport. To support pt-fill, we'd have to recompute these cached values every time the window is resized. Then we'd have to determine if we want to continue using "hardcoded" widths or if we want to move to flexbox semantics.)

[llorca]

Sounds like what a regular HTML <table> would do. It's a bit weird to think about the same interaction within a spreadsheet table, because there's so many more moving pieces. Some preliminary thoughts/questions:

• What happens when the UI changes the width of the table, or when the screen gets bigger or smaller?
  
  
  
  • Do all columns get resized proportionally?
  
  
  • Does only the last column get resized?
  
  
• What happens when columns are added or removed?
• This may potentially mess with users' workspace, for instance when they resize a bunch of columns to their preference and want it to stay.

[brunesto]

I use the gist below in my current project. the quality is probably not enough to be part as is into blueprint, but it does work fine. The table will occupy all its parent space. Column widths are specified either with a positive number which represents absolute pixels, or with a unit-less negative number which ala flex , using a new property; columnWidthsSpec

The way it works is that the columns with absolute width are allocated first, and the remaining space is shared among the flex columns.

resizing the columns is supported,
re ordering (ie dragging)/ adding /removing columns is not supported i guess (never tried)

https://gist.github.com/brunesto/eb2c1979ad26e7fab2077fe85ddbf8e3

[tnrich]

Although @llorca brings up some good points, this has definitely been a slight pain point for us when using blueprint's table. We've had to wrap it in react-measure and manually set column widths but even when doing that there are various issues we've had to make hacky fixes for.

Maybe there is a way this could be done and still allow for all of the complex use cases?

Thanks!

[llorca]

@tnrich there's surely a way, we just need to be careful about all design aspects and how different features can interact/conflict with each other. Not sure when we'll get to this as we're focused on substantial performance improvements at the moment!

[Lojka59]

sometimes it is good to make only one column stretchable

Something like:
ability to set "auto" (or flex) as columnWidth, like so:
columnWidths=[ 50, 50, 50, "auto"]

and this one column will fill all available space of table (or be default if not enought space)

[tgreenwatts]

Apps can support this themselves if they so desire, so I think we're going to close this

[olivergeorge]

We've got code to do column stretch to fill but it's quite unstable between blueprint releases. The problem is working out what width we've got to work with.

Our current iteration uses this approach to pick the available width. Note: Very dependent on how Table is constructed from HTML elements.

• (gdom/getElementByClass "bp-table-quadrant-scroll-container" bp-table-container)
• (gobj/get scroll-container "clientWidth")

It would be helpful to have a clean way to know the available width for columns excluding row header and vertical scrollbar.

(perhaps this should be a separate issue for consideration)