I agree that it can be hard to follow the flow and I shared similar thoughts around boilerplate, ctrl+b eventually becomes your best friend - which it should be anyways!
Where we disagree is that MVI really comes to shine in larger code bases with complex UI interactions, and is overkill for simple UI. When you think about refactoring or adding on more functionality, MVI pinpoints the exact interactions that already occur and what their side effects are, and eventually results in the exact state expected - you know exactly what to expect and how to modify pre existing states. Without that unidirectional flow of intentions, the codebase only becomes increasingly more difficult to scale on top of and maintain.
"MVI pinpoints the exact interactions that already occur and what their side effects are"
MVI does not do this by default though, it requires developers to model those interactions themselves. MVI only provides the framework to do so, just like any other architecture pattern. And MVI is really strict about this, it imposes a lot of artifacts and rules down your throat. Rules and constraints can be good, but in my opinion, the ones MVI encourages are not.
Without that unidirectional flow of intentions, the codebase only becomes increasingly more difficult to scale
The idea of the unidirectional flow is nice, you can still implement it without strictly adhering to all MVI ruleset or go with a different architecture altogether
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree that it can be hard to follow the flow and I shared similar thoughts around boilerplate, ctrl+b eventually becomes your best friend - which it should be anyways!
Where we disagree is that MVI really comes to shine in larger code bases with complex UI interactions, and is overkill for simple UI. When you think about refactoring or adding on more functionality, MVI pinpoints the exact interactions that already occur and what their side effects are, and eventually results in the exact state expected - you know exactly what to expect and how to modify pre existing states. Without that unidirectional flow of intentions, the codebase only becomes increasingly more difficult to scale on top of and maintain.
Hi! Thanks for reading, appreciate the feedback!
MVI does not do this by default though, it requires developers to model those interactions themselves. MVI only provides the framework to do so, just like any other architecture pattern. And MVI is really strict about this, it imposes a lot of artifacts and rules down your throat. Rules and constraints can be good, but in my opinion, the ones MVI encourages are not.
The idea of the unidirectional flow is nice, you can still implement it without strictly adhering to all MVI ruleset or go with a different architecture altogether