Came across cases where Composables accept `Mutabl...

# compose

[Tash]

Came across cases where Composables accept MutableState<T> as arguments:

@Composable fun FooButton(fooState: MutableState<Foo>) { /** read/write fooState here **/ }

instead of accepting the raw data (i.e. not MutableState) + a lambda for the caller to implement:

@Composable fun FooButton(foo: Foo, onClick: () -> Unit) { /** read foo & call onClick() here **/ }

Given the guidelines around state-hoisting for reads/writes, the former looks like an anti-pattern in the declarative/Compose world. Is that right?

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

I think so, yea. One reason is that it’s less flexible. You can call a function that takes a value+callback if you have a MutableState or any api that publishes values and change callbacks (eg a view model that gives you a StateFlow). But if you’re calling a function that only takes a MutableState, you have to provide a MutableState and that might be awkward.

[Tash]

Absolutely. Makes sense, thank you 🙏🏼

[brandonmcansh]

Echo what Zach stated :)