One Off the Slack: How Should We Add Space in Columns?

Stylianos Gakis asked:

I have a code-style related question. How do you prefer to write your layouts

The first option given was:

Column {
    Item()
    Spacer(Modifier.height(16.dp))
    OtherItem()
}

The second option was:

Column(verticalArrangement = Arrangement.spacedBy(16.dp)) {
    Item()
    OtherItem()
}

IOW, do you use spacedBy() or Spacer()? The poll was strongly in the favor of the latter option.

Stylianos followed up with:

For people answering B. What do you do when the design comes with one of the spacings being 20.dp instead of 16.dp a list with let’s say >5 items?

Do you remove the verticalArrangement and add a spacer in-between all items manually?

Filip Wiesner replied:

If it’s one of many spacings that is bigger than others, than I would hack it some other way like adding padding to one of the items next to it. The problem is when the spacing is smaller than the common one or there is more than one different spacing. Than I would remove arrangement add Spacers like you mentioned.

Stylianos remained concerned:

These are two points that really have been bothering me too.

Space is smaller problems: Literally impossible, have to fallback to spacings

Space is bigger problems: If we add a padding to a specific item as you said, it

1) Feels like a hack, since that item itself isn’t what needs a padding, so you add something to it that’s unrelated to it (adding it to its modifier alleviates this problem at least a bit)

2) It becomes an actual problem when things start being rearranged in the list (very common) and suddenly that item takes its padding with it to weird places in the list.

Joseph Hawkes-Cates suggested:

Another option when the space is smaller between two items in the column is to encapsulate those two items in another container (column, box, etc) and then set their spacing accordingly. This helps you avoid adding spacers between everything else.

There was a bit of a digression, where Google’s Chris Sinco was recommending pushing back on designs that had varying spacing rules. Stylianos clarified:

I think you got me wrong Chris. The spacing of the items isn’t supposed to change depending on the number of items on it, and the children’s height or width doesn’t change when this spacing changes.

Actually I was referring to columns/rows that do not contain much of the same item, but are for example screens that contain a bunch of completely different items in them with potentially varying spacings between them.

This has nothing to do with pixel perfectness, but more about giving things various spacings to give less/more emphasis maybe?

Is that really something that I should push back on? I really don’t think so, this feels like a very natural use case.

Chris then explained a bit more:

I tend to use the spacedBy modifier in containers where I expect some uniformity amongst the children elements. It’s handy in the screenshot above for the overall Column of the screen, but I’d use it out of convenience, especially in the beginning as you mentioned. Over time, I may remove it and rely on padding within each child element because as the screen gets more complex and the children get more complex, they could have their own set of spacing built-in since they may be reused across your app. In that case, spacedBy doesn’t quite scale.

I myself use Spacer less often since I tend to have each component handle their own spacing, and/or rely on arrangement when brought together in a Column/Row. It might be because I have a designer brain and am used to tools that don’t make adding arbitrary Spacers convenient so most choices are padding or arrangement. But Spacer is very handy when hacking quickly / debugging layout / finessing before cleaning up. Oh it’s also very useful when you need to make padding/spacing percentage or ratio-based since we aren’t able to do that with the Padding modifier just yet.

The latter paragraph echoes Joseph’s earlier comment: a composable should be responsible for its own spacing.

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!