# Reclaim the reactivity of your state management, say no to imperative MVI

DevFeed: [Reclaim the reactivity of your state management, say no to imperative MVI](<https://devfeed.tech/articles/reclaim-the-reactivity-of-your-state-management-say-no-to-imperative-mvi-25932.md>)

Original publisher: [Read original article](<https://proandroiddev.com/reclaim-the-reactivity-of-your-state-management-say-no-to-imperative-mvi-3b23ca6b8537?source=rss-7a8d96da8cb6------2>)

Author: Gabor Varadi

Published: 2022-05-02T05:05:46Z

Content type: opinion

Language: en

Sources: [Stories by Gabor Varadi on Medium](<https://devfeed.tech/sources/stories-by-gabor-varadi-on-medium.md>)

Topics: [reactive](<https://devfeed.tech/topics/reactive.md>), [Redux](<https://devfeed.tech/topics/redux.md>), [Elm](<https://devfeed.tech/topics/elm.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [architecture-pattern](<https://devfeed.tech/tags/architecture-pattern.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [elm](<https://devfeed.tech/tags/elm.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [model-view-intent](<https://devfeed.tech/tags/model-view-intent.md>), [mvi](<https://devfeed.tech/tags/mvi.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [redux](<https://devfeed.tech/tags/redux.md>), [state](<https://devfeed.tech/tags/state.md>), [state-management](<https://devfeed.tech/tags/state-management.md>)

## AI overview

The article critiques imperative MVI-style state management as overly complex and boilerplate-heavy. It traces MVI's web-oriented history through Cycle.js, The Elm Architecture, and Redux, and questions whether those patterns fit statically typed application development.

## Source excerpt

Do you find yourself chasing for "clean code, clean architecture, clean design, clean state management" yet still feel bogged down in a sea of boilerplate for even the simplest of tasks -- such as showing a simple list fetched with a coroutine? Surely this could be done in a single line or maybe about seven, but it certainly shouldn't need gigantic case-whens, three layers of indirection, and so on? Well, normally you could just invoke functions on ViewModel and it would work, but if you're forced to seek the "architectural holy grail", no one around you will trust your code unless you add at least one sealed class called ViewActions, and increase the cyclomatic complexity of your "action handler" function until it feels "just clean enough". (After all, surely the more completely unrelated things a single function does based on its argument, the more it has a "single responsibility" of handling literally everything, which is why you know it's definitely the best possible way to do it. 😏) Anyway, the boilerplate of coupling together all aspects into a single class, whether it is a function call or state property, this all has a history: namely, it came from the web. The brief history of MVI MVI stands for "model-view-intent" and comes from a (not very popular for use in production) Javascript framework called Cycle.js, hand-in-hand with a (not popular anymore) concept called "The Elm Architecture" defined as the best practices and intended use of an experimental (and since 2019, unmaintained) "functional-reactive programming language for the web" called ELM. Then again, these didn't come from a vacuum either -- the originator is Redux, in 2015. The general idea was to implement a state machine using the command processor pattern in Javascript, thereby supporting "undo" functionality (also often referred to as "time-travel debugging"). Of course, most design decisions of Redux only make sense for Javascript -- as it is a language with no static typing. It makes sense to