I wrote a little abstraction to render some content (a series of Text composables) either horizontally (Row) or Vertically (Column). Does Compose offer a better (built-in) way to do this?

enum class Orientation {
    HORIZONTAL,
    VERTICAL
}

@Composable
fun OrientedContent(
        orientation: Orientation, 
        modifier: Modifier = Modifier, 
        content: @Composable () -> Unit) = when (orientation) {
    Orientation.HORIZONTAL -> Row(modifier = modifier) { content() }
    Orientation.VERTICAL -> Column(modifier = modifier) { content () }
}

It doesn't (yet?). The parameters are type safe, so it would require some interesting generics to get right.

The better way is to just write

Row

when you want horizontal and

Column

when you want vertical 😛

@Adam Powell don't be bringing logic and reason into the conversation ... I'm not interested in those things! 😉

this code doesn't maintain content identity if the orientation changes. Here's what I mean:

var orientation by remember { mutableStateOf(Orientation.Horizontal) }
OrientedContent(orientation) {
  var counter by remember { mutableStateOf(0) }
  Button(
    onClick = {
      counter++
      orientation = if (orientation == Orientation.Horizontal) Orientation.Vertical else Orientation.Horizontal
    }
  ) {
    Text("Toggle!")
  }
  Text("Clicked $counter times")
}

Ha, the results I see in my head are.... shocking. I guess it would be asking too much from compose to make this "Just work" or perhaps it's just the components fault.

yes, "just write

Row

or

Column

" is obvious now. What led me down the

OrientedContent

path was a refactor. I originally had a Composable (

PostMetaData

) that was showing a

Row

of several

Text

composables. In a new spot, I needed to show the exact same things, just in a column instead of a Row, and so I came up with the above solution, instead of just extracting the

Row

from

PostMetaData

entirely and wrapping the call(s) to it in the appropriate Row/Column. It allowed me to leave my original calls to

PostMetaData

untouched, while allowing the new call to achieve verticality.

Hmm, I just ran it and skija crashed.

oops 😄

yeah, that's what I got when i emulated it in my brain.

https://github.com/JetBrains/compose-jb/issues/262 Gotta love breaking things.

the nature of this is why we're currently working on a feature of composition as a value, where you can move a part of a composition and preserve this identity. It's important for being able to do things like shared element transitions along with some other fun stuff

or in layman's terms ... if you write a composable that has a composable content lambda parameter, most of the time you probably want to avoid calling the content lambda in multiple places ...

unless you explicitly want multiple instances of that content, yes. (Think things like LazyColumn where the lambdas can represent the same presentation of different data.)

right

yep