El debate: canal de efectos frente a estado consumible

Después de cuatro lecciones defendiendo el canal, toca hacer lo que exige la honestidad intelectual: exponer el argumento contrario en su versión más fuerte, no en su caricatura. Porque existe una posición seria, sostenida por gente que ha pensado el problema con cuidado, según la cual el canal de efectos es un parche elegante a un problema mal planteado y la solución correcta es que todo sea estado, incluidos los eventos, consumidos explícitamente mediante una intención que los retira del modelo. No es una postura ingenua: nace de tomarse en serio la fuente única de verdad, la muerte del proceso y la reproducibilidad, tres cosas que el canal maneja peor de lo que su elegancia sugiere. Conocer los dos bandos y saber qué premisa acepta cada uno es lo que distingue a quien elige de quien repite.

La tesis del canal

El argumento del canal parte de una observación categórica: hay dos clases de salidas con semánticas incompatibles —convergencia y entrega única— y ninguna estructura puede ofrecer ambas a la vez. De ahí se sigue que deben ser dos canales con dos tipos, y que la separación debe ser estructural para que el compilador y el runtime la sostengan.

El argumento tiene además un componente de economía cognitiva que no conviene despreciar. Toda garantía que el sistema sostiene por ti es una regla menos que recordar, y el número de reglas que un equipo puede sostener a la vez es finito y bastante bajo. Al elegir el canal, la regla “acuérdate de consumir el evento” desaparece del manual del equipo, y con ella desaparece la clase entera de fallos que nacía de olvidarla.

Sus ventajas prácticas son considerables. La entrega única sale gratis, sin código de consumo ni banderas. El tipo sellado de efectos documenta, en un solo sitio y de forma exhaustiva, todo lo que la pantalla puede provocarle al mundo. El estado queda limpio de campos que solo existen para disparar cosas y por tanto sigue siendo comparable por igualdad, que es lo que permite recomposiciones baratas. Y el flujo permanece unidireccional de verdad: la interfaz no escribe nunca en el modelo, ni siquiera para decir “ya lo he visto”.

La tesis del estado consumible

El bando contrario empieza rechazando la premisa. Sostiene que la distinción entre convergencia y entrega única es real pero está mal ubicada: no es una propiedad del dato, sino del consumo del dato. Un evento pendiente, dicen, es perfectamente un hecho sobre el mundo —“hay un aviso sin mostrar”— y por tanto pertenece al estado; lo que no pertenece al estado es la decisión de mostrarlo, que corresponde a la interfaz y que debe comunicarse de vuelta con una intención explícita.

data class LoginState(
    val cargando: Boolean = false,
    val avisoPendiente: Aviso? = null,
)

// La interfaz confirma el consumo con una intencion de vuelta
fun avisoMostrado(id: String) = intent {
    reduce {
        if (state.avisoPendiente?.id == id) state.copy(avisoPendiente = null)
        else state
    }
}

Nótese que esto no es la bandera ingenua de la lección dos. Aquí el consumo es una intención que pasa por el mismo reductor que todo lo demás, es idempotente gracias a la comprobación por identificador, y por tanto no sufre las carreras del borrado manual descuidado. El evento no se pierde si nadie lo consume: permanece en el estado hasta que alguien lo consuma de verdad.

flowchart LR
L[Logica] -->|efecto en el estado| E[Estado unico con aviso pendiente]
E --> V[Interfaz muestra el aviso]
V -->|intencion aviso mostrado| L
L -->|reduce a nulo| E
style E fill:#a6e3a1,color:#11111b
style V fill:#89b4fa,color:#11111b

La premisa que sostiene todo el bando se puede enunciar así: si no está en el estado, no existe para el sistema. Lo que no está en el estado no se puede guardar, no se puede restaurar, no se puede inspeccionar en una herramienta de depuración ni reproducir en un informe de fallo. Desde ese punto de vista, el canal no es una solución elegante sino un agujero por el que se escapa información del sistema, y la elegancia se paga en observabilidad perdida.

Sus argumentos fuertes son cuatro. Uno: hay una única fuente de verdad, y el estado guardado describe la pantalla completa, incluidos sus pendientes, lo que permite restaurarla exactamente tras la muerte del proceso. Dos: los efectos pendientes son visibles en las herramientas de depuración y en los tests como cualquier otro campo, sin necesidad de consumir un flujo aparte. Tres: la entrega deja de depender de que exista un coleccionista en el momento exacto, con lo que desaparece la ventana de pérdida. Cuatro: con varios consumidores no hay reparto no determinista, porque todos ven el mismo estado.

Hay un quinto argumento, menos citado y quizá el más incómodo para el bando contrario: la reproducibilidad. Si toda salida está en el estado, entonces la secuencia de estados de una sesión es un registro completo de lo que ocurrió, y un fallo se reproduce reinyectando esa secuencia. Con efectos en un canal, el registro tiene huecos: hubo órdenes que se ejecutaron y que no aparecen en ninguna fotografía, de modo que reconstruir lo sucedido exige leer registros aparte y confiar en que estén completos.

Su coste, que también conviene decir sin adornos, es la ceremonia: cada efecto necesita identidad, una intención de consumo y disciplina en la interfaz para invocarla. Y es un contrato que el compilador no verifica: olvidar la intención de vuelta reintroduce el aviso zombi, exactamente el bug que se quería evitar. El canal traslada esa garantía al runtime; el estado consumible la deja en manos del programador.

Los cuatro ejes y el arbitraje

Puestos los dos casos, el desacuerdo se ordena en cuatro ejes donde cada bando gana uno o dos, y ninguno los gana todos.

De ahí sale un criterio de arbitraje que es más útil que cualquier lealtad: decide según lo que le pase al efecto si la app muere antes de ejecutarlo. Si perderlo es aceptable —una vibración, un aviso informativo, una animación, un mensaje de validación— el canal es la elección correcta y su ergonomía es un regalo. Si perderlo es inaceptable —una navegación que forma parte de un flujo de pago, la apertura de un documento tras una subida, una confirmación que el usuario debe ver sí o sí— entonces ese efecto no era efímero del todo y probablemente merece existir en el estado, con identidad y consumo explícito, o incluso persistirse.

La solución mixta y la regla de equipo

En una base de código real las dos soluciones conviven sin contradicción, siempre que la frontera esté escrita y no dependa del criterio del día. El reparto que funciona es sencillo: el canal para lo prescindible y el estado para lo crítico.

data class PedidoState(
    val cargando: Boolean = false,
    // Critico: debe sobrevivir a la muerte del proceso
    val confirmacionPendiente: Confirmacion? = null,
)

sealed interface PedidoEfecto {
    // Prescindibles: si se pierden, no pasa nada grave
    data class Avisar(val mensaje: String) : PedidoEfecto
    data object VibrarError : PedidoEfecto
}

fun confirmacionVista(id: String) = intent {
    reduce {
        if (state.confirmacionPendiente?.id == id) state.copy(confirmacionPendiente = null)
        else state
    }
}

El criterio que separa ambas listas es único y se puede enunciar en una frase que cualquiera del equipo puede aplicar sin consultar: si perder este efecto por la muerte del proceso produciría un fallo que un usuario reportaría, va al estado con consumo explícito; en cualquier otro caso, va al canal. Aplicado con honestidad, ese criterio deja el canal con la inmensa mayoría de los efectos y el estado con dos o tres casos por app, casi siempre relacionados con dinero, con documentos o con confirmaciones legales.

La objeción previsible a la solución mixta es que introduce dos mecanismos donde antes había uno, y que dos mecanismos son más difíciles de enseñar que uno. Es cierta y hay que responderla con el mismo criterio que se aplica a cualquier abstracción: la uniformidad solo vale la pena cuando los casos son uniformes. Aquí no lo son —un aviso perdido y una confirmación de pago perdida tienen consecuencias de órdenes de magnitud distintas— y forzar el mismo tratamiento para ambos significa o pagar ceremonia innecesaria en el noventa por ciento de los casos, o aceptar pérdidas inaceptables en el diez restante.

Conviene además fijar el número de casos críticos como una métrica que se vigila. Si la lista de efectos guardados en el estado crece más allá de un puñado, casi siempre significa una de dos cosas: o el equipo está clasificando por miedo en vez de por análisis, o hay un flujo que en realidad debería modelarse como una máquina de estados persistida y no como una secuencia de avisos.