El ciclo intent → reduce → render

Ya tienes las dos mitades del patrón: en las lecciones anteriores modelaste el Intent como la entrada del sistema y el Model como su salida. Falta el tejido que las une, y ese tejido es un ciclo de tres tiempos que se repite mientras la pantalla siga viva. Un intent entra, una función lo reduce a un estado nuevo, y la vista se vuelve a dibujar a partir de ese estado: intent, reduce, render. La palabra decisiva es ciclo, no secuencia. Cuando el usuario toca la pantalla recién pintada no reanuda un hilo que venía de antes, sino que arranca otra vuelta idéntica emitiendo un intent nuevo. Sobre un único StateFlow inmutable, esa vuelta se cierra sobre sí misma una y otra vez, y toda la vida de la interfaz cabe en ese giro que no se detiene.

El ciclo como una sola vuelta

Una vuelta de MVI tiene tres tiempos y ni uno más. Primero, la vista emite un Intent: el usuario tocó algo y esa interacción se convirtió en un dato que entra por onIntent. Segundo, reduce toma ese intent junto al estado vigente y calcula el estado siguiente, sin tocar nada del mundo exterior. Tercero, ese estado nuevo se publica en el StateFlow y la vista, que lo está observando, se redibuja. Ahí termina la vuelta. Si el usuario vuelve a actuar sobre la pantalla ya redibujada, no continúa donde lo dejó: empieza una vuelta nueva, con la misma forma exacta.

flowchart LR
U[usuario toca la pantalla] --> I[emite un Intent]
I --> OI[onIntent]
OI --> RD[reduce estado mas intent]
RD --> NS[StateFlow publica estado nuevo]
NS --> RE[Compose recompone]
RE --> U
style I fill:#89b4fa,color:#11111b
style RD fill:#f9e2af,color:#11111b
style NS fill:#a6e3a1,color:#11111b
style RE fill:#cba6f7,color:#11111b

Fíjate en que ninguna flecha va hacia atrás dentro de una misma vuelta. La vista no escribe en el estado; el estado no llama a la vista para ordenarle que se pinte. Cada tramo entrega su resultado al siguiente y se desentiende. Esa geometría —la misma del flujo unidireccional del nivel 17, ahora hablada en Kotlin— es la que permite razonar sobre la pantalla como sobre un bucle de tres pasos y no como sobre una maraña de callbacks que se llaman entre sí.

reduce: la función pura en el centro

El corazón del ciclo es reduce, y conviene escribirlo como lo que es: una función pura, aislada del ViewModel, que recibe el estado actual y un intent y devuelve el estado siguiente. Nada más entra —ni la hora, ni la red, ni una variable de fuera— y nada más sale que su return. Sacarlo del ViewModel a una función suelta no es capricho: es lo que te deja probarlo pasándole valores, sin montar medio Android alrededor.

data class ContadorState(val cuenta: Int = 0, val paso: Int = 1)

sealed interface ContadorIntent {
    data object Incrementar : ContadorIntent
    data object Decrementar : ContadorIntent
    data class PasoCambiado(val nuevoPaso: Int) : ContadorIntent
}

// reduce: funcion pura, aislada del ViewModel. (estado, intent) -> estado nuevo.
fun reduce(estado: ContadorState, intent: ContadorIntent): ContadorState =
    when (intent) {
        ContadorIntent.Incrementar     -> estado.copy(cuenta = estado.cuenta + estado.paso)
        ContadorIntent.Decrementar     -> estado.copy(cuenta = estado.cuenta - estado.paso)
        is ContadorIntent.PasoCambiado -> estado.copy(paso = intent.nuevoPaso)
    }

El ViewModel se limita a orquestar: guarda el estado en un MutableStateFlow, lo expone en solo lectura y, en onIntent, aplica reduce sobre el valor vigente. La pieza clave es update, que lee el estado actual, le aplica tu función y publica el resultado en una sola operación atómica. Si dos corrutinas emiten intents a la vez, update garantiza que ninguna pisa a la otra.

class ContadorViewModel : ViewModel() {
    private val _state = MutableStateFlow(ContadorState())
    val state: StateFlow<ContadorState> = _state.asStateFlow()

    // Punto de entrada unico: publica el estado nuevo de forma atomica.
    fun onIntent(intent: ContadorIntent) {
        _state.update { actual -> reduce(actual, intent) }
    }
}

render: Compose recompone y cierra el bucle

Falta el tercer tiempo, y es el que menos se parece a lo que dictaría la intuición imperativa: tú nunca ordenas que se dibuje. La vista se suscribe al StateFlow con collectAsStateWithLifecycle, que convierte cada valor emitido en estado observable de Compose y, de paso, deja de recolectar cuando la pantalla no está visible. Cuando reduce publica un estado nuevo, Compose lo detecta y reprograma la recomposición de los componibles que leyeron ese estado. Render no es una instrucción que das: es la consecuencia automática de que el estado cambió.

// Componible con estado: recolecta el flujo y delega el dibujo.
@Composable
fun ContadorScreen(vm: ContadorViewModel = viewModel()) {
    val estado by vm.state.collectAsStateWithLifecycle()
    ContadorContenido(estado = estado, onIntent = vm::onIntent)
}

// Componible sin estado: funcion pura del estado, previsualizable y testeable.
@Composable
fun ContadorContenido(estado: ContadorState, onIntent: (ContadorIntent) -> Unit) {
    Column {
        Text("Cuenta: ${estado.cuenta} (paso ${estado.paso})")
        Button(onClick = { onIntent(ContadorIntent.Incrementar) }) { Text("Mas") }
        Button(onClick = { onIntent(ContadorIntent.Decrementar) }) { Text("Menos") }
    }
}

El corte en dos componibles no es adorno. El de arriba tiene estado —recolecta el flujo y conoce el ViewModel—; el de abajo es una función pura del estado que recibe, así que se previsualiza y se prueba pasándole un ContadorState cualquiera y una lambda vacía. Esa separación, el state hoisting de Compose, es la que vuelve literal la ecuación vista = f(estado): el contenido no sabe de dónde vino el estado ni a dónde van los intents, solo pinta lo que le dan y avisa de lo que el usuario quiso.

Hay un dividendo de rendimiento en esta última parte que conviene ver. Compose no repinta la pantalla entera cuando el estado cambia: gracias a su sistema de snapshots, solo vuelven a ejecutarse los componibles que leyeron el trozo de estado que cambió, y las anotaciones de estabilidad del nivel anterior le permiten saltarse subárboles que reciben el mismo valor. Por eso un estado único inmutable no implica recomponer de más: implica recomponer exactamente lo que dejó de ser cierto, ni un píxel más.

Una vuelta que sale al mundo y regresa

El contador no toca el exterior, pero casi ninguna pantalla real es tan pura. En cuanto hay una carga de datos, un solo intent no basta para cerrar el trabajo: dispara un efecto que tarda, y el resultado tiene que volver a entrar por el ciclo como un intent nuevo. El molde es siempre el mismo. onIntent recibe la intención de cargar, reduce el estado al modo de carga y, en la misma llamada, lanza una corrutina que hará el trabajo lento; cuando esa corrutina termina, no escribe el estado a mano, sino que emite otro intent —el que transporta el resultado— y deja que reduce lo pliegue.

fun onIntent(intent: TareasIntent) {
    when (intent) {
        TareasIntent.Cargar -> {
            _state.update { reduce(it, intent) }        // pasa al modo de carga
            viewModelScope.launch {
                val items = repo.cargar()               // efecto: tarda y puede fallar
                onIntent(TareasIntent.Recibidas(items)) // el resultado reentra por el ciclo
            }
        }
        else -> _state.update { reduce(it, intent) }
    }
}

Observa la simetría: tanto la intención del usuario como la respuesta de la red entran por la misma puerta y se pliegan con la misma función pura. El efecto —la parte impura, la que espera y puede fallar— queda confinado a la corrutina, mientras que el estado solo cambia doblando intents. Una carga, vista así, no son dos mecanismos distintos: son dos vueltas del mismo bucle, una que sale al mundo y otra que trae lo que el mundo respondió.