Is it a supported pattern to pass around `MutableState` instances to implement "utility" composable...

# compose

[Norbi]

Is it a supported pattern to pass around MutableState instances to implement "utility" composables? (Seems to work but does not follow the "state hoisting" pattern.)

@Composable
fun <T : Any> ComboBox(
    state: MutableState<T?>,
    ...
) {
    ComboBox(
        selected = state.value,
        onChange = { state.value = it },
        ...
    )
}

Thanks.

[MR3Y]

You should avoid doing so because you'll end up with multiple sources of truth which can result in a hard to debug obscure bugs + it makes your api a bit more clunky.

[MR3Y]

Consider accepting a lambda parameter instead.

[Stylianos Gakis]

Make it take:

param: T
setParam: (T) -> Unit

Or even

getParam: () -> T
setParam: (T) -> Unit

There's never a good reason to make it take MutableState instead.

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

Lambdas are nice because at some point you’ll need to actually do some on a value coming in or out and if you have a lambda you can just do it. Also makes it easier to write tests