Just looking back at Orbit... and I'm wondering wh...

# orbit-mvi

[dave08]

Just looking back at Orbit... and I'm wondering what's the advantage over just having a simple channel for side effects and a state flow for ui state in the view model?

[Guilherme Delgado]

That’s a great question. Also, in the context of Kotlin Multiplatform, we have libraries like KMP-NativeCoroutines and Gradle plugins like SKIE that enhance the use of channels and flows, making them more accessible and lightweight for iOS, with the advantage of requiring just an annotation in the code (if using the library) or nothing at all (if using the plugin). This has led me to consider the overall advantages of MVI libraries in general as well (note that this libs/plugins do not impose any arch.).
I also think it’s very important to have clear documentation that demonstrates the advantages of using these MVI libraries instead of the ‘default core,’ so the target audience is better informed about this.

[Mikolaj Leszczynski]

in short:
1. Work is automatically offloaded to a background thread when you call intent so you don't have to think about managing coroutines by hand - this creates consistency in your codebase and protects your UI from work accidentally done on the main thread
2. Less boilerplate
3. Consistency again - the architectural logic/implementation is consistent throughout your VM's which might not be the case if you hand-roll every VM.
4. The library is heavily unit tested against the adopted paradigms
5. Unit testing is possibly easier and more consistent.
6. Extra considerations, like caching side effects or cancelling and restarting intents depending on the number of observers.
That's just off the top of my head 🙂