I'm wondering, what are the differences between `StateFlow` and `MutableState` in viewmodel/presente...

# compose

[Lilly]

I'm wondering, what are the differences between StateFlow and MutableState in viewmodel/presenter layer? Is there a rule of thumb when to use one over the other, are there any drawbacks to use the one or the other? It seems to me both work the same way

[Adam Powell]

imo use [Mutable]State for things consumed by your UI. If you need a Flow somewhere you can use snapshotFlow {} to get one.

[Adam Powell]

Snapshot state is generally easier to work with via the property delegates and works transitively across the call stack without having to assemble an operator chain. All snapshot state objects are guaranteed to be transactionally consistent with one another during composition, which is not a guarantee with separate StateFlows; in those use cases if you want to ensure that same consistency you would have to merge them into a single stream.

[Adam Powell]

And finally, .collectAsState simply collects the flow and copies it into a State<T> anyway, so using mutableStateOf directly instead saves some steps.

[Lilly]

Thank you very much for the detailed answer @Adam Powell ❤️

[Jason Ankers]

I’d argue combining flows is a positive. If a screen is composed of multiple independent remote data sources, doing something like this feels nice:

val uiState = combine(source1, source2, source3) {
    emit(UiState.Loaded)
}.onStart {
    emit(UiState.Loading)
}.catch { 
    emit(UiState.Error) 
}

[Adam Powell]

if you've got cold flows, sure, but since we were talking about [Mutable]StateFlows above that don't complete or emit errors, and source1-3 must be multicast/hot to communicate the actual values somewhere else, the (observable!) equivalent using snapshot state might look something like:

val isLoaded: Boolean
  get() = source1 != null && source2 != null && source3 != null

or replace the null with whatever other initial-value sentinel you might be using. No special API needed, just plain Kotlin.

[efemoney]

Can [Mutable]State be used in common code (yet)?

Say the same presenter object is to be shared across platforms, doe this answer still hold for whether to expose StateFlow or MutableState?

[Adam Powell]

yes, it's supported on any platform compose targets

[frankelot]

I suspect this is going to be a rather popular question as more and more people jump into compose
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1623313858334200

I hear good reasons to favor [Mutable]State over StateFlow , are there any good reasons for when to favor StateFlow