Sobre coroutines y Flow: Orbit es Kotlin asíncrono

Cuatro lecciones atrás quedó una promesa pendiente. Cuando presentamos Orbit dijimos que su grandeza no estaba en lo que añade sino en lo que se atreve a no añadir: que era una convención sobre coroutines, no un motor por encima de ellas. Y en la lección de intent prometimos volver sobre esa integración con corrutinas al final del nivel. Este es el final. Aquí verás que la frase no era retórica: intent es literalmente una corrutina, el estado es literalmente un StateFlow de la biblioteca estándar, los side effects viajan por un Flow respaldado por un Channel, y la cancelación es la concurrencia estructurada de Kotlin sin un solo adaptador de por medio. Orbit no habla un idioma asíncrono propio que haya que traducir al de tu app: habla el mismo, porque no hay otro.

intent es Kotlin asíncrono, sin adaptadores

Ya lo insinuamos al presentar intent: no es un método que ejecutas, es un bloque que lanza una corrutina sobre el scope del container. Lo que no habíamos desplegado es hasta dónde llega esa afirmación. Dentro de un intent estás en tierra suspend sin restricción alguna: puedes esperar un repositorio, paralelizar con async y await, abrir un coroutineScope hijo, cambiar de dispatcher con withContext o coleccionar un Flow que emite para siempre. No hay una API asíncrona de Orbit que aprender por encima; hay corrutinas, y punto.

// 1. Suspender y paralelizar: async/await dentro del intent
fun cargar(id: String) = intent {
    reduce { state.copy(cargando = true) }
    coroutineScope {
        val perfil = async { repo.perfil(id) }   // suspende, no bloquea
        val posts  = async { repo.posts(id) }
        reduce { state.copy(perfil = perfil.await(), posts = posts.await(), cargando = false) }
    }
}

// 2. Coleccionar un Flow vivo: el intent no termina, reacciona
fun observar(id: String) = intent {
    repo.mensajesFlow(id).collect { lista ->
        reduce { state.copy(mensajes = lista) }
    }
}

Lee el primero como Kotlin corriente: coroutineScope abre un ámbito hijo, los dos async disparan trabajo en paralelo y el reduce no ocurre hasta que ambos await han resuelto. Si cualquiera de las dos llamadas falla, la concurrencia estructurada cancela a su hermana y propaga el error hacia arriba sin dejar corrutinas huérfanas. Nada de eso es API de Orbit; es el comportamiento por defecto de un ámbito de corrutinas.

El segundo intent merece una pausa: no retorna nunca, se queda coleccionando el Flow de la base de datos y reduciendo en cada emisión. En una arquitectura con suscripciones manuales tendrías que recordar cancelarla —y olvidarlo es la fuente clásica de fugas de memoria—. Aquí no cancelas nada: como la corrutina cuelga de viewModelScope, la concurrencia estructurada la termina en cuanto el ViewModel se destruye, junto con toda su descendencia. La cancelación no es una función de Orbit; es la de Kotlin, heredada gratis.

Esa corrutina viva se puede afinar aún más. En la lección del container viste que Orbit ofrece variantes de sus flujos con conteo de suscriptores; repeatOnSubscription es el envés de esa moneda dentro del intent: envuelve una colección para que solo se ejecute mientras alguien mira la pantalla y se pause cuando el último coleccionista se va, reanudándose al volver. Así, observar la base de datos no consume recursos con la app en segundo plano, y sigues sin escribir una sola línea de gestión de ciclo de vida.

StateFlow y Flow: reutilizar la maquinaria, no reinventarla

La misma economía gobierna la salida. Viste en la lección del container que el estado se expone como StateFlow<STATE> y los side effects como Flow<SIDE_EFFECT> sobre un Channel. Lo que importa entender ahora es que esos son tipos de la biblioteca de corrutinas, no envoltorios propios de Orbit. La consecuencia es enorme y silenciosa: Orbit no inventa su sistema de suscripción, ni su planificador, ni su modelo de contrapresión, ni su forma de cancelar. Reutiliza el de coroutines, que ya es idiomático, está probado y lo conoce cualquiera que escriba Kotlin.

El contraste con la generación anterior es instructivo. Las arquitecturas MVI construidas sobre RxJava sí traían mundo propio: un Observable que no era el Flow de nadie más, un Disposable que había que acordarse de liberar, un Scheduler que aprender aparte de los dispatchers. Cada una de esas piezas era una segunda verdad sobre la asincronía que convivía, a menudo mal, con la del resto del proyecto. Al plantarse sobre Flow, Orbit borra la duplicidad: no hay un modelo asíncrono de la librería y otro de la app, hay uno solo.

Exponer un tipo estándar es lo que hace que el estado componga con el resto del mundo sin adaptadores. Un StateFlow es un Flow, así que aguas abajo puedes transformarlo con los operadores de siempre:

// El estado es un StateFlow normal: compone con la biblioteca estandar
val nombresVisibles: Flow<List<String>> =
    viewModel.container.stateFlow
        .map { estado -> estado.usuarios.filter { it.visible }.map { it.nombre } }
        .distinctUntilChanged()

Si el estado fuera un tipo cerrado de Orbit, cada una de esas operaciones exigiría un puente. Al ser Flow, no exige ninguno: map, combine, flatMapLatest, coleccionarlo en Compose con collectAsStateWithLifecycle o entregarlo a otra capa son gestos que ya sabes hacer. La superficie que Orbit no ocupa la ocupa Kotlin.

flowchart LR
KT[Biblioteca de corrutinas de Kotlin] --> I[intent es una corrutina]
KT --> S[StateFlow expone el estado]
KT --> C[Channel respalda los side effects]
KT --> V[viewModelScope cancela en cascada]
I --> O[Orbit solo pone los nombres]
S --> O
C --> O
V --> O
style KT fill:#89b4fa,color:#11111b
style O fill:#cba6f7,color:#11111b

Orbit en el mapa: a mano, Mavericks, Ballast

Conviene situar a Orbit entre sus vecinos para ver qué defiende. Todas estas opciones implementan el mismo bucle unidireccional que estudiaste; se diferencian en cuánta maquinaria propia interponen entre tú y las corrutinas.

El eje que ordena la tabla es sencillo. El MVI a mano no interpone maquinaria, pero te obliga a mantenerla y a no equivocarte con la concurrencia; Mavericks y Ballast interponen bastante y te dan a cambio funciones listas para usar; Orbit interpone lo mínimo que todavía merece llamarse librería. Ninguno es incorrecto: son puntos distintos en el compromiso entre control y comodidad. Lo que Orbit apuesta es que, con coroutines debajo, el punto óptimo está mucho más cerca del mínimo de lo que la industria creyó durante años.

Traducido a una decisión práctica: si arrancas un proyecto nuevo, y sobre todo si es Multiplatform, Orbit te da MVI correcto con la menor superficie posible; si ya vives en un ecosistema Android grande que necesita persistencia de estado y utilidades de carga de fábrica, Mavericks encaja; y si quieres MVI Multiplatform con depuración por viaje en el tiempo e interceptores incluidos, Ballast es la opción con más pilas. Elegir bien es reconocer cuánta maquinaria vas a usar de verdad, no cuánta te ofrecen en el folleto.

Una sola lógica, muchas plataformas

La última pieza cae por su propio peso. Si la lógica de un feature no depende de nada de Android —solo de coroutines, de Flow y de Kotlin puro— entonces puede vivir en commonMain y compilar para todos los objetivos de Kotlin Multiplatform. El ViewModel con su container, sus intent y sus reduce es código común; lo único específico de cada plataforma es la interfaz que colecciona los dos flujos de salida.

flowchart TD
CM[commonMain con ViewModel container intent reduce] --> AND[Android colecciona con Compose]
CM --> IOS[iOS colecciona con SwiftUI]
CM --> WEB[Escritorio y web coleccionan igual]
style CM fill:#a6e3a1,color:#11111b
style AND fill:#89b4fa,color:#11111b
style IOS fill:#f9e2af,color:#11111b

Ese reparto es la recompensa de haberse apoyado en primitivas neutrales. Android colecciona stateFlow con Compose; iOS lo colecciona desde SwiftUI; escritorio y web hacen lo mismo. La regla de negocio —qué ocurre cuando el login tiene éxito, cómo se serializan las reducciones, qué es estado y qué es un evento de una vez— se escribe una sola vez y se prueba una sola vez, y solo la capa de colección se reescribe por plataforma.

Merece subrayar la asimetría: compartir la lógica no obliga a compartir la interfaz. Puedes escribir la pantalla con Compose en Android y con SwiftUI nativo en iOS —cada plataforma con su propio lenguaje visual— y aun así tener un solo ViewModel, una sola definición de qué es estado y qué es side effect, y una sola batería de tests sobre esa lógica. Es lo contrario del mínimo común denominador: no renuncias a la interfaz nativa para compartir el núcleo, porque lo único que cruza la frontera son dos Flow.

En términos de módulos, eso se traduce en un reparto limpio: el ContainerHost, la data class de estado y la sealed interface de side effects viven en commonMain, mientras que cada androidMain o iosMain aporta solo el arranque propio de su plataforma. La regla para saber qué es común es la misma que recorre todo el nivel: si algo depende únicamente de Kotlin y de corrutinas, sube a commonMain; si toca la plataforma, baja al módulo específico. Orbit no te da esa regla como una función que activar, sino como una consecuencia de no haber atado su núcleo a ninguna plataforma.