https://kotlinlang.org logo
#compose
Title
# compose
m

Marcello Galhardo

10/29/2021, 5:40 PM
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? 🤔
b

Brian G

10/29/2021, 5:44 PM
State
is fine to use, unless you are writing multiplatform code.
State
requires the Compose dependency, while
Flow
does not.
👍 1
1
E.g. if you want to reuse your ViewModel on iOS
m

Marcello Galhardo

10/29/2021, 5:48 PM
I do plan to use KMM in this project but I’m not planning to share ViewModels. Interesting to know. 🤔
Thank you @Brian G.
e

eygraber

10/29/2021, 7:40 PM
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.
b

Brian G

10/29/2021, 9:32 PM
State
is in
androidx.compose.runtime
, I don't think that's published for iOS (yet)
m

Marcello Galhardo

10/29/2021, 10:54 PM
@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? 🤔
e

eygraber

10/30/2021, 11:56 PM
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).
m

Marcello Galhardo

10/31/2021, 10:23 AM
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? 🤔
e

eygraber

10/31/2021, 3:26 PM
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.
m

Marcello Galhardo

11/02/2021, 8:25 AM
I see, thank you @eygraber - it is clear now.