The resolution of my question above leads me to 2 ...

# compose

[Travis Griggs]

The resolution of my question above leads me to 2 MutableState questions:
1. var foo by remember { mutableStateOf("stuff") } and var foo = remember { mutableStateOf("stuff") } look similar, but are two different things. The first is nice because I don't have to .value all access to what I really want out of it. But on the flip, it can't be passed to other composables to modify if that's desired. Do others tend to name them differently so it's clearer when a variable is one or the other? (e.g. foo vs fooState?)
2. I have these ItemCards which are nested composables. The part that will actually care/recompose is a composable nested 1-3 levels down. So you have to pass the state down. It's simpler if I "de-value" the observable right up top and just pass the primitive down the chain. But does that result in more recomposition than necessary? Is it better to pass the "holder" down the chain, until you get to the composable that actually cares about it's value and then devalue it at that point? Or is Compose magical/powerful enough that it doesn't matter?

[ephemient]

1. I don't bother naming them differently, the types are different so they can't get mixed up
2. pass () -> String down the chain instead of State<String>, it's more general and a pattern used in the compose libraries

[Kirill Grouchnikov]

Why would you want a child composable update the state it's getting? I'd rather prefer the place that "owns" the state (where it's defined) to also be the only place that updates the state.

[Kirill Grouchnikov]

Having composables that get a MutableState isn't ideal in terms of understanding how data not only flows, but also where it's updated

[Travis Griggs]

so how would you structure the list header where the header has the actions to modify the state, but the list items read the flags to control their view? maybe you wouldn't have a header composable, but just put all the header stuff in the over all list composable that is the aggregate of the items column and the header?

[Kirill Grouchnikov]

Pull all the state up to the common parent

[Travis Griggs]

I have...

[Ben Trengrove [G]]

Your Header should look something like

Header(selected: Int, onSelectedChanged: (Int)->Unit)

[Ben Trengrove [G]]

And then bubble that changed event up to where the state is hoisted and mutate the state there

[Ben Trengrove [G]]

See https://developer.android.com/jetpack/compose/state#state-hoisting

[Travis Griggs]

Thanks @Ben Trengrove [G]. That actually helps. Concise. It seems kind of counterintuitive to pass to parameters to a function to manage a variable when we've had 50 years of C pointers (and other similar indirections) which allow us to capture those related ideas into a single parameter. But I get the value of the separation too.