El esqueleto mínimo: estado privado, estado público e intents

Después de doce niveles apoyados en Orbit conviene hacerse una pregunta incómoda: ¿cuánto de lo aprendido era la librería y cuánto era la arquitectura? La respuesta, que sorprende la primera vez, es que la arquitectura completa cabe en unas pocas docenas de líneas de Kotlin sin una sola dependencia externa. MVI no es un artefacto que se instala: es un contrato sobre quién puede escribir el estado, quién puede leerlo y por dónde entran los cambios. Ese contrato se puede expresar con tres construcciones del lenguaje que ya conoces —un flujo mutable confinado, su proyección de solo lectura y una función de entrada— y el resultado no es una versión degradada de Orbit sino el mismo modelo mental sin azúcar. Construirlo a mano una vez es la forma más rápida de dejar de tratar la librería como magia y empezar a tratarla como una decisión.

La asimetría entre escribir y leer

El corazón del esqueleto es una asimetría deliberada. Dentro del componente vive un MutableStateFlow con visibilidad privada; hacia fuera se expone el mismo objeto proyectado como StateFlow, que carece de métodos de escritura. La interfaz recibe un valor que puede observar y no puede alterar, y esa imposibilidad no es una convención documentada sino una propiedad del tipo, verificada por el compilador en cada punto de uso.

class CarritoViewModel(
    private val repo: CarritoRepo,
) : ViewModel() {

    private val _estado = MutableStateFlow(CarritoState())
    val estado: StateFlow<CarritoState> = _estado.asStateFlow()
}

Merece la pena detenerse en asStateFlow. Una alternativa frecuente es declarar la propiedad pública con el tipo StateFlow y asignarle directamente el flujo mutable, confiando en que el tipo declarado baste. Bastaría en Kotlin puro, pero no protege frente a una conversión descendente en tiempo de ejecución ni frente a consumidores escritos en otro lenguaje de la JVM. La llamada a asStateFlow devuelve un envoltorio distinto que no es el mismo objeto y que, por tanto, no puede recuperarse con un as oportunista. El coste es una asignación por instancia de pantalla; la garantía es que la única ruta de escritura del estado es la que tú has escrito.

flowchart LR
U[Interfaz] -->|envia intent| P[Funcion procesar]
P --> R[Reducer puro]
R --> M[MutableStateFlow privado]
M --> S[StateFlow publico de solo lectura]
S --> U
style M fill:#f9e2af,color:#11111b
style S fill:#a6e3a1,color:#11111b

El diagrama muestra un ciclo, no una línea, y esa circularidad es el sello de MVI: la interfaz nunca escribe estado, solo emite intenciones; el estado nunca invoca a la interfaz, solo cambia de valor y deja que la observación haga el resto. Un StateFlow encaja aquí porque cumple tres propiedades a la vez que la pantalla necesita: siempre tiene un valor actual, conflada los cambios rápidos y entrega el último valor a cada nuevo suscriptor. Esa última es la que hace que una rotación de pantalla no pierda nada: el observador nuevo recibe inmediatamente el estado vigente.

Una sola puerta de entrada

La segunda pieza es una función que recibe intenciones. Su firma importa más que su cuerpo: acepta un tipo sellado y no devuelve nada útil, con lo que declara que la única forma de influir en el componente es enviarle un valor de ese vocabulario cerrado.

sealed interface CarritoIntent {
    data object Cargar : CarritoIntent
    data class CambiarCantidad(val id: String, val cantidad: Int) : CarritoIntent
    data class Borrar(val id: String) : CarritoIntent
}

fun procesar(intent: CarritoIntent) {
    when (intent) {
        CarritoIntent.Cargar -> cargar()
        is CarritoIntent.CambiarCantidad -> cambiarCantidad(intent.id, intent.cantidad)
        is CarritoIntent.Borrar -> borrar(intent.id)
    }
}

Que la función sea única no es una cuestión estética. Una clase con quince métodos públicos ofrece quince superficies de entrada, y nada impide que un compañero añada la decimosexta sin que nadie lo note. Una clase con un solo método público cuyo parámetro es un tipo sellado ofrece exactamente tantas entradas como casos tenga ese tipo, y ampliarlas obliga a tocar un fichero que la revisión de código mira siempre. La unidireccionalidad deja de depender de la disciplina y pasa a ser legible en la firma.

El despacho con when exhaustivo añade la segunda garantía: añadir un intent nuevo rompe la compilación aquí hasta que alguien decida qué hacer con él. Es el mismo mecanismo que sostiene el consumo de efectos, aplicado a la entrada en vez de a la salida.

Conviene además que la función no devuelva nada aprovechable. La tentación de que retorne el estado resultante, o un valor que indique si la intención fue aceptada, parece una comodidad y rompe el modelo: si el emisor puede leer una respuesta directa, ya existe un segundo canal de información fuera del estado, y la interfaz empezará a tomar decisiones con ese valor en vez de con lo que observa. Todo lo que el mundo exterior debe saber tiene que llegarle por el estado o por un efecto, sin excepciones.

El reducer puro y el trabajo que lo rodea

El error más común al escribir MVI a mano es meter la llamada de red dentro de la misma función que calcula el estado nuevo. Conviene mantener dos capas bien distintas: una función pura que dado un estado y un hecho produce el estado siguiente, y unas corrutinas que producen esos hechos hablando con el mundo.

private fun reduce(estado: CarritoState, intent: CarritoIntent): CarritoState =
    when (intent) {
        is CarritoIntent.CambiarCantidad ->
            estado.copy(lineas = estado.lineas.map {
                if (it.id == intent.id) it.copy(cantidad = intent.cantidad) else it
            })
        else -> estado
    }

private fun cargar() = viewModelScope.launch {
    _estado.update { it.copy(cargando = true) }
    val lineas = repo.lineas()
    _estado.update { it.copy(cargando = false, lineas = lineas) }
}

La llamada a update merece explicación, porque la alternativa evidente es asignar directamente a la propiedad de valor. La asignación directa lee y escribe en dos pasos, y entre ambos puede colarse otra corrutina que también escriba: el clásico problema de lectura, modificación y escritura no atómica. La función update aplica la transformación mediante una comparación e intercambio en bucle, de modo que si otro escritor se adelantó, el bloque se reejecuta sobre el valor nuevo. El precio es que ese bloque debe ser puro y barato, porque puede ejecutarse varias veces; si dentro haces una llamada suspendida o registras una métrica, tendrás efectos duplicados sin saber por qué.

Hay un segundo detalle del StateFlow que conviene interiorizar pronto porque explica muchas sorpresas: la emisión está condicionada por la igualdad. Si el valor nuevo es igual al anterior según su comparación estructural, el flujo no emite nada y los observadores no se enteran. Con estados modelados como clases de datos inmutables eso es justo lo que quieres, porque convierte una reducción idempotente en una recomposición evitada. Pero explica también un fallo desconcertante: si tu estado contiene una lista mutable y la modificas en el sitio antes de asignarla, la comparación dará igualdad y la interfaz no se actualizará jamás, sin ningún error visible.

Merece señalarse una asimetría entre este esqueleto y lo que enseñan los tratamientos canónicos de MVI. En la formulación estricta, cada acción del usuario produce un intent, cada respuesta del mundo produce un hecho, y solo los hechos alimentan el reducer. Aquí hemos colapsado ambos vocabularios en uno solo por brevedad, lo cual funciona perfectamente en pantallas medianas y empieza a doler cuando una operación tiene varias etapas observables: en ese momento el tipo de intents acumula casos que el usuario nunca puede provocar, como la llegada de una respuesta o el vencimiento de un temporizador. Cuando eso ocurra, separar los dos vocabularios no es purismo sino higiene, y el coste es un tipo sellado adicional.

Queda una decisión de estilo con consecuencias reales: si el trabajo asíncrono se lanza desde el despacho o desde el reducer. La respuesta correcta es siempre desde el despacho, nunca desde el reducer, y la razón es que el reducer debe poder ejecutarse en un test sin ningún alcance de corrutinas. Un reducer que lanza trabajo obliga a que cada prueba suya monte infraestructura, y en cuanto eso ocurre las pruebas de transiciones dejan de escribirse porque cuestan demasiado.

Este esqueleto tiene además un silencio importante que conviene nombrar antes de cerrarlo, porque será el hilo de las lecciones siguientes: no dice absolutamente nada sobre qué ocurre si dos intents se procesan a la vez. Cada llamada lanza su propia corrutina y ninguna espera a las demás, de modo que dos operaciones lentas pueden intercalar sus reducciones en cualquier orden. En el camino feliz eso no se nota; con una red lenta y un usuario impaciente, sí. Que treinta líneas basten para el patrón no significa que basten para la concurrencia, y confundir ambas cosas es el error más caro que se comete al abandonar una librería.