Modelar los intents: la intención del usuario como tipo

Todo el edificio de MVI descansa sobre una decisión que parece menor y es fundacional: convertir la interacción en dato. Mientras la acción del usuario viva como una llamada a un método —guardar(), recargar(), borrarFila(id)— la interfaz está dando órdenes, y quien da órdenes decide; decidir es lógica, y esa lógica acaba de mudarse a la capa que menos debería tenerla. Un intent invierte el sentido de la flecha. La vista no manda: informa. Dice “el usuario pulsó el botón de guardar”, “el usuario escribió esto en el campo”, “la pantalla apareció”, y calla. Qué se hace con esa noticia es asunto de otro. Esta lección trata de cómo se construye ese vocabulario de noticias y por qué la elección de cada nombre —un gesto que parece cosmético— determina, más que ninguna otra cosa, dónde va a terminar viviendo la lógica de tu aplicación.

El intent como acta, no como orden

En Kotlin el vocabulario de una pantalla se escribe con un sealed interface: un tipo cuyas implementaciones están cerradas y son conocidas por el compilador. Cada miembro es un hecho que puede ocurrir. Cuando el hecho no lleva información asociada basta un data object, porque solo hay una forma posible de que ocurra. Cuando el hecho arrastra un dato —el texto tecleado, el identificador tocado— la carga viaja dentro de una data class.

sealed interface CarritoIntent {
    data object PantallaMostrada : CarritoIntent
    data class CantidadCambiada(val linea: String, val unidades: Int) : CarritoIntent
    data class LineaDeslizada(val linea: String) : CarritoIntent
    data class CuponEscrito(val texto: String) : CarritoIntent
    data object CuponAplicadoPulsado : CarritoIntent
    data object ReintentoPulsado : CarritoIntent
}

Antes de seguir, una aclaración que ahorra confusiones: este Intent no tiene ninguna relación con android.content.Intent, el mensajero del sistema que arranca actividades y servicios. Comparten nombre por un accidente histórico y nada más. Aquí un intent es un tipo tuyo, de dominio, que no sale nunca de tu módulo de presentación.

Léelo como un acta y no como una API. No dice qué debe hacer el sistema; dice qué pasó en el mundo. PantallaMostrada no ordena cargar nada: constata que la pantalla se mostró. Que de ese hecho se siga una carga de red es una consecuencia que decide el reducer, y podría cambiar mañana sin tocar ni una línea de la vista. Esa independencia entre el hecho y su consecuencia es exactamente la costura por donde MVI separa las responsabilidades.

Nombrar por lo que pasó, no por lo que hay que hacer

La regla se enuncia en una frase y se incumple todos los días: el nombre del intent describe el evento, no el remedio. CargarCarrito es un remedio; PantallaMostrada es un evento. AplicarCupon es un remedio; CuponAplicadoPulsado es un evento. La diferencia parece de estilo y es de arquitectura.

La regla tiene una excepción aparente que conviene desactivar cuanto antes. A veces el hecho no tiene un gesto obvio detrás: el usuario no pulsa nada, simplemente la pantalla aparece. La tentación es llamar a ese intent Cargar, porque es lo que va a provocar. Resiste: el hecho es PantallaMostrada, y lo bueno de nombrarlo así se ve el día que el producto decide que al aparecer no hay que cargar sino restaurar lo cacheado, o cargar solo si pasaron cinco minutos. Con el nombre del hecho esa evolución es una rama del reducer; con el nombre del remedio es un cambio en la vista y probablemente una mentira: un intent llamado Cargar que a veces no carga.

Cuando el intent se llama BorrarLinea, la vista ya ha tomado la decisión de que deslizar significa borrar. Ese conocimiento —una regla de negocio disfrazada de gesto— queda atrapado en el Composable, fuera del alcance de los tests unitarios y fuera del reducer donde debería estar escrito. El día que el producto pida que deslizar archive en lugar de borrar, o que borre solo si la línea no está pagada, la modificación aterriza en la capa equivocada. Con LineaDeslizada el cambio ocurre donde vive la política, y la vista sigue diciendo la única verdad que le consta.

Un test rápido para saber si has acertado con el nombre: léelo en voz alta precedido de la frase el usuario acaba de. Si la oración resultante describe algo que un ser humano hizo —el usuario acaba de deslizar la línea, el usuario acaba de pulsar reintentar— el nombre es correcto. Si describe algo que hace el programa —el usuario acaba de recargar los datos— el nombre pertenece al reducer y no a la vista.

La superficie enumerable

Un vocabulario cerrado tiene una propiedad que ningún conjunto de métodos públicos tiene: se puede recorrer entero. El compilador conoce cada miembro del sealed interface, de modo que un when sin rama else obliga a atender todos los casos, y añadir un intent nuevo rompe la compilación en cada punto que lo consume hasta que decidas su tratamiento.

flowchart TD
V[Vista solo observa y reporta] --> I[Intent hecho ocurrido]
I --> W[when exhaustivo sobre el tipo sellado]
W --> R[Reducer decide la consecuencia]
R --> S[Estado siguiente]
S --> V
style I fill:#f9e2af,color:#11111b
style R fill:#cba6f7,color:#11111b
style S fill:#a6e3a1,color:#11111b

La exhaustividad tiene además un efecto social que no conviene subestimar: convierte la ampliación del producto en una conversación obligatoria. Cuando alguien añade un intent porque el diseño incorporó un gesto nuevo, el build rompe en cada pantalla y en cada test que consumía ese tipo, y quien lo añadió tiene que decidir explícitamente qué ocurre en cada punto. No hay forma de introducir una acción a medias, funcionando en el camino feliz y olvidada en el resto.

Esa clausura habilita cosas que en el Android imperativo eran imposibles. Registrar cada intent produce la crónica exacta de la sesión, en orden y sin huecos, porque no hay ninguna vía alternativa por la que la interacción pueda entrar. Serializar esa crónica y reinyectarla sobre el mismo estado inicial reproduce el bug que un usuario reportó, sin conjeturas. Y probar una interacción se reduce a construir un valor y pasarlo: sin instrumentación, sin pantalla, sin esperas.

Hay una condición para que todo esto se sostenga, y conviene enunciarla ahora porque será la fuente de casi todas las regresiones: el intent tiene que ser un dato inerte. Nada de lambdas dentro, nada de referencias a la vista, nada de objetos que arrastren un contexto de Android. En cuanto un miembro del tipo transporta una función, deja de poderse comparar, serializar y reinyectar, y la propiedad se pierde para toda la pantalla, no solo para ese caso. Un intent debe poder escribirse en un fichero y volver a leerse mañana sin haber perdido nada.

// Inerte: comparable, serializable, registrable.
data class LineaDeslizada(val linea: String) : CarritoIntent

// Contaminado: la logica viaja dentro y ya nada de lo anterior es cierto.
data class LineaDeslizada(val alConfirmar: () -> Unit) : CarritoIntent

La misma exigencia se aplica a la carga: los tipos que viajan dentro de un intent deben ser datos de dominio, no envoltorios de infraestructura. Un identificador como String o como un tipo de valor propio, sí; un cursor de base de datos, una vista de Android o un objeto que solo tiene sentido dentro de un framework, no. El criterio es el mismo de siempre y se comprueba igual de rápido: si no puedes escribirlo en un fichero y volver a leerlo, no es un intent.

Los hechos que no vienen del usuario

El vocabulario de una pantalla no se agota en los gestos. Hay hechos que ocurren sin que nadie toque nada y que el estado debe reflejar igual: el resultado de una petición que vuelve, un permiso que el sistema concede, un flujo de la base de datos que emite una fila nueva, la conectividad que cae. Todos ellos son noticias, y por tanto son intents con el mismo rango que los del usuario.

sealed interface CarritoIntent {
    // Del usuario
    data class CantidadCambiada(val linea: String, val unidades: Int) : CarritoIntent
    data object CuponAplicadoPulsado : CarritoIntent

    // Del mundo
    data class CarritoRecibido(val resultado: Resultado<List<Linea>>) : CarritoIntent
    data class ConectividadCambiada(val hayRed: Boolean) : CarritoIntent
    data class RelojAvanzado(val instante: Long) : CarritoIntent
}

Meter estos hechos en el mismo tipo tiene dos consecuencias que compensan de sobra la incomodidad inicial. La primera es que el reducer sigue siendo el único lugar donde el estado cambia, incluso cuando el cambio lo provoca la red: no aparece una segunda gramática de mutación por la puerta de atrás. La segunda es que el registro de intents vuelve a ser la historia completa, y no una versión parcial que solo cuenta lo que hizo la persona. Reproducir un bug exige exactamente eso: saber también qué contestó el servidor y en qué orden llegó.

Conviene fijarse en cómo está tipado CarritoRecibido: transporta un Resultado, no una lista. El fracaso viaja dentro del mismo intent que el éxito porque ambos son la misma noticia —el servidor contestó— y separarlos en dos miembros distintos suele acabar en dos ramas que repiten la mitad de la lógica. La lección siguiente vuelve sobre esto con detalle; aquí basta con notar que el error también es un hecho y también tiene su sitio en el vocabulario.

Nota el tercer miembro del ejemplo, RelojAvanzado. Es el patrón que resuelve la tentación más frecuente de todas, la de consultar la hora dentro del reducer para decidir si algo caducó. Si el instante entra como dato, la caducidad se convierte en una función pura del estado y del intent, comprobable en un test que fija el reloj a mano en lugar de esperar a que pase el tiempo real.

Una última observación práctica sobre el sitio del tipo. El sealed interface de intents pertenece al mismo archivo o al mismo paquete que el estado y el reducer de esa pantalla, no a un cajón común de tipos compartidos. La razón es de acoplamiento: cuando dos pantallas comparten un vocabulario de intents, cualquier gesto añadido en una obliga a la otra a atenderlo, y lo que empezó siendo reutilización termina siendo un tipo que ninguna de las dos puede modificar sin negociar. Los intents son locales por naturaleza; lo que se comparte entre pantallas son los modelos de dominio que viajan dentro de ellos.