Efectos tratados como estado: el evento que vuelve al rotar

Hay una asimetría curiosa en cómo se enseña este fallo. Todo el mundo aprende a reconocer el caso canónico —el mensaje de error guardado en el estado que vuelve a mostrarse tras rotar— y casi nadie aprende a reconocer sus catorce primos, que producen el mismo bug con nombres que no delatan nada. Un campo llamado pagoConfirmado no parece un evento; parece un hecho perfectamente respetable del dominio. Y sin embargo, si la pantalla reacciona a él lanzando una navegación, es una orden congelada y volverá a ejecutarse en cuanto alguien se resuscriba. Por eso el trabajo de nivel veinte no consiste en volver a derivar la causa del fallo, que ya está establecida, sino en adquirir un procedimiento que lo detecte sin depender de que el nombre del campo sea sospechoso. Ese procedimiento existe, cabe en una pregunta y es mecánico.

El catálogo de los disfrazados

La versión de manual del fallo tiene un campo llamado error con un mensaje dentro, y esa versión casi nunca es la que llega a producción, porque es demasiado evidente. Las que llegan tienen otra forma y conviene tenerlas catalogadas, porque el reconocimiento por familia es mucho más rápido que el análisis caso por caso.

La primera familia es la del booleano de éxito. Campos como registroCompletado, pagoConfirmado o sesionCerrada describen algo que parece un hecho del mundo y a menudo lo es; el problema aparece cuando la pantalla los observa para hacer algo irreversible. La segunda es la del identificador de destino: un campo que guarda a dónde hay que ir, con la orden metida en su propio nombre. La tercera es la del contador de disparos, un entero que se incrementa para forzar que la interfaz reaccione, que es la confesión más clara posible de que se está usando el estado como un canal. La cuarta, la más sutil, es la de la marca temporal: guardar el instante del último evento para que la comparación con el anterior sirva de detector de cambio.

// Cuatro familias, un solo error de categoria
data class MalState(
    val pagoConfirmado: Boolean = false,      // booleano de exito
    val destinoPendiente: String? = null,     // identificador de destino
    val disparosDeAviso: Int = 0,             // contador de disparos
    val instanteUltimoError: Long? = null,    // marca temporal
)

Las cuatro comparten un rasgo que las delata mejor que cualquier nombre: todas requieren, tarde o temprano, un mecanismo de limpieza. En cuanto un estado necesita una operación cuyo único propósito es volver a poner un campo a su valor inicial para que no se vuelva a disparar, ese campo era un evento. La operación de limpieza es la confesión, y tiene además la particularidad de ser fácil de buscar automáticamente: los nombres que contienen limpiar, consumir, marcar como visto o reiniciar aparecen en el mismo sitio en casi todos los proyectos que sufren este fallo.

Hay una quinta familia que merece mención aparte porque afecta a lo que no se ve. La telemetría alojada en el estado —un campo que la pantalla observa para enviar un evento de analítica— produce el mismo fallo sin ninguna manifestación visual, de modo que nadie lo reporta y las métricas quedan infladas en un factor que depende de cuántas veces roten los usuarios. Es el único caso del catálogo en el que el bug puede sobrevivir años sin que nadie lo note, y también el único cuyo coste no se mide en experiencia de usuario sino en decisiones de producto tomadas sobre datos falsos.

El test de reejecución

Como la clasificación depende del consumidor, hace falta un criterio que hable de consumidores y no de nombres. El test es este: si la interfaz volviera a observar este mismo estado desde cero, sin que nada haya cambiado en el mundo, ¿el resultado sería idéntico? Si la respuesta es sí, el campo es un hecho y pertenece al estado. Si la respuesta es no —porque la reobservación produciría una segunda navegación, un segundo cobro, un segundo aviso o un segundo evento de analítica—, entonces no es un hecho sino una orden, y ninguna cantidad de disciplina en el consumidor la convertirá en otra cosa.

El test es formalmente una pregunta de idempotencia sobre la función que va del estado a las acciones observables. El estado, por definición, se relee cada vez que hay un suscriptor nuevo, y el número de suscriptores nuevos a lo largo de una sesión no está acotado ni es predecible. Por tanto, todo lo que dependa del estado debe tolerar ejecución repetida. Un campo cuya lectura provoca un efecto no idempotente viola esa condición estructural, y el fallo es solo cuestión de tiempo.

flowchart TB
P[Campo del estado bajo sospecha]
P --> Q{La reobservacion produce el mismo mundo}
Q -- Si --> H[Es un hecho y se queda en el estado]
Q -- No --> O[Es una orden y sale a un canal de efectos]
O --> R[Jerarquia sellada de efectos]
R --> C[Canal de entrega unica]
C --> V[Consumo consciente del ciclo de vida]
style H fill:#a6e3a1,color:#11111b
style O fill:#f38ba8,color:#11111b

Hay una variante del test más rápida de aplicar y casi igual de fiable, útil en revisión de código cuando no hay tiempo para el análisis completo: preguntarse qué pasaría si el estado se guardara en disco y se restaurase mañana. Un nombre de usuario restaurado mañana sigue siendo correcto. Una lista restaurada mañana sigue siendo correcta, aunque esté desactualizada. Una orden de navegar restaurada mañana lleva al usuario a una pantalla que pidió ayer, y una orden de mostrar un aviso restaurada mañana le enseña el error de una sesión que ya olvidó. La restauración diferida amplifica hasta lo grotesco la diferencia que la rotación solo insinúa, y por eso es un detector más sensible.

Conviene aplicarlo también en dirección contraria, porque la sobrecorrección es un riesgo real en equipos que acaban de aprender esta lección. Un diálogo visible es un hecho: si el usuario gira el teléfono con un diálogo de confirmación abierto, el diálogo debe seguir abierto, y por tanto la propiedad que lo describe pertenece al estado y debe sobrevivir a la muerte del proceso. Lo mismo vale para una hoja modal desplegada, para un elemento seleccionado o para el paso actual de un asistente. Enviar cualquiera de estos por un canal de efectos produce el bug simétrico y menos conocido: la pantalla que pierde su diálogo al rotar, que en un flujo de pago puede costar bastante más que un aviso duplicado.

La cura y sus tres trampas

La cura tiene tres piezas y ninguna es opcional. La primera es una jerarquía sellada que enumera los efectos de la pantalla: al ser cerrada, el consumidor está obligado a tratarlos todos y añadir uno nuevo rompe la compilación en el sitio exacto donde hay que decidir qué hacer con él. La segunda es un transporte de entrega única, que en Orbit es postSideEffect y a mano es un Channel convertido en flujo con receiveAsFlow. La tercera es el consumo consciente del ciclo de vida, que garantiza que el efecto no se entrega mientras la pantalla no está en primer plano.

sealed interface PerfilEfecto {
    data class Aviso(val texto: TextoUI) : PerfilEfecto
    data class IrADetalle(val id: String) : PerfilEfecto
    data object PedirPermisoCamara : PerfilEfecto
}

fun confirmar() = intent {
    val r = repo.confirmar()
    reduce { state.copy(confirmado = r.exito) }   // el hecho se queda
    if (r.exito) postSideEffect(PerfilEfecto.IrADetalle(r.id))  // la orden se va
}

Conviene subrayar el detalle del ejemplo anterior porque concentra toda la lección en dos líneas: el mismo suceso produce a la vez un hecho y una orden, y cada uno va por su vía. El hecho —el pago quedó confirmado— se queda en el estado porque describe el mundo y debe sobrevivir a la rotación, a la muerte del proceso y a cualquier reconstrucción de la pantalla. La orden —lleva al usuario al detalle— sale por el canal porque su reejecución produciría una segunda navegación. Quien intenta elegir entre ambas cosas está planteando mal el problema: no compiten, son dos proyecciones distintas de un mismo suceso y ambas son necesarias.

// Consumo correcto: solo mientras la pantalla esta en primer plano
LaunchedEffect(Unit) {
    lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        vm.container.sideEffectFlow.collect { efecto ->
            when (efecto) {
                is PerfilEfecto.Aviso -> mostrarAviso(efecto.texto)
                is PerfilEfecto.IrADetalle -> navegar(efecto.id)
                PerfilEfecto.PedirPermisoCamara -> pedirPermiso()
            }
        }
    }
}

La primera trampa es la del transporte que pierde. Un SharedFlow con repetición cero descarta la emisión si en ese instante no hay ningún colector, y hay un instante así en cada rotación. El Channel no pierde porque suspende al productor hasta que alguien recoge, pero eso tiene su propia consecuencia: si nadie recoge nunca, el intent que emitió queda suspendido indefinidamente. La elección entre ambos no es de gusto sino de qué fallo prefieres tener, y para efectos de interfaz la respuesta correcta es casi siempre el canal con capacidad acotada.

La segunda trampa es la del consumo sin conciencia del ciclo de vida. Recoger el flujo de efectos en un LaunchedEffect sin repeatOnLifecycle significa que la pantalla puede recibir una orden de navegación mientras está en segundo plano, y el resultado es una transición que ocurre fuera de la vista del usuario o directamente una excepción del controlador de navegación por estado inválido. La tercera es la más silenciosa: emitir efectos desde el reductor. El reductor debe seguir siendo una función pura del estado anterior al siguiente; si además emite, deja de ser reproducible y la única herramienta que teníamos para razonar sobre el sistema se pierde.

Efectos que no se pueden perder

La cura anterior es correcta para los efectos de presentación, que son la inmensa mayoría, y es insuficiente para una minoría que conviene identificar porque su fallo es el más caro del catálogo. Un canal de efectos vive en memoria y muere con el proceso; si el sistema mata la aplicación mientras hay un efecto pendiente, ese efecto desaparece sin dejar rastro. Para un aviso perdido eso es aceptable e incluso deseable. Para una confirmación de cobro, para el registro de una operación de auditoría o para el disparo de una sincronización que el usuario cree hecha, no lo es.

La distinción útil no es entre efectos importantes y accesorios, que es demasiado vaga para decidir nada, sino entre efectos cuyo destinatario es la pantalla y efectos cuyo destinatario es el mundo. Un aviso, una navegación o una petición de permiso solo tienen sentido si hay alguien mirando, y perderlos cuando no hay nadie es la conducta correcta. Un cobro, un envío o una escritura en un sistema externo tienen sentido con o sin pantalla, y esos no son efectos de interfaz aunque los haya disparado un botón: son trabajo de dominio que se coló en la capa equivocada porque el botón estaba cerca.

// Efecto de presentacion: si nadie mira, perderlo es correcto
postSideEffect(PagoEfecto.MostrarRecibo(id))

// Trabajo de dominio: debe sobrevivir al proceso, luego no es un efecto de UI
sincronizaciones.encolar(TareaSincronizar(pedidoId = id))

La consecuencia práctica es que el refactor de esta lección tiene dos destinos y no uno. Todo lo que salga del estado por no ser idempotente se dirige al canal de efectos si su destinatario es la pantalla, y baja a la capa de dominio con persistencia si su destinatario es el mundo. Mezclarlos produce dos fallos simétricos igual de reales: perder trabajo que había que hacer, cuando se pone en el canal lo que debía persistir; y ejecutar dos veces una acción visible, cuando se persiste lo que debía morir con la pantalla.