ListChoice height should be based on content

[sjavora]

From slack:

Height of ListChoice is based on the content. Inner paddings are always the same. Why - to make it easier to develop and understand. We should always stick to the same padding if possible (it wouldn’t make sense to have dynamic padding, it wouldn’t be a systematic approach). You might object - “But different ListChoices can have different sizes then!” - and it’s true but it shouldn’t be a problem as typical list is usually homogenous - all ListChoices are of the same type so they have the same height.

[PavelHolec]

Isn't this what we already have? We have .small paddings around content, but a strut that makes sure the height is > 44(45)

[sjavora]

Why is that strut necessary though?

[PavelHolec]

Without it, the height could be smaller than 44 (it would be 2x12 plus whatever small custom content there is)

[sjavora]

So as written on slack, that should be 2*12 + 20 (line height) = 44. Are you thinking of some content that's even smaller than that? Do we care about such an eventuality?

[PavelHolec]

It could happen when using description alone (smaller lineheight), or just any custom content. Even just for the consistency with other tappable components that have minimal width/heigth constraint as a safety measure.

[PavelHolec]

This task could unify the custom content to use the same layout as in Tile, where caller can still use the heading, while providing the custom content below it.

This might require ListChoice<Content, ValueContent> to support both content below and a value content.

Tile:

ListChoice (not possible to combine heading with custom content in typical scenarios):