Should huge when blocks be avoided in viewModels? ...
# android-architecture
d
Should huge when blocks be avoided in viewModels? I need to decide the content of some compose views according to the results of a state machine, and the when is very big... should I maybe be using a map instead? Or maybe resolve those states in the compose view itself?
a
I don't tend to avoid whens when they get long per say, the questions I would ask myself are, can ay of this be functioned out of my way? and does all of it belong in the viewmodel (or the view, if I'm in compose code). Is any of this actually business logic / domain code I should move up and out and just call? or is it all just view state logic?
d
It's basically some buttons and a text field that's content depends on the state of the current object being displayed on the screen. I get events that could change that status. One state could have just button A and text A displayed another could have button B and C displayed and text B, etc... I think that's view state logic... but maybe I should have all those button combinations in the the compose view? Currently I just have a composable that can display up to three buttons with a callback and a stringres for each that the viewmodel injects according to state... is that the right way to do this?