I have a code-style related question. How do you p...

# compose

[Stylianos Gakis]

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

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

B:

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

I’d love to hear arguments/opinions too if someone feels like they have strong opinions about either way.

[Stylianos Gakis]

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]

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.

Tldr: 🅱️ but depends on the context 🙂

[Filip Wiesner]

Thanks for this interesting discussion btw 👌

[Stylianos Gakis]

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.

With all these in mind, I really feel like even though I like 🅱️ more, and it seems like most people like it too, it starts becoming a problem in every slight change the Column/Row might see.

[Joseph Hawkes-Cates]

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.

[Chris Sinco [G]]

Another option: push back on the designer about why their spacing choices are inconsistent 🤷🏻‍♂️

[Colton Idle]

Have you ever tried speaking to a designer? 🧌 😂

[Chris Sinco [G]]

Revisiting this thread, and jokes partially aside, as a designer, I would question my design choices about being super precise with spacing (20 vs 16) between items based on # of items, assuming the parent Column width is the screen width (albeit padding). Not sure if this is design is based on iOS but I’d push back and say hey Android screens have different widths, so it’s more scalable to use weight or Arrangement.SpaceBetween in this scenario. This would also ensure the children in the Column would all be the same size (assuming this is what you want), and have even spacing between them.

[Chris Sinco [G]]

I guess to others’ points, it all depends on context and the design you are trying to achieve. But again, as a fellow designer, I’d welcome the pushback because we shouldn’t be designing everything pixel perfect to a single device.

[Stylianos Gakis]

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.

[Stylianos Gakis]

I think I can use this image as an example.
Think of this screen having a Column {} wrapping everything, you have the CircleView then MoveAndHeartItems then StepCalcStats then HeartGraph composables.
These in-between them have varying Spacings as it is right now as far as my eye can see (I don’t have a great “designer’s eye”).
Thing is this screen may have started with less features, and a common verticalArrangement spacing may have sufficed, but then as soon as more of those composables were introduced, you’d have to drop that in favor of individual Spacings. Am I wrong to think of it this way? Please do help me understand your point if so, I’d really appreciate it.

[Chris Sinco [G]]

Gotcha, indeed I misunderstood. Though I think the general answer of "it depends on context" still applies. In the screenshot you provided, yes I think you may end up having variability in the spacing across the entire screen just due to the size of elements (font size, height/width) which I believe is being used more to communicate hierarchy and emphasis than space. Space here is used more to communicate grouping of items together / container relationships.

[Chris Sinco [G]]

Related, 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.

[Chris Sinco [G]]

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.

[Chris Sinco [G]]

Am I wrong to think of it this way?

I personally don't think there's a wrong or right way to think about how to implement spacing. I think what is great about Compose is there is just enough variability in how to implement spacing that you can choose what works for you but not be overwhelmed with too much choice, e.g. CSS. One general rule I do have though in a world of variable spacing is at least for Android/Material apps, using multiples of 4.dp is always handy to keep UI spacing harmonious across your layouts with minimal effort.

[Stylianos Gakis]

Hey thanks for taking the time to write down all this advice, I do appreciate it!

[Stylianos Gakis]

Re-reading this post 8 months later (damn time flies) and I must say I’ve pretty much defaulted to going with Spaces in the majority of the cases with the exception being when for sure all items are equally away from each other so I just use spacedBy.
The idea of the items themselves knowing about their own space has never worked for me still. Depending on different contexts these items are being used in, it’s always easier to reason about by adding the spacer itself. Either I’m interpreting the designs weirdly and I don’t quite get that spacing, or not sure 😅

[Colton Idle]

Yeah. thats what i do basically. https://mxstbr.com/thoughts/margin/

[Colton Idle]

"margin considered harmful" blog post basically says that putting padding into a component makes it less reusable. and ive definitely swayed that way over time as well.

[Colton Idle]

https://chris.banes.dev/always-provide-a-modifier/ has also pushed me towards doing that.

[Chris Sinco [G]]

Yeah always passing a modifier is a nice tool