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

State

is fine to use, unless you are writing multiplatform code.

State

requires the Compose dependency, while

Flow

does not.

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

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)

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

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 Honest question: what is more hidden? Isn't the state emissions exactly the same? 🤔

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.

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