El reducer puro: de estado e intent al siguiente estado

La función más importante de una aplicación MVI cabe en una línea de firma y no hace absolutamente nada interesante: recibe un estado y un intent, devuelve otro estado, y ahí termina su ambición. Esa modestia es su poder. Un reducer no llama a la red, no toca el disco, no lee el reloj, no escribe en un log, no lanza corrutinas, no conoce Android. Toda la tentación de hacer cosas se ha desplazado fuera de él, y lo que queda dentro es únicamente una tabla de decisiones sobre datos: si el estado era así y ocurrió esto, entonces el estado pasa a ser así otro. Lo que ganas a cambio de esa renuncia es una propiedad rara en el software de interfaz: la de poder afirmar con certeza qué va a pasar, sin ejecutar la aplicación, sin emulador y sin suerte.

La firma manda sobre el cuerpo

Antes de escribir una sola rama, escribe la firma. Es la que impone la disciplina y la que hace imposibles categorías enteras de error.

fun reducir(estado: CarritoState, intent: CarritoIntent): CarritoState =
    when (intent) {
        is CarritoIntent.CantidadCambiada ->
            estado.copy(lineas = estado.lineas.conUnidades(intent.linea, intent.unidades))
        is CarritoIntent.CuponEscrito ->
            estado.copy(cupon = intent.texto, errorCupon = null)
        CarritoIntent.ReintentoPulsado ->
            estado.copy(cargando = true, error = null)
        CarritoIntent.PantallaMostrada ->
            estado.copy(cargando = true)
        else -> estado
    }

Antes de mirar el cuerpo, repara en dónde está escrita esa función: es una función libre, fuera de la clase, sin this que la ate a un ViewModel. Esa colocación no es un capricho de estilo. Una función libre no puede leer propiedades de la instancia por accidente, no arrastra el ciclo de vida de Android y se importa desde un test de JVM sin ninguna ceremonia. Cuando el reducer vive dentro del ViewModel, la tentación de leer un campo de la clase está siempre a un carácter de distancia, y basta con que alguien ceda una vez para que la pureza deje de ser cierta sin que nada lo señale.

Fíjate ahora en tres detalles del cuerpo que tampoco son accidentales. El estado entra como parámetro y no se lee de ninguna propiedad de la clase: no hay entrada oculta. El resultado sale por el return y no por un emit ni una asignación: no hay salida oculta. Y cada rama produce un valor nuevo con copy en lugar de mutar el que recibió: el estado que entró sigue existiendo intacto, lo que permite compararlos, guardarlos y reproducirlos.

Qué significa puro, operativamente

Pureza suena a categoría teórica y en realidad es una lista corta de prohibiciones comprobables. Un reducer es puro si, ejecutado dos veces con los mismos argumentos, devuelve valores iguales y no deja rastro en ninguna parte.

Hay una prueba casera para verificarlo sin filosofar: intenta mover el reducer a un módulo Kotlin puro, sin dependencia de Android. Si compila, es casi seguro que es puro, porque la mayoría de las impurezas que importan llegan por esa vía —contexto, recursos, registro, preferencias, tiempo del sistema—. Si no compila, el compilador acaba de señalarte con precisión cada línea que había que sacar. Muchos equipos convierten esa prueba en estructura permanente y colocan el reducer y el estado en un módulo compartido, precisamente para que la barrera la vigile la máquina y no la buena voluntad.

Las dos infracciones más frecuentes son también las más inocentes de aspecto. La primera es el reloj: calcular dentro del reducer si un cupón caducó consultando la hora actual convierte una función determinista en una función que falla a medianoche. La solución es transportar el instante como dato dentro del intent, de modo que el reducer siga siendo una tabla y el tiempo entre por la puerta. La segunda es el registro: una llamada a Log parece inofensiva y ya es un efecto, además de una dependencia de Android que impide correr el reducer en un test de JVM puro. Sácala al borde, donde los efectos son legítimos y están vigilados.

Queda una duda razonable: si el reducer no puede hacer nada, ¿de dónde salen las llamadas a la red? La respuesta corta es que el reducer no las hace, las provoca, y que quien las ejecuta es otra capa que verás en la lección siguiente. Lo importante ahora es que esa separación no debilita la pureza: el reducer decide qué estado corresponde y, como mucho, deja constancia en el estado de que hay trabajo pendiente. Nunca lo realiza.

La comprobación se vuelve aritmética

Cuando la pureza se respeta, el test deja de ser un ejercicio de andamiaje y se convierte en una afirmación sobre valores. No hay ViewModel que construir, ni dispatcher que sustituir, ni tiempo que adelantar, ni repositorio que fingir: hay un estado, un intent y un estado esperado.

@Test
fun `escribir cupon limpia el error anterior`() {
    val inicial = CarritoState(cupon = "", errorCupon = "Cupon no valido")
    val siguiente = reducir(inicial, CarritoIntent.CuponEscrito("VERANO"))
    assertEquals("VERANO", siguiente.cupon)
    assertNull(siguiente.errorCupon)
}

No hay runTest, ni Dispatchers.setMain, ni un repositorio falso, ni una espera. Tampoco hay margen para el test que pasa por casualidad: si la aserción se cumple una vez, se cumple siempre, porque no queda ninguna variable oculta que pueda cambiar entre ejecuciones. Un test así no es lento ni frágil por construcción, no por disciplina.

flowchart LR
E0[Estado inicial] --> R[reducir funcion pura]
I[Intent] --> R
R --> E1[Estado siguiente]
E1 --> A[Asercion directa sobre el valor]
style R fill:#cba6f7,color:#11111b
style A fill:#a6e3a1,color:#11111b

De aquí nace la práctica de la tabla: una lista de tripletas de estado inicial, intent y estado esperado, recorrida en un test parametrizado. Esa tabla es la especificación ejecutable de la pantalla, y crece de forma lineal con las reglas en vez de exponencialmente con las combinaciones de infraestructura. También es la base de la comprobación basada en propiedades: como el reducer es una función total y determinista, se le pueden lanzar secuencias aleatorias de intents y afirmar invariantes —que el total nunca sea negativo, que cargando y error jamás sean ciertos a la vez— sin que ninguna aserción dependa del entorno.

Y de la misma pureza sale, casi gratis, la reproducción de una sesión entera. Si el reducer es una función de dos argumentos, entonces aplicarlo sobre una lista de intents es un pliegue, y el estado final de una sesión es simplemente el resultado de doblar la historia sobre el estado inicial.

val estadoFinal = trazaDeIntents.fold(CarritoState()) { acc, i -> reducir(acc, i) }

Esa línea es, literalmente, la reproducción de un bug reportado por un usuario: guarda los intents, dóblalos y observa. Con la lista de estados intermedios en la mano tienes también el viaje en el tiempo, y con dos versiones del reducer aplicadas a la misma traza tienes una comparación exacta de qué cambió tu refactor.

Un reducer que se puede componer

Una pantalla grande no necesita un when de doscientas ramas. Como el reducer es una función, se compone igual que cualquier otra: se parte por secciones del estado y se delega, y la función de nivel superior solo enruta. La pureza se conserva en la composición porque componer funciones puras da funciones puras.

fun reducir(estado: PedidoState, intent: PedidoIntent): PedidoState = when (intent) {
    is PedidoIntent.DelCarrito ->
        estado.copy(carrito = reducirCarrito(estado.carrito, intent.hijo))
    is PedidoIntent.DelPago ->
        estado.copy(pago = reducirPago(estado.pago, intent.hijo))
    PedidoIntent.ConfirmarPulsado ->
        estado.copy(fase = Fase.Confirmando)
}

Cada subreducer se prueba con su propia tabla y desconoce el estado de los demás, que es justo lo que quieres: la sección de pago no puede corromper la de carrito porque ni siquiera la recibe. El reducer padre queda como un enrutador legible de un vistazo, y las reglas que cruzan secciones —que confirmar exige carrito no vacío y pago válido— viven en él, que es el único punto que ve ambas cosas a la vez. Esa es también la señal para dividir: si una regla necesita mirar dos secciones, pertenece al padre; si solo mira una, baja.

Conviene resistir dos tentaciones en este punto. La primera es hacer el reducer parcial, devolviendo un valor nulo cuando el intent no le corresponde: una función total que devuelve el estado sin cambios es más fácil de razonar y no obliga a nadie a comprobar nulos. La segunda es meter en el reducer un cálculo derivado caro y guardarlo en el estado por comodidad; si el valor se puede calcular de los demás campos, calcularlo en la vista o en una propiedad val del estado evita mantener dos verdades sincronizadas a mano.

Vale la pena cerrar con la advertencia que la experiencia impone: la pureza no se pierde de golpe sino por erosión. Nadie decide un martes que el reducer va a llamar a la red; lo que ocurre es que alguien añade un registro para depurar y no lo quita, y meses después otra persona, viendo que ya hay una llamada externa, añade una segunda con menos escrúpulo. Por eso la defensa efectiva no es la vigilancia en la revisión de código sino la barrera estructural: un módulo sin dependencias de Android, un reducer que es función libre y una batería de tests que corren en milisegundos y dejarían de hacerlo en cuanto alguien introdujera una espera.