Hello, everyone! :blush: I have a complex Composa...

# compose

[escodro]

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! 🎉

[Adam Powell]

If you use [Mutable]State<T> instead of StateFlow you get snapshot consistency of both plus observability for free

[escodro]

Sorry, I don’t know if I get it.
Replacing StateFlow to State and observing both will be better than doing so with StateFlow ?

[Casey Brooks]

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

[Adam Powell]

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

[Adam Powell]

Snapshot observation is transitive, no need to explicitly start a subscription operation. If anything about the class reads snapshot state the observe is recorded

[Adam Powell]

So all of the business about combining states just becomes calling normal functions and reading properties.

[escodro]

Something like this?

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

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

[Adam Powell]

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

[Adam Powell]

you don't need it when creating an instance of the object

[Adam Powell]

and if you're performing these operations from the main thread in the global transaction, that's fine too (to omit the withMutableSnapshot)

[escodro]

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

[Adam Powell]

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.

[escodro]

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

Thanks a lot! 😊

[escodro]

One last point: About the recomposition when observing multiple states from ViewModel(s). Is that okay? I was trying initially to have a SSOT to avoid this (combining states, for example).

[Adam Powell]

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.

[Adam Powell]

The "combine" operations are implicit, you just use what you need.

[Adam Powell]

No copies, no additional layers of caching values.

[escodro]

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

[Adam Powell]

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

[Adam Powell]

we've chosen to focus on incremental adoption use cases first, but the tradeoff there is that interop cases involve a lot of existing constructs that don't need to be there for green-field compose code, and there's a risk of creating cargo cults by implying that these things need to be there for things to work, rather than that they're there for familiarity and smooth integration with existing code that already looks that way for other reasons.

[Adam Powell]

This is also why things like the snapshotFlow {} API exist; it's an easy way to observe snapshot-powered objects written in the style I described above and consume it from other parts of your app that already speak Flow

[escodro]

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.

[Adam Powell]

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