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.
i
Ian Lake
10/19/2020, 8:08 PM
You say that like you can't have multiple small, independent ViewModels.
👍 3
s
Susheel
10/19/2020, 8:10 PM
TBH, I haven't even considered having multiple ViewModels for the same Fragment. But that sounds interesting.
t
Tash
10/19/2020, 9:56 PM
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.
a
Adam Powell
10/20/2020, 1:08 AM
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
i
Ian Lake
10/20/2020, 3:03 AM
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
a
Adam Powell
10/20/2020, 3:27 AM
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