A modern programming language that makes developers happier.

kotlinlang

Hi! Does anyone know if there are downsides of using a `MutableState` and `State` inside a `ViewModel`? For example, why would someone choose a `MutableStateFlow` in a `ViewModel` and do a `collectAsState` instead of simple using a `MutableState` at first place? :thinking_face:

`State` is fine to use, unless you are writing multiplatform code. `State` requires the Compose dependency, while `Flow` does not.

E.g. if you want to reuse your ViewModel on iOS

I do plan to use KMM in this project but I’m not planning to share ViewModels. Interesting to know. :thinking_face:

I believe `State` is common code, so it could be used in a multiplatform project. 

One reason to use `MutableStateFlow` / `collectAsState` would be to keep your state entirely immutable (i.e. if state changes a whole new object is emitted vs updating your existing state). This is helpful in architectures like MVI.

`State` is in `androidx.compose.runtime` , I don't think that's published for iOS (yet)

<@U3K6VQZLJ> you can still put a whole object inside a state and have immutability, no?

Or do you mean, with MurableStateFlow you can use operators like map and "break down" the immutable into small states for better recomposition? :thinking_face:

You could put the whole object into a state, but then you're directly mutating the reference to it when you update it. Which is technically the same as how `Flow` works, except it's more hidden because you're doing it through state emissions (also the distinction blurs depending on how you work with it, i.e. `MutableStateFlow.value` vs doing everything with a flow API).

I'm sorry but I think I'm missing something. If you don't use property delegate (by) with `MutableState`, you would still change it by using `MutableState.value = newValue` - which from my understanding is exactly what you described above with `StateFlow`.

Reference: <https://developer.android.com/reference/kotlin/androidx/compose/runtime/MutableState|https://developer.android.com/reference/kotlin/androidx/compose/runtime/MutableState>

Honest question: what is more hidden? Isn't the state emissions exactly the same? :thinking_face:

It depends. 

If you're using a regular `Flow` for `collectAsState` then you're not setting `value` anywhere; you're just emitting your state. If you use `MutableStateFlow` then it is much closer to how `MutableState` works. 

I think using `MutableState` in this way "sort of" defeats its advantage over `collectAsState`. The way I'm using it to have a `MutableState` for each field so that I can limit the recomposition to the specific scope where that discrete read is. 

By having your whole state in a `MutableState` that you read in a top level composable, recomposition will affect that whole subtree.

You can still get the skipping behavior if the params passed to another function haven't changed, but I've seen a few folks here caution against relying on that since there are some scenarios where it gets tricky.

I see, thank you <@U3K6VQZLJ> - it is clear now.