Any feedback on these 2 compose state design pract...

# compose

[Pablichjenkov]

Any feedback on these 2 compose state design practices. I would appreciate an article talking about this comparison.

[Pablichjenkov]

bigstatedesign.png,statecontrollerdesign.png

[Pablichjenkov]

Number 1, one big state for the whole screen
Number 2, multiple components each consuming its own StateFlow<ComponentState> or MutableState<ComponentState> hosted in the ViewModel

[Casey Brooks]

I usually go for approach #1 (big ViewModel with all logic), but when it gets too big or has reusable logic needed elsewhere, I’ll create a new VM for it that’s completely separate from the root. IMO, aggregating multiple state holders into a parent VM as described in #2 seems a bit over-architected, as there’s not a clear reason why they should be collected in the root. Just make the sub-components fully independent of one another or their parent, without the need for a parent VM to coordinate for them.

[Pablichjenkov]

Thanks 👍, I am collecting some feedback for internal discussions

[Casey Brooks]

As a general rule, I’ve found that having a hierarchy of VMs gets difficult to understand conceptually, as the data of the app usually doesn’t follow the same hierarchy that the UI does. The data layer tends to be more flat, or else have a dependency structure much more complicated than can be easily expressed in a UI hierarchy. But either way, I find it to be easier to handle the dependency structure of the app data in the Data/Domain layers, rather than trying to manage it in the UI. The UI then becomes as simple as possible, with little more structure than an independent VM sitting at the root of some composable (usually a Screen, but not always), and coordinating its own encapsulated data however it needs with the Data/Domain layers

[Pablichjenkov]

I have been following approach number 1 for quite some time but like you just said and many on the Internet, we basically passed from God Activities to God ViewModels. So in an effort to split up these big VMs, I have been playing with some patterns to extract some code out of it.
I was thinking an approach could be, keep the big state in the ViewModel but the functions that update the different sections of the state, take them out to a StateUpdater classes, similar to MVI reducers.

[Pablichjenkov]

Reading your answer I might be over engineering things a bit 😁

[Zach Klippenstein (he/him) [MOD]]

ViewModels aren’t designed to be hierarchical. Lots of better architecture libraries out there that are and make it pretty straightforward.

[Nabeel]

@Zach Klippenstein (he/him) [MOD] Could you please provide examples for architecture libraries that are worth look into. I'm also facing similar issue like bloated viewmodels.

[Zach Klippenstein (he/him) [MOD]]

Circuit, Trio, even just using compose to generate models directly (what CashApp does, often called “Molecule” but technically doesn’t require using molecule)

[Zach Klippenstein (he/him) [MOD]]

Basically any droidcon talk from the last two years on architecture

[Casey Brooks]

The Android documentation on App Architecture is a very good resource on this topic. While it is written with an obvious bent toward Android (code samples, terminology and such), most of it is general enough to be applied to any frontend development. In particular, adding in the Domain Layer is what will really help break up the problem of giant VMs or complicated data layers, and aligns closely with the concept of “Clean Architecture” (though Google doesn’t use that name, specifically).

But because the recommendations outlined in the Architecture Guide are more of general principles or guidelines to follow, it doesn’t require any specific libraries to work, and it can be incrementally adopted in existing codebases.