El modelo mental completo: intent, reduce, estado y efecto

Un modelo mental no es un resumen de lo aprendido: es la estructura mínima que te permite deducir el resto cuando no recuerdas los detalles. Después de veinte niveles de piezas sueltas —tipos sellados, reductores puros, flujos calientes, canales de efectos, recomposición y estabilidad— llega el momento de comprobar si todo eso colapsa en algo que quepa en la cabeza a la vez. La respuesta es que sí, y que cabe en menos de lo que parece: cuatro piezas, un bucle, dos garantías y dos motores. Lo demás son consecuencias. Si has entendido bien este nivel, no necesitarás recordar cómo se escribía un Channel ni qué hacía flatMapLatest, porque sabrás deducir qué pieza corresponde a cada problema y qué garantía se rompe si eliges mal.

Cuatro piezas y un bucle

El bucle entero se enuncia en una frase que conviene saber decir sin titubear: una intención entra como dato, un reductor puro la convierte en un estado nuevo, la interfaz se redibuja desde ese estado, y todo lo que no es estado sale por un canal aparte de una sola vez. Cada palabra de esa frase está pagada con una lección del track.

Que la intención sea un dato y no una llamada a un método es lo que permite encolarla, registrarla, reproducirla y comprobar exhaustivamente en un when que ninguna quedó sin tratar. Una llamada se ejecuta y desaparece; un valor persiste y se puede examinar. Ese cambio de registro —de verbo a sustantivo— es el que convierte una sesión de usuario en una lista de valores, y una lista de valores es algo que se puede doblar, guardar y volver a aplicar.

Que el reductor sea puro es lo que permite afirmar el comportamiento sin ejecutarlo. Sin reloj, sin azar, sin red, sin registro, sin this. Su única salida es el valor devuelto, y por eso un test suyo es una aserción sobre valores y no una coreografía de dobles y esperas.

Que el estado sea inmutable y comparable por igualdad es lo que permite a Compose decidir qué saltarse. Un data class con copy produce un valor nuevo por transición, y la comparación entre el valor viejo y el nuevo es la señal que gobierna toda la recomposición aguas abajo.

Que el efecto viaje por un canal aparte es lo que reconoce que hay dos semánticas incompatibles: el estado converge y se puede releer, el efecto se entrega una vez y no se relee. Meter una navegación en el estado es pedirle a una estructura que converge que se comporte como una que no.

flowchart LR
U[Gesto del usuario] --> I[Intent como dato]
I --> C[Container secuencial]
C --> R[Reduce puro]
R --> S[Estado inmutable]
S --> V[Compose redibuja]
V --> U
C --> E[Canal de efectos]
E --> V
style R fill:#cba6f7,color:#11111b
style S fill:#a6e3a1,color:#11111b
style E fill:#f9e2af,color:#11111b

Sobre ese bucle se apoyan dos garantías que hay que saber nombrar porque son las que se pierden primero cuando alguien improvisa. La primera es la unidireccionalidad: la interfaz nunca escribe en el modelo, solo envía intenciones; el modelo nunca lee de la interfaz, solo publica estado. La segunda es la serialización de las transiciones: por muchas corrutinas que haya en vuelo, las reducciones se aplican de una en una sobre el estado más reciente, de modo que nunca dos transiciones parten de la misma fotografía.

Conviene ver las cuatro piezas escritas juntas una vez, porque la declaración completa de una pantalla cabe en una pantalla de editor y esa brevedad es parte del argumento.

// 1. El estado: un valor inmutable, comparable por igualdad
data class PerfilState(
    val cargando: Boolean = false,
    val perfil: Perfil? = null,
    val error: String? = null,
)

// 2. Las intenciones: un tipo cerrado con todo lo que puede ocurrir
sealed interface PerfilIntent {
    data object PantallaMostrada : PerfilIntent
    data class SeguirPulsado(val id: String) : PerfilIntent
}

// 3. Los efectos: lo que sale una sola vez y no se relee
sealed interface PerfilEfecto {
    data class Avisar(val mensaje: String) : PerfilEfecto
    data object VolverAtras : PerfilEfecto
}

// 4. El reductor: funcion libre, pura, total
fun reducir(estado: PerfilState, intent: PerfilIntent): PerfilState = when (intent) {
    PerfilIntent.PantallaMostrada -> estado.copy(cargando = true, error = null)
    is PerfilIntent.SeguirPulsado -> estado
}

Léelo buscando lo que no hay. No hay una referencia a Context. No hay una llamada suspendible. No hay una excepción que escape. No hay un else que oculte un caso sin decidir. Las cuatro ausencias son el contrato entero, y cada una de ellas es la que hace posible una garantía distinta: la primera permite probar en la JVM, la segunda permite serializar las transiciones, la tercera permite que todo fallo sea visible en el estado y la cuarta permite que añadir una intención rompa la compilación hasta que alguien decida qué hace.

Dónde entra la corrutina

El error más común al integrar corrutinas con MVI es creer que la concurrencia entra en el reductor. No entra, y la razón es estructural: si el reductor pudiera suspenderse, la garantía de serialización se rompería, porque entre la lectura del estado y la escritura del siguiente cabría otra transición entera. Por eso el reparto es rígido y merece memorizarse: el trabajo suspendible ocurre en el intent, la transición ocurre en el reduce, y el reduce no suspende nunca.

fun cargarPerfil(id: String) = intent {
    reduce { state.copy(cargando = true, error = null) }
    val resultado = runCatching { repositorio.perfil(id) }  // suspende aqui
    reduce {
        resultado.fold(
            onSuccess = { state.copy(cargando = false, perfil = it) },
            onFailure = { state.copy(cargando = false, error = it.mensajeUsuario()) },
        )
    }
    resultado.onFailure { postSideEffect(PerfilEfecto.Avisar("No se pudo cargar")) }
}

Léelo como una alternancia: reduce, suspende, reduce. Cada bloque reduce es un instante indivisible; entre ellos el mundo puede cambiar, y por eso el segundo reduce lee state de nuevo en vez de confiar en el que vio el primero. Esa relectura no es un detalle de estilo: es la única forma de que una respuesta lenta no pise el trabajo de una intención posterior.

El resto del encaje se sigue de la concurrencia estructurada. El ámbito de las corrutinas es el del ViewModel, de modo que cuando la pantalla muere de verdad, todo el trabajo en vuelo se cancela solo. La cancelación es cooperativa, lo que significa que tu código bloqueante no la respeta a menos que compruebe el estado del trabajo o llame a funciones suspendibles que lo hagan por él. Y los errores no se propagan hacia arriba por su cuenta: se capturan en el borde del intent y se traducen a estado, porque un fallo que solo existe en una excepción es un fallo que la interfaz no puede mostrar.

Dónde entra Compose

Compose no participa del bucle: lo consume. Su contrato con MVI es de una simplicidad engañosa —recibe un estado y produce una descripción de interfaz— y toda la complejidad real está en decidir qué partes de esa descripción hay que volver a producir cuando el estado cambia. Esa decisión la toma comparando: si un parámetro es igual al de la composición anterior y su tipo es estable, la función se salta entera.

De ahí se sigue por qué MVI y Compose encajan tan bien y por qué el encaje se rompe con tanta facilidad. Encajan porque un data class inmutable de tipos estables da exactamente la señal que el runtime necesita. Se rompe en cuanto el estado contiene una List mutable, una lambda recreada en cada composición o un tipo de un módulo que el compilador no puede inferir como estable, porque entonces la comparación devuelve siempre desigual y el ahorro desaparece sin que nada lo avise.

@Composable
fun PerfilRoute(vm: PerfilViewModel = hiltViewModel()) {
    val state by vm.container.stateFlow.collectAsStateWithLifecycle()
    LaunchedEffect(Unit) {
        vm.container.sideEffectFlow.collect { efecto ->
            when (efecto) {
                is PerfilEfecto.Avisar -> mostrarAviso(efecto.mensaje)
                PerfilEfecto.VolverAtras -> navegar.popBackStack()
            }
        }
    }
    PerfilScreen(state = state, onIntent = vm::enviar)
}

Fíjate en el reparto: el componente de ruta habla con el ViewModel, colecciona el estado con conciencia del ciclo de vida y consume los efectos en un efecto lanzado; el componente de pantalla es una función del estado que no conoce el ViewModel y por eso se puede previsualizar, probar y reutilizar. Esa frontera es la versión Compose del state hoisting, y coincide exactamente con la frontera que MVI ya había trazado por otros motivos.

Las cuatro costuras

Un modelo mental maduro incluye sus propios límites. Estas son las cuatro costuras por donde el bucle se abre, y en cada una la respuesta correcta es reconocer que el modelo no cubre el caso, no forzarlo.

Hay un patrón común detrás de las cuatro: todas aparecen cuando se aplica una regla que era correcta en su dominio fuera de él. El estado único es correcto para la lógica de la pantalla y equivocado para el cursor de un campo de texto. El canal de efectos es correcto para un aviso y equivocado para una confirmación legal. Reconocer el dominio de validez de cada regla es exactamente lo que separa a quien aplica una arquitectura de quien la entiende.

De las cuatro, la que más discusiones inútiles genera es la tercera, y merece un ejemplo porque la solución es menos obvia de lo que parece. La tentación ante una pantalla con secciones independientes es multiplicar los containers, uno por sección, y esa salida rompe la garantía de serialización precisamente en el único sitio donde importaba: en las reglas que cruzan secciones. La salida correcta es un solo container con el estado compuesto de subestados.

data class PedidoState(
    val carrito: CarritoState = CarritoState(),
    val pago: PagoState = PagoState(),
    val fase: Fase = Fase.Editando,
) {
    // Regla que cruza secciones: vive en el padre porque solo el las ve juntas
    val puedeConfirmar: Boolean get() = carrito.lineas.isNotEmpty() && pago.valido
}

Ese puedeConfirmar como propiedad calculada, y no como campo guardado, es un detalle con consecuencias: un valor derivado que se almacena es una segunda verdad que hay que mantener sincronizada a mano, y toda verdad duplicada acaba divergiendo. La regla general que se sigue de ahí vale para cualquier estado: guarda lo que no se puede deducir y calcula lo que sí.

Queda una pregunta que casi todo el mundo se hace al llegar aquí y que conviene responder sin adornos: ¿merece la pena todo esto para una pantalla de dos campos? No, y decirlo forma parte del modelo mental. El bucle completo compra la eliminación de estados imposibles, la comprobabilidad sin instrumentación y la reproducción de fallos; si una pantalla no tiene estados imposibles que eliminar ni fallos difíciles que reproducir, no había nada que comprar y la ceremonia es coste puro. El criterio no es aplicar el patrón en todas partes, sino saber qué señales indican que ya hace falta: más de tres campos que se condicionan entre sí, trabajo asíncrono que puede solaparse, o un bug que nadie consigue reproducir.