DEV Community

Discussion on: A case against the MVI architecture pattern

Collapse
feresr profile image
Raviola Author • Edited on

I don't see how that eliminates the drawbacks. Let's take a flow in your example: the Reset counter flow. To understand how it works you need to go to line 45 in the handler, read one single line, then jump to line 67 in the reducer, read another single line, and the jump again!. Both lines are surrounded with completely unrelated code.
Also, it's not clear where to jump exactly, no shortcut will take you where the code should continue, cmd+f/b is your best bet and even so it might take you a while.

In the end, you spend more time jumping around trying to find code than actually reading code.

Collapse
mochadwi profile image
Mochamad Iqbal Dwi Cahyo

for now the MVFlow is the simplest we can think of at the moment, also I'm fully agreed with you

Both lines are surrounded with completely unrelated code

any suggestion at the moment to optimize this instead?

spend more time jumping around trying to find code than actually reading code.

Thread Thread
feresr profile image
Raviola Author

any suggestion at the moment to optimize this instead?

Personally, I'd just switch to another Archtecture pattern (MVVM) or use an MVI library that does not impose strict rules regarding where you have to do the mapping, and where you have to perform state reduction.

This library for example avoids the (intent -> action) mappings altogether. When you call add you can follow the flow linearly and the state is reduced contextually.

orbitlibrary

Thread Thread
mochadwi profile image
Mochamad Iqbal Dwi Cahyo • Edited on

thanks for the suggestion, the Orbit-MVI 3 seems fit our usecases and a simplified version! ❤️