feat: method to expand to fill height tea.WithAltScreen()

[lrstanley]

Hello -- awesome library. I'm looking to use this with tea.WithAltScreen(), however I'm struggling to figure out the best approach to have the table expand to fill the entire height. This is the current layout of my UI (ignore the broken background):

I'd essentially like the outer border to expand towards the bottom like shown below, however I don't see any height fields exposed to allow such a configuration.

My first two thoughts would be:

1. An empty row, with no column dividers (and depending on if footer is enabled, the borders would be rounded).
2. A flag for toggling outer borders, but still allowing inner borders. This could allow the user to draw their own border. Currently, toggling border settings seems to apply across the board, including all columns/rows.

Thoughts? Is there another way that I'm missing to do this? I've thought about repurposing the footer, and dynamically changing the height of it, but that feels fragile given the dynamic height of some of the other components inside of the table.

[Evertras]

Hey there, glad you like it!

A flag for toggling outer borders, but still allowing inner borders. This could allow the user to draw their own border. Currently, toggling border settings seems to apply across the board, including all columns/rows.

First I want to touch on this: this is something I've considered for other reasons, but this has a sneaky pain point for your particular use case. Trying to draw the border outside is actually going to be nearly impossible due to the connection characters at joints between borders, or at least any outside border will not be able to connect to the inside borders. So, technically this might work, but I don't think it would look like what you want it to look like.

An empty row, with no column dividers (and depending on if footer is enabled, the borders would be rounded).

I'm definitely open to thoughts here as I think having a constant fixed height is absolutely a valid feature. The other approach that seems useful is by basically adding empty rows until the desired height is reached. This would have the column bars go down further, but it would make the footer be a fixed height which has appeal compared to making the footer variable height to fill.

So I think we have the following options (forgive my awful drawings):

1) Add empty space in footer

-------------------------
header | header | header |
-------------------------
data     | data     | data    |
data     | data     | data    |
-------------------------



footer
-------------------------



2) Add a second 'footer' for spacing
-------------------------
header | header | header |
-------------------------
data     | data     | data    |
data     | data     | data    |
-------------------------


-------------------------
footer
-------------------------


3) Add empty rows with columns

-------------------------
header | header | header |
-------------------------
data    | data    | data   |
data    | data    | data   |
        |         |        |
        |         |        |
        |         |        |
-------------------------
footer
-------------------------

I think for 1, this has potentially bad effects when the user is specifically trying to make a multiline footer... does it align top or bottom? Maybe this isn't terrible, but 2 and 3 seem more appealing for achieving constant height. Is 2 what you were thinking?

[lrstanley]

First I want to touch on this: this is something I've considered for other reasons, but this has a sneaky pain point for your particular use case. Trying to draw the border outside is actually going to be nearly impossible due to the connection characters at joints between borders, or at least any outside border will not be able to connect to the inside borders. So, technically this might work, but I don't think it would look like what you want it to look like.

Ah, yes, I totally forgot, yeah that won't work.

I actually think 3 would be the most ideal, as long as the highlighted row doesn't let you go below actual rows, and the visible row-based methods don't return empty values.

I have added a temporary (and very hacky... :D) solution that would be like 1, but a bunch of additional logic is necessary and it gets rather complicated when doing those calculations externally. Also have to dynamically change the pagination size depending on the view size as well.

[Evertras]

I'm slightly wavering between 2 and 3. I'll have to toy with this a bit, I think, and will probably try 3 first.

[robertjli]

👋 Sorry to revive an old thread, but I'd like to add my vote for setting a fixed height on the table. I think aesthetically option 3 would be best, did you ever get a chance to try it?

I can take a stab at an implementation if no prior work has been done.

[Evertras]

👋 Sorry to revive an old thread, but I'd like to add my vote for setting a fixed height on the table. I think aesthetically option 3 would be best, did you ever get a chance to try it?

I can take a stab at an implementation if no prior work has been done.

Hey there, I've not really done much with this yet. I may get some time in the future but if you're willing to take a crack at it please feel free!