With Compose, is there (or will there be) a depart...

# compose

[Tash]

With Compose, is there (or will there be) a departure from using the ViewModel arch component to preserve state during config changes?

Having the ViewModel (arch component) is great, but I wonder what’s next. In the very basic form they’re essentially state holders that give us a simple solution for handling config changes, and because of that very feature, they have the propensity to grow into monoliths of presentation/domain transactions.

[Ian Lake]

You say that like you can't have multiple small, independent ViewModels.

[Susheel]

TBH, I haven't even considered having multiple ViewModels for the same Fragment. But that sounds interesting.

[Tash]

Yeah, I do use multiple ViewModels in Fragments, but more in the sense of one ViewModel that’s scoped to the parent activity and another that’s scoped to the Fragment. I guess my question was more along the lines of if Compose will offer any alternatives to managing config changes that doesn’t require your state to live in a ViewModel arch component.

[Adam Powell]

If your UI is fully compose and maybe a webview or something else tolerant to config changes you can just turn off activity recreation for config changes entirely

[Ian Lake]

Handling config changes manually is certainly way easier in a pure Compose app, but you probably still don't want your UI directly talking to repositories, etc. - that layering still a good idea IMO

[Adam Powell]

Yeah, there's still a lot of utility in having a layer format things for you. It just doesn't have to explicitly participate in the androidx ViewModel type hierarchy to keep state around

[Tash]

Gotcha, that makes sense, thanks!!!