Consumir los efectos en Compose con el ciclo de vida correcto

Un canal de entrega única solo cumple su promesa si alguien lo escucha bien. Y escuchar bien, en Compose, es más delicado de lo que parece, porque hay dos relojes corriendo a la vez: el de la composición, que se reevalúa muchas veces por segundo y sin garantías sobre cuándo, y el del ciclo de vida, que sigue el ritmo lento y observable de la pantalla que aparece, se oculta y se destruye. Atar la recolección de efectos al reloj equivocado produce dos fallos simétricos y ambos frecuentes: si la atas a la composición, ejecutas efectos en recomposiciones y vuelves al punto de partida; si no la atas a nada, sigues recolectando con la app en segundo plano y navegas hacia una pantalla que ya no está en el primer plano, con excepción incluida. El extremo receptor es donde una arquitectura correcta se gana o se pierde.

Dos relojes y un solo sitio correcto

El cuerpo de un Composable es una función que describe interfaz y que puede ejecutarse cuantas veces quiera el runtime: en cada recomposición, en cada cambio de un estado leído, incluso de forma especulativa. De ahí sale la primera regla, que es absoluta: nunca ejecutes un efecto directamente en el cuerpo de un Composable. Navegar, avisar o vibrar desde ahí es apostar a que el runtime no reevalúe esa función, y siempre la reevalúa.

Compose ofrece el puente adecuado: los efectos secundarios se lanzan en corrutinas gestionadas por la composición —LaunchedEffect es el caso típico— que sobreviven a las recomposiciones mientras su clave no cambie. Pero la composición no es el reloj correcto para consumir eventos de una pantalla, porque una pantalla puede seguir compuesta y estar en segundo plano, o desaparecer del árbol sin que nada de eso corresponda a su estado de visibilidad real. El reloj correcto es el ciclo de vida.

@Composable
fun CarritoScreen(vm: CarritoViewModel, nav: NavController) {
    val estado by vm.estado.collectAsStateWithLifecycle()
    val duenio = LocalLifecycleOwner.current

    LaunchedEffect(vm, duenio) {
        duenio.lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
            vm.efectos.collect { efecto -> manejar(efecto, nav) }
        }
    }

    CarritoContenido(estado, onBorrar = vm::borrarLinea)
}

Lee la estructura con atención. LaunchedEffect con claves estables —el propio modelo de vista y el dueño del ciclo de vida— arranca una corrutina que no se reinicia en cada recomposición. Dentro, repeatOnLifecycle ejecuta el bloque cada vez que el ciclo de vida alcanza el estado indicado y cancela la corrutina cuando cae por debajo. La colección del canal vive así exactamente mientras la pantalla está visible.

stateDiagram-v2
[*] --> Creada
Creada --> Visible: onStart arranca la coleccion
Visible --> Oculta: onStop cancela la coleccion
Oculta --> Visible: onStart reinicia la coleccion
Oculta --> Destruida: los efectos pendientes siguen en el bufer

Reiniciar la colección no duplica nada

La duda razonable al ver repeatOnLifecycle es si reiniciar la colección tras volver del segundo plano no reintroduce el bug de la lección anterior. La respuesta es que no, y el motivo es exactamente la propiedad que se eligió al modelar el transporte: el canal no tiene historial. Al cancelarse la colección y volver a empezar, no hay nada que reemitir; los efectos ya recibidos desaparecieron al recibirse, y los que se hayan emitido mientras la pantalla estaba oculta esperan en el búfer y se entregan al reanudar, una sola vez cada uno.

Este punto es el que más veces se malinterpreta al revisar código ajeno, y conviene tenerlo dicho con precisión: quien reintroduce el bug no es la reanudación de la colección, sino la existencia de un valor retenido al otro lado. Reiniciar una lectura sobre una cola vacía no produce nada; reiniciar una lectura sobre una celda con valor produce ese valor otra vez. La diferencia está en el flujo, no en el consumidor.

Compáralo con el estado, que hace lo contrario y también lo correcto: collectAsStateWithLifecycle reinicia igualmente su colección y al reanudar recibe de inmediato el último estado, porque el estado sí debe reponerse. Las dos mitades de la pantalla usan la misma disciplina de ciclo de vida y obtienen comportamientos opuestos, no por cómo se recolectan, sino por la naturaleza del flujo que hay al otro lado.

Los tres errores clásicos

El extremo receptor concentra unos pocos fallos que se repiten en todos los proyectos, y los tres tienen la misma raíz: haber atado la ejecución del efecto a algo que se repite.

Los tres tienen además un rasgo común que los hace difíciles de detectar en revisión: ninguno produce un error de compilación ni una excepción, y los tres funcionan perfectamente en el camino feliz que el autor probó. Solo se manifiestan bajo condiciones de ciclo de vida que rara vez se reproducen a mano, lo que convierte a la revisión de este patrón concreto en uno de los sitios donde más rentable resulta tener una regla escrita y un ayudante compartido.

El tercero merece un matiz porque es el más disfrazado. Su forma habitual no es una llamada suelta sino un condicional sobre un campo del estado que dispara la navegación cuando ese campo cambia. Eso es la lección dos otra vez, con ropa de Compose: el campo permanece, la recomposición lo vuelve a leer y el efecto se repite. La corrección no es proteger el condicional con más banderas, sino mover ese dato al canal de efectos, donde su consumo lo destruye.

// Consumo correcto y minimo con un helper reutilizable
@Composable
fun <T> ObservarEfectos(
    flujo: Flow<T>,
    minimo: Lifecycle.State = Lifecycle.State.STARTED,
    onEfecto: suspend (T) -> Unit,
) {
    val duenio = LocalLifecycleOwner.current
    LaunchedEffect(flujo, duenio, minimo) {
        duenio.lifecycle.repeatOnLifecycle(minimo) {
            flujo.collect { onEfecto(it) }
        }
    }
}

Extraer el patrón a una función tiene una ventaja que va más allá del ahorro de líneas: convierte la decisión sobre el ciclo de vida en un parámetro explícito y revisable, en vez de en una repetición que cada pantalla copia y alguna copia mal. Cuando el equipo decida subir a RESUMED para la navegación, habrá un solo sitio donde discutirlo.

Quién maneja el efecto y dónde

Resuelto el cuándo, queda el dónde, y es una decisión de arquitectura y no de estilo. Orbit ofrece un atajo, collectSideEffect, que encapsula el patrón anterior con el ciclo de vida ya considerado; usarlo es correcto y ahorra la ceremonia. Lo que el atajo no decide por ti es en qué nivel del árbol de composición colocas la traducción del efecto a una acción de la plataforma.

@Composable
fun CarritoRuta(
    vm: CarritoViewModel = hiltViewModel(),
    alPagar: (String) -> Unit,
    alCerrar: () -> Unit,
) {
    val estado by vm.collectAsState()
    val anfitrionSnackbar = remember { SnackbarHostState() }

    vm.collectSideEffect { efecto ->
        when (efecto) {
            is CarritoEfecto.IrAlPago -> alPagar(efecto.carritoId)
            is CarritoEfecto.AvisarStockAgotado ->
                anfitrionSnackbar.showSnackbar(efecto.producto)
            CarritoEfecto.ConfirmarBorrado -> alCerrar()
            CarritoEfecto.PedirFocoEnCupon -> Unit
        }
    }

    CarritoPantalla(estado, anfitrionSnackbar, onBorrar = vm::borrarLinea)
}

La separación entre el componente de ruta y el de pantalla no es decorativa. El de ruta conoce el modelo de vista, consume los efectos y traduce la navegación a lambdas que recibe de fuera; el de pantalla es puro, recibe estado y devuelve interacciones, y por eso se puede previsualizar y probar sin ningún modelo de vista. Pasar la navegación como lambda en vez de recibir el controlador entero mantiene la pantalla ignorante del grafo y hace trivial reutilizarla en otro flujo.

Queda un caso que merece atención propia: los efectos que deben ejecutarse aunque nadie esté mirando. Descargar un archivo, enviar un formulario en cola o registrar una compra no son efectos de interfaz, y atarlos al ciclo de vida de una pantalla es un error de ubicación, no de técnica. Esos trabajos pertenecen a un ámbito de mayor duración —un servicio, un trabajo programado, un repositorio con su propio alcance— y el efecto de interfaz correcto es solamente el aviso de que el trabajo se encoló.