Hi :wave: I have the following layout: ```Text1 S...

# compose

[tankistorep]

Hi 👋

I have the following layout:

Text1 Separator Text2

If all of this doesn't fit on one line, then it should change to

Text1
Text2

Is there a way of doing this without using SubcomposeLayout? The usual advice is to use this when a composition of a child depends on a measurement of another, which I think applies here, but this layout seems way too simple to be using subcomposition.

The other solution I can think of is using Layout for all 3 of those Composables, but only placing the 2 Text Composables after measurements, but measuring 3 Composables and only placing 2 feels like an anti-pattern

[Stylianos Gakis]

A custom layout sounds great here.
We do basically the same thing here https://github.com/HedvigInsurance/android/blob/develop/app%2Fdesign-system%2Fdesign-system-hedvig%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fhedvig%2Fandroid%2Fdesign%2Fsystem%2Fhedvig%2FDialog.kt#L402-L469 which you can draw some inspiration from

[Stylianos Gakis]

Your separator can be just a dp number in the layout logic instead of an entire composable like we do. That is if the separator is only spacing and not something that is rendered on the screen

[tankistorep]

Ah apologies I should have been more clear, the Separator is indeed a separate composable, not just spacing

[sindrenm]

If your Separator is indeed another composable that you only wish to render when there's space on one line for all three, then a custom Layout seems appropriate to me, too. Otherwise, if it's just spacing, a FlowRow might do the trick?

[Stylianos Gakis]

Yeap, not placing it at all is completely fine tbh. And quite simple with a custom layout

[tankistorep]

The reason why I was thinking it's an anti-pattern is because I would be including the Separator in the Composition phase and half of the Layout stage (measurement), but then not in the second half (placing) and not in the drawing phase.

So whilst the solution would technically work, you still have the Separator node in the UI tree but it's not visually present. Which, I don't know if that would cause any side effects.

This is based on my understanding of how this works though, please feel free to correct my thinking 🙂

[sindrenm]

What kind of side effects are you worried about? AFAIK, if it's not being laid out (placed), then it would also not be picked up by any accessibility service, for instance. I think it would be fine, but I'm no expert here.

[tankistorep]

Good question 😅 I guess I was wondering if there would be any potential performance issues if the component is recomposing despite not being there, and wondering if there could be any layout glitches or anything like that.

But I suppose any performance overhead would probably be less than if subcomposition was used, and if a Composable is not placed then likely nothing strange will happen? 🤷 Especially since this is a pretty simple layout

[sindrenm]

Wouldn't you want it to recompose and remeasure, though? In case someone the container's size changes, for instance, or someone changes their text size?

[kotlinforandroid]

There were talks about exposing the text wrapping API. I had a similar issue ~2.5y ago. It was about parsing a string and providing word boundary information.

Maybe they have exposed said API already. Then you could simply get the boundary information and use a FlowRow with a bunch of Text elements, each being a "word".

[tankistorep]

@ Sindre Moen
Ah yeah that's a good point actually, fair enough!

@ kotlinforandroid
Interesting, I'll try snoop around and see if I can find something like that

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

Re composing-but-not-placing vs subcomposelayout, it’s a trade off.
• Composing something you don’t need isn’t free, but something like a simple separator that probably doesn’t have any state is pretty cheap.
• Subcomposing has a significant cost, and to use it for this you’d have to subcompose at least twice, including at least once for the text content that’s always getting composed.
So the question is: is composing the divider when you don’t need it more expensive than doing a subcomposition all the time? Probably not.

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

When in doubt, measure. But given the other downsides of subcomposelayout (additional complexity, breaks intrinsics), I wouldn’t even bother here, I’d just not place the separator.

[tankistorep]

That makes a lot of sense, thank you everyone 🫶