MVI Architecture in Compose

---
title: "MVI in Compose: Kill Impossible States with Sealed Interfaces and a Pure Reducer"
published: true
description: "Learn how to implement strict MVI in Jetpack Compose using Kotlin sealed interfaces, pure reducer functions, and StateFlow to eliminate boolean flag hell and ship deterministic UI at scale."
tags: kotlin, android, architecture, mobile
canonical_url: https://mvpfactory.co/blog/mvi-compose-sealed-interfaces-reducer
---

## What we are building

By the end of this workshop you will have a working `SearchViewModel` built on strict MVI — sealed interfaces for state and events, a pure reducer function, and `StateFlow` wired to Compose. More importantly, you will understand *why* this pattern makes an entire class of UI bugs structurally impossible.

## Prerequisites

- Kotlin 1.9+
- Jetpack Compose (any recent stable)
- Familiarity with `ViewModel` and coroutines
- A project using `androidx.lifecycle:lifecycle-viewmodel-compose`

---

## Step 1 — Understand why boolean flags rot

Here is the anti-pattern I see in almost every codebase I review:

kotlin
// ❌ 2^3 = 8 possible states, only 3 are valid
data class SearchState(
val isLoading: Boolean = false,
val isError: Boolean = false,
val results: List = emptyList()
)

This compiles. It runs. And it will bite you at 2am when a race condition sets `isLoading = true` and `isError = true` simultaneously, rendering garbage silently. The fix is not better discipline — it is making invalid states unrepresentable.

---

## Step 2 — Model state as a sealed interface

Kotlin sealed interfaces are exhaustive by design. The `when` expression will not compile unless you handle every branch. Here is the minimal setup to get this working:

kotlin
// ✅ Only 4 valid states can exist
sealed interface SearchUiState {
data object Idle : SearchUiState
data object Loading : SearchUiState
data class Success(val results: List) : SearchUiState
data class Error(val message: String) : SearchUiState
}

Events follow the same pattern:

kotlin
sealed interface SearchEvent {
data class QueryChanged(val query: String) : SearchEvent
data object RetryClicked : SearchEvent
data object ClearClicked : SearchEvent
}

Let me show you a pattern I use in every project: keep states and events in the same file, named after the screen. `SearchUiState.kt` with both sealed interfaces is a single-glance contract for the entire screen.

---

## Step 3 — Write the pure reducer

A reducer is a pure function: `(State, Event) -> State`. No side effects, no coroutine launches, no repository calls. This makes it trivially unit-testable — twenty lines, zero mocks.

kotlin
fun reduce(state: SearchUiState, event: SearchEvent): SearchUiState =
when (event) {
is SearchEvent.QueryChanged -> SearchUiState.Loading
SearchEvent.RetryClicked -> SearchUiState.Loading
SearchEvent.ClearClicked -> SearchUiState.Idle
}

If your reducer is hard to unit test, it is doing too much.

---

## Step 4 — Wire it together with StateFlow

kotlin
class SearchViewModel(private val repo: SearchRepository) : ViewModel() {

private val _state = MutableStateFlow<SearchUiState>(SearchUiState.Idle)
val state: StateFlow<SearchUiState> = _state.asStateFlow()

fun onEvent(event: SearchEvent) {
    _state.update { current -> reduce(current, event) }
    handleSideEffect(event)
}

private fun handleSideEffect(event: SearchEvent) {
    if (event is SearchEvent.QueryChanged) {
        viewModelScope.launch {
            _state.value = try {
                SearchUiState.Success(repo.search(event.query))
            } catch (e: Exception) {
                SearchUiState.Error(e.message ?: "Unknown error")
            }
        }
    }
}

}

In Compose, bind with `collectAsStateWithLifecycle()` for lifecycle awareness:

kotlin
val state by viewModel.state.collectAsStateWithLifecycle()

when (val s = state) {
SearchUiState.Idle -> IdleScreen()
SearchUiState.Loading -> LoadingIndicator()
is SearchUiState.Success -> ResultsList(s.results)
is SearchUiState.Error -> ErrorMessage(s.message)
}

The compiler enforces exhaustiveness. You cannot forget the error case.

---

## Pattern comparison

| Approach | Invalid states possible | Testable reducer | Compiler-enforced |
|---|---|---|---|
| Boolean flags | Yes (2ⁿ combos) | Difficult | No |
| Sealed class + `isLoading` hybrid | Partially | Partial | No |
| **Strict MVI + sealed interface** | **No** | **Yes** | **Yes** |

---

## Gotchas

**Do not launch coroutines inside the reducer.** The moment you add `viewModelScope.launch` there, you have broken purity and your tests need mocks. Keep the reducer a pure mapping function and push side effects to `handleSideEffect`.

**React to state, not to events, in `LaunchedEffect`.** Triggering a network call from `state == Loading` rather than from the event means recomposition cannot cause double-fetches. The docs do not emphasise this enough — it is easy to get wrong and genuinely annoying to track down when you do.

**Three `is*` booleans on the same concern is the tell.** When you spot `isLoading`, `isError`, and `hasData` sitting together, that is a sealed interface waiting to be written — not a discipline problem, a modeling problem.

---

## Conclusion

Once a codebase commits to strict MVI, that whole category of state-related bugs disappears — not because developers became more careful, but because the compiler stopped allowing those states to exist. Start with the next screen you write. Find three boolean flags, replace them with a sealed interface, and watch the `when` expression do your QA for free.

**Further reading:**
- [Kotlin sealed interfaces — official docs](https://kotlinlang.org/docs/sealed-classes.html)
- [StateFlow and SharedFlow — Android docs](https://developer.android.com/kotlin/flow/stateflow-and-sharedflow)
- [collectAsStateWithLifecycle — lifecycle-runtime-compose](https://developer.android.com/reference/kotlin/androidx/lifecycle/compose/package-summary)