Hi! Does anyone know if there are downsides of using a `MutableState` and `State` inside a `ViewMode...

# compose

[Marcello Galhardo]

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? 🤔

[Brian G]

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

[Brian G]

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

[Marcello Galhardo]

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

[Marcello Galhardo]

Thank you @Brian G.

[eygraber]

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.

[Brian G]

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

[Marcello Galhardo]

@eygraber 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? 🤔

[eygraber]

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).

[Marcello Galhardo]

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

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

[eygraber]

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.

[eygraber]

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.

[Marcello Galhardo]

I see, thank you @eygraber - it is clear now.