Using a `LazyRow` with a horizontal content paddin...

# compose-android

[Jonathan]

Using a LazyRow with a horizontal content padding of 16.dp I'm unable to get children to fill the entire width of row occupies. The max width of children seem to be LazyRow.width - contentPadding.horizontal. I was hoping the content padding would act as an offset before the first and after the last child of the LazyRow and not affect the max achievable width. Is the only solution to wrap my LazyRow in a BoxWithContraints in order to get the maxWidth for the space the row occupies?

[Stylianos Gakis]

That's why Lazy* takes in a contentPadding: PaddingValues, to do exactly what you describe

[Stylianos Gakis]

Otherwise, you could also just do

LazyRow() {
  item { Spacer(Modifier.width(16.dp)) }
  // whatever you had here before anyway
  item { Spacer(Modifier.width(16.dp)) }
}

[Stylianos Gakis]

But option #1 is what you really want here probably

[Jonathan]

I'm using a content padding and it's affecting the maximum width of the children in the LazyRow

[Stylianos Gakis]

Well, I am not sure what you mean, the maximum width of an item inside LazyRow should be infinite, since it can be as wide as it wants to be, since it's scrollable.
Also if you've not scrolled at all, your space at the beginning will show, is this not what you want?

[Jonathan]

I would like the child to fill the entire horizontal space the LazyRow occupies. I don't need it to be infinity wide. So if my LazyRow is 200.dp wide I'd expect using Modifier.fillMaxParentWidth() would size the child to be 200.dp wide and not 200.dp minus the 16.dp left + 16.dp right horizontal content padding.

[Stylianos Gakis]

Aha you're using fillParentMaxWidth, I see.
Then did you try with this approach?

LazyRow(contentPadding = PaddingValues(0.dp)) {
  item { Spacer(Modifier.width(16.dp)) }
  // whatever you had here before anyway
  item { Spacer(Modifier.width(16.dp)) }
}

Your item in the middle should correctly match the size of your lazy row itself this way

[Stylianos Gakis]

Just tested this in a preview. It does in fact match the width of the lazy row itself this way.

[Jonathan]

I have not tried this approach. I figured maybe there was an existing Modifier I was unaware of that could achieve what I wanted... This solution also doesn't play nicely using the Arrangement.spacedBy(...) my first and last items will have additional spacing otherwise I'd need to use custom per item {} padding.

[Stylianos Gakis]

Yeah it does not play super well with spacedBy.
If your spacedBy is 12.dp for example, you could get away with doing

LazyRow(
  contentPadding = PaddingValues(0.dp),
  horizontalArrangement = Arrangement.spacedBy(12.dp),
) {
  item { Spacer(Modifier.width(4.dp)) }
  // whatever you had here before anyway
  item { Spacer(Modifier.width(4.dp)) }
}

and it would all work out well. But I understand how this is not optimal.
You might want to file a report saying that you find it unexpected that Modifier.fillMaxParentWidth() is shrunk by the contentPadding() that you pass inside the LazyRow, and see what the maintainers of that have to say about it. Perhaps there's more people who think the same.

[Jonathan]

Seems like it is intended functionality, just seems kinda limiting and or not obvious at this is how the LazyRow/Column would behave.

[Jonathan]

I know it’s an edge case but seems like it wouldn’t be too difficult to acheive.

[Stylianos Gakis]

Hmm yeah I see they seem to have already marked this as a WAI.
I can admit it is non-obvious, but it looks like you won't get far with getting them to change this.
I'd just go with this item{} alternative and accept defeat, at least if it fits your needs 😄

[Jonathan]

I don’t think mixing item { Spacer(Modifier.width(…)) } with item { Content(Modifier.padding(...)) } is an ideal solution. I think maybe wrapping the LazyRow in a BoxWithConstraints is far simplier.

[Stylianos Gakis]

You're introducing another layer of subcomposition then.
I wouldn't do it, but of course do whatever you feel is best for your needs.

[Zach Klippenstein (he/him) [MOD]]

On the contrary, BoxWithConstraints is far worse than using normal layout system

[Jonathan]

How much worse are we talking?

[Stylianos Gakis]

You're losing out on one entire frame I'm pretty sure.

[Zach Klippenstein (he/him) [MOD]]

Not necessarily losing a frame, but it’s way slower than the other way.

[Stylianos Gakis]

In which scenarios are you not losing out on a frame? You need one composition pass to be done first, doesn't that have to wait for the frame clock to tick to happen? Or is that just not true for sub composition somehow?

I do feel like when people discuss this topic I don't always give the best advice because I don't understand this subcomposition mechanism too well.

[Zach Klippenstein (he/him) [MOD]]

Or is that just not true for sub composition somehow?

Yep. Subcomposition can happen during the measure or placement passes. This is part of what makes it so tricky, it totally upends all your assumptions about phase ordering.