Perhaps a bit of a micro-optimization, but if you ...

# compose

[Stylianos Gakis]

Perhaps a bit of a micro-optimization, but if you want to have a composable just in order to use a modifeir to make it do stuff. Background colors, size, clip whatever. Do you typically use Box? Spacer? Something else?
I’ve always been using Box but as I see the impl it does do more than what Spacer does which I am actually not interested in for those cases, like pass a BoxScope to the content.

[Ben Trengrove [G]]

Spacer is a tiny bit more light weight, I wouldn't stress about it though. We use it for Canvas for example

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]droidx/compose/foundation/Canvas.kt;l=42

[Stylianos Gakis]

Yeah I did say “micro-optimization” and I am not stressing about it to be honest. It’s just that another engineer wrote such a composable with a Spacer and I instinctively tried to suggest to use a Box as that is what we typically use.
Only to then realize that I would be suggesting a worse solution for no reason.
I think seeing Canvas use Spacer is exactly what I needed to see.
Won’t go over the codebase migrating everything, but I’ll take one less remember and the BoxMeasurePolicy etc in future cases on each of those call sites 😄 Thanks!

[Albert Chang]

I think you were looking at the wrong overload. The Box overload without the content parameter here doesn't remember anything and is essentially the same as Spacer. I don't believe there is any difference in performance.
Btw which to use is not unified even in compose codebase. For example Icon uses Box (source).

[Ben Trengrove [G]]

Ah nice, looks like this was actually changed since I last looked quite a while ago. So yeah they are basically equivalent now

[Ben Trengrove [G]]

Key thing is to write Box(Modifier.foo) not Box(Modifier.foo) {}