Hello, everyone! 😊 I have a complex Composable function that I decided to create two ViewModels in order to better split the responsibilities and both of them emits state (

sealed classes

via

StateFlow

). How could I handle the state changes? 1. Combine both states (with

.combine

) and create a third “ViewState” mixing and matching the two states. 2. Observe both individually and let my function recompose when they change 3. Another better approach? The first ViewModel has three states: EmptyList, LoadedList, Error and the second one has two: DataLoaded and Error. Thanks and advance! 🎉

If you use

[Mutable]State<T>

instead of

StateFlow

you get snapshot consistency of both plus observability for free

Sorry, I don’t know if I get it. Replacing

StateFlow

to

State

and observing both will be better than doing so with

StateFlow

?

I’d say it depends on the relationship between the two ViewModels. If they are independant of one another, then it probably makes the most sense to observe each one individually (

.collectAsState()

). If they are related, I like to choose one as the “parent” VM and collect that one in the “child” VM, and only

collectAsState()

on the child VM (basically making a hierarchy of VMs, rather than a loose network of them which are collected in various places). The child VM emits a state object which includes the necessary properties from its parent (with any necessary transformations), as well as its own state

I'd just use

by mutableStateOf

properties on the class, yeah. And

withMutableSnapshot {}

whenever several things need to change as part of a single snapshot transaction

Something like this?

val detailViewState by detailViewModel.state
val categoryViewState by categoryViewModel.state

withMutableSnapshot {
    TaskDetailRouter(
        detailViewState = detailViewState,
        categoryViewState = categoryViewState
    )
}

the

withMutableSnapshot

is used when you're actually performing mutations that should be seen as atomic

I don’t know if I’m following, but basically observe both directly is the way to go?

yes, and skip the

StateFlow

and go directly to

by mutableStateOf

object properties because the

StateFlow

isn't buying you anything here unless it's coming from a

.stateIn

from other cold flows. If you're using

MutableStateFlow

you're adding unnecessary complexity and steps, since

.collectAsState()

creates a

mutableStateOf

and writes into it using a `LaunchedEffect`/`.collect` anyway.

Oh, I see. Didn’t know about that complexity for

StateFlow

as well. Thanks a lot! 😊

If you write

class MyState(private val dep: Dependency) {
  var foo by mutableStateOf(...)
    private set

  val bar: Bar
    get() = dep.bar

  fun updateFoo(...) {
    foo = ...
  }
}

then using it this way:

val myState = remember(dep) { MyState(dep) }

Button(onClick = { myState.updateFoo(...) } {
  Text("Click to update")
}
Image(imageFor(myState.bar)), myState.bar.description)

then anything that is backed

by mutableStateOf

under the hood is observable, and when any of it changes the right thing will recompose. You can use this to maintain single sources of truth, and other objects' functions and properties can simply reference those sources of truth naturally.

Again, thanks a lot, Adam! I think that I need to study and practice more to understand it better. I also think that this is a great topic to cover in future artcicles/codelabs. 😊

I totally agree! We've had a lot of discussion among the team around how to position teaching materials for audiences that are deep in existing android codebases with arch components+viewmodel+livedata, rxjava, flow, etc. vs. materials for green-field compose code

I can comment as a developer who never had any experience with other declarative UI (Flutter, ReactNative etc): sometimes is very difficult to know how to proceed with Compose because there a lot of interop things on the way. Things like: “Should we use ViewModel in a new Compose project?“, “Should I use LiveData, StateFlow or State?” and so on.

yeah, there are a lot of training wheels in these examples 🙂