What is MVI?
Introduction
The success of a new project is determined not only by meeting the business requirements but also by building it in a way that is easy to change and test. Basically, to develop a project in this way we’ll need two things: the right technologies and good architecture.
A well-known and battle-tested architecture can solve many issues on the platform you are working on and make the code maintainable, testable, and flexible.
In this article, I would like to talk about MVI which stands for Model-View-Intent and is an architectural approach to developing UI (user interfaces).
The definition
Based on André Medeiros (Staltz) the man behind this pattern and the creator of the JavaScript framework called cycle.js, the main idea of MVI is to do what MVC (Model-View-Controller) does, but in a reactive functional way. What is the reactive way? The apps with a UI that reacts to the state changes. And he defines the pattern as follows:
Instead of dividing our code into View, Model, and Controller classes, we divide it into three cheap to create functions (Model, View, and Intent), and using Reactive Extensions (Rx), we can make those three functions observe each other and react to each other.
How does it work?
From a theoretical point of view we can represent Model-View-Intent as follow:
In the diagram we can see that the data flow is cyclic and unidirectional and below are described the roles of each component:
Intent: represents the intention of a user to change the Model with an intent (i.e. UI events, like click events).
Model: reflects the View state. It is manipulated by the Intent and the result will be a new Model. So it is not updating an already existing Model because we enforce immutability.
View: takes the new Model and simply displays it to the user.
Essentially, Business Logic reacts to input events (intents) and produces a Model as output, which afterward can be displayed in the View’s render method.
Why MVI?
The MVI architecture offers scalability, flexibility, and easy testability.
Advantages:
- single source of truth — one immutable state that is common to all layers
- unidirectional data flow
- easy to debug — unidirectional data flow ensures that the app is easy to debug
- the code is easy to test
- possibility to test all layers of the application with unit tests — with Model representing the State we can simplify unit tests to simple check assertEquals(expectedModel, model).
Disadvantages:
- boilerplate — however a lot of that can be reduced with Mosby library.
Conclusion:
I’m not saying that MVI is better than other architectural patterns however, it can help us write more elegant code when dealing with complex problems. And last but not least, should you use this architecture on your project? Well, it depends. However, before making a decision I would recommend taking a look at this course series with detailed examples of MVI architecture implementation.
