Closed bashbunni closed 1 day ago
@bashbunni can you clarify what is meant to impact the height of the table?
To demonstrate, the following is a table of height 4 using each of these approaches:
1.
โญโโโฌโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโฎ
โIDโtitle โdescription โ
โโโโผโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโค
โฐโโโดโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโฏ
2.
โญโโโฌโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโฎ
โIDโtitle โdescription โ
โโโโผโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโค
โ1 โLost in Time โA thrilling adventโฆโ
โ2 โWhispering ShaโฆโSecrets unravel inโฆโ
โ3 โStolen IdentityโAn innocent man's โฆโ
โ4 โInto the Abyss โExposing deep-rootโฆโ
โฐโโโดโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโฏ
3.
โญโโโฌโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโฎ
โIDโtitle โdescription โ
โโโโผโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโค
โ1 โLost in Time โA thrilling adventโฆโ
โ2 โWhispering ShaโฆโSecrets unravel inโฆโ
โ3 โStolen IdentityโAn innocent man's โฆโ
โฐโโโดโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโฏ
NOTE: This example isn't concerned with adding ellipsis as the bottom row ;)
Currently bubbles/table
takes a hybrid approach where the height is the sum of two things:
lipgloss.Height(headers)
which takes into account styling on the headers (eg. borders).Meaning the bubbles/table
equivalent of length 4 would be:
โญโโโฌโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโฎ
โIDโtitle โdescription โ
โโโโผโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโค
โ1 โLost in Time โA thrilling adventโฆโ
โฐโโโดโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโฏ
3 lines for the header with styling + 1 line for the row content (no styling)
The PR I mentioned is currently taking approach 1 from my original message. I am happy to fix the unit tests and close this out once you confirm the desired approach for calculating table height :)
It's also worth clarifying whether height should be increased beyond what is needed. Since bubbles/table
sets the height on a viewport you can make it as long as you want, but in my current lipgloss/table
solution you cannot increase the height of a table beyond the total number of rows (ie. no inserting empty rows).
@Broderick-Westrope I think the height should be counted by cell (number of lines) for consistency's sake. The width is set based on the total width (number of cells) of the table, including borders, so I think height should be the same
I agree: the first approach makes the most sense to me and will generally help when reasoning about layout.
Great, thank you both for clarifying. That's what's currently implemented. I'll just fix up the unit tests and mark it ready for review.
Done. I've written a detailed description in the PR demonstrating different cases :)
We should cut off additional rows when a height is explicitly set. The last allowed row should probably just show '...' to show that there's more content than the height allows. Checked the source code and the resizing logic is only applied to width
code to reproduce: