Is it really true that if using MVI, there should ...
# android-architecture
k
Is it really true that if using MVI, there should be only one state? I like to have different states for different parts of screen so these can update independently and it also makes it hard to maintain if you put everything in one class. Is my understanding wrong?
waving from afar right 1
a
If they don't have a dependency on each other then go for it. It makes sense.
k
That’s what i think of it but I had an interview and the interviewer kept saying in mvi there should be only one state
a
Well thats just bad luck, or good luck, you never know.
m
The interviewer is in love with the 'god-like' data classses as ui state... You can think about state machines before studying model-view-thing patterns for ui state handling and domain modeling @Kashismails
K 2
c
There are pros and cons of both approaches. I prefer having a single state per "presentation logic class" (ViewModel/Presenter/whatever). In my case it is because it makes it possible to have some sort of base class with a generic parameter for the state (like
BaseViewModel<S>
with some niceties. That said, I would push back against the claim that MVI "should" only be one state. It always depends on the situation.
k
@marlonlom that’s what my answer was
@curioustechizen i prefer not to do it you can for example have a redux like structure for the state and effects but if you start using base classes if you come to a scenario where that doesn’t work its starts adding code smells which becomes harder to maintain. Same for single state if you keep adding everything to one state it becomes a god class
c
Like I said, there are pros and cons to both approaches. Just as I would push back if an interviewer claimed that MVI "should always only be one state"; I would also push back if someone claims MVI "should never be single state".
k
I am not saying it cant be i am trying to argue its not always the case