Hi, I came across this talk, where the guy is crit...
# orbit-mvi
r
Hi, I came across this talk, where the guy is criticising MVI. I’m struggling to understand his objections, do you know what he means?

https://www.youtube.com/watch?v=q7y6NQ_ou0A

b
He talks about the issues of having a single state object when using Redux, because it leads to code coupling, which is generally a bad thing. With Orbit, if you keep your `ContainerHost`s small this problem doesn't exist. One argument is that sending event objects rather than calling functions. With Orbit, events are represented as functions. From what I've read, it's true that some MVI framework like uniflow-kt can give you an outdated state, but it's not the case with Orbit. You can always access the latest state in the
reduce
block or from
SimpleSyntax
. So not a problem. Overall, a lot of bs and MVI bashing for no reason
👍 2
j
fwiw, I follow Gabor Varadi on Twitter, and it seems like all he does is criticize everything.
a
the way i listened to it is Redux sucks; i agree with that statement. the single reduction function is one of my big bug bears as @Benoît says the fact orbit, uniflow, mavericks handle reduction broken down in individual functions is a big selling point of this style of MVI, what i've previously referred to as MVVM+ really MVI to me comes down to enforcing a couple of simple rules... • unidirectional cycle of data • non-blocking • immutable state
👌 1
unidirectional cycle of data means we end up with a single stream of state... personally I prefer this to what we'd often seen with a lot of MVVM implementations with multiple livedata streams - certainly when interviewing other senior android devs most have concluded a single stream is better anyway he talks about tight coupling of this single state but realistically there was often tight coupling between these multiple live data streams anyway
Rakesh Patel
I use MVI, I do not understand anything he said. vars for fields in the state object? No, they are vals. One function for the whole app? This guy is talking rubbish.
you certainly get the impression he hasn't really spent much time playing with MVI and the various frameworks out there
b
Also he says MVVM is better because it has multiple smaller state, rather than 1 bigger state. Well, actually having multiple states is much harder to deal with in my experience. Languages like Elm enforce an architecture with a single state and only 1 way to modify this state. That's what makes it so nice to use
👍 1
g
I moved from MVVM with multiple live data to MVVM+ with an atomic single “live data”, and I couldn’t be more happy
much easier to handle, to onboard new devs, validate, etc..
now imagine when orbit hits stable in KMM 🥳
on another note, I don’t remember if in your medium @appmattus you explain what you’ve explained in this thread, but for me this is good doc stuff
when i’m studying the adoption of new libs/frameworks this is the kind of info that I’m looking for
You and Mikolaj have a great video and medium about this (the MVI comparators) 👍