StateFlow: valor siempre presente, conflación por igualdad y las emisiones que nunca verás

La definición operativa de StateFlow<T> cabe en una línea: es un SharedFlow con repetición uno, sin capacidad extra, con política de descartar el más antiguo, y con la obligación de tener siempre un valor. Todo lo demás se deduce de ahí. Que nunca suspenda al emitir se deduce de la política de descarte; que un suscriptor nuevo reciba siempre algo se deduce de la repetición uno; que sea un observable y no una cola se deduce de que el buffer tenga tamaño uno. Lo único que no se deduce, porque es un añadido deliberado, es la conflación por igualdad: si el valor entrante es estructuralmente igual al actual, no hay emisión en absoluto. Esa cláusula es la que convierte a StateFlow en la herramienta perfecta para el estado y en una fuente de bugs irreproducibles para todo lo demás.

Un flujo que siempre tiene una respuesta

La diferencia visible con SharedFlow es la propiedad value, legible y escribible sin suspender. Eso convierte a StateFlow en un puente entre el mundo suspendido y el mundo síncrono: cualquiera puede preguntar cuál es el estado ahora sin colectar nada, y quien colecta recibe el valor actual de forma inmediata en el momento de suscribirse, antes de cualquier emisión futura.

private val _pantalla = MutableStateFlow<Pantalla>(Pantalla.Cargando)
val pantalla: StateFlow<Pantalla> = _pantalla.asStateFlow()

fun cargar(datos: List<Fila>) {
    _pantalla.value = Pantalla.Contenido(datos)   // no suspende jamás
}

Como el buffer tiene tamaño uno y la política es descartar el más antiguo, publicar es una operación total: nunca falla, nunca espera y nunca informa de que alguien se lo perdió. La contrapresión, que en SharedFlow era una decisión, aquí sencillamente no existe: el emisor va tan rápido como quiera y los recolectores ven lo que alcanzan a ver. Esa es la primera fuente de emisiones invisibles y es de diseño.

Para actualizaciones que dependen del valor anterior no basta con leer value y escribirlo, porque entre ambas operaciones cabe otra escritura. La biblioteca ofrece update, que aplica la función en un bucle de comparación e intercambio hasta que gana. Su lambda debe ser pura y barata, porque puede ejecutarse varias veces.

_contador.update { it + 1 }        // atómico y correcto bajo concurrencia
_contador.value = _contador.value + 1   // carrera clásica: no lo hagas

Igualdad estructural: la cláusula que decide todo

La regla exacta es que una asignación a value solo produce emisión si el valor nuevo no es estructuralmente igual al actual, comparado con equals. No hay forma de desactivarlo, no hay parámetro, no hay variante. Y como es equals quien decide, la corrección de tu flujo de datos queda delegada en la corrección de un método que casi nunca se revisa con esa responsabilidad en mente.

El caso de la mutación en sitio merece detenerse porque es el que consume tardes enteras. El valor se actualizó, la propiedad value devuelve el objeto con los datos nuevos, y sin embargo ningún recolector reaccionó: como se mutó el mismo objeto, la comparación con el anterior —que es él mismo— dio cierto y no hubo emisión. El síntoma es una interfaz que se queda congelada mostrando lo viejo mientras el estado en memoria es correcto. La cura es estructural, no táctica: el tipo de estado debe ser inmutable de arriba abajo.

// Mal: la lista es la misma instancia, equals da true, no hay emisión.
_estado.value.items.add(nuevo)

// Bien: instancia nueva, equals da false, emisión garantizada.
_estado.update { it.copy(items = it.items + nuevo) }

flowchart TD
A[Asignacion a value] --> B{El nuevo es igual al actual}
B -->|Si| C[No hay emision y nadie se entera]
B -->|No| D[Se guarda como valor actual]
D --> E{El recolector va mas rapido que el emisor}
E -->|Si| F[Ve todos los valores]
E -->|No| G[Ve solo el ultimo de la rafaga]

Por qué no sirve para eventos

Juntando las dos causas anteriores, un valor publicado en un StateFlow puede no llegar nunca a un recolector por dos motivos independientes: porque era igual al anterior, o porque llegó otro antes de que el recolector volviera a mirar. Ninguno de los dos es un fallo; ambos son el comportamiento contratado. Y ambos son inaceptables si lo que transportas es un hecho puntual.

El ejemplo canónico es el mensaje de error. Si publicas un error, el usuario lo descarta, y ocurre exactamente el mismo error otra vez, el segundo no emite: es igual al primero. Desde fuera parece que el sistema dejó de fallar. Los apaños habituales —añadir una marca de tiempo o un identificador aleatorio al modelo de estado para forzar la desigualdad— funcionan y son una confesión: estás introduciendo ruido en el tipo para desactivar una conflación que no querías, lo cual demuestra que el tipo elegido era el equivocado.

La regla de decisión es de dominio y se enuncia en una pregunta: ¿aplicar este valor dos veces seguidas es lo mismo que aplicarlo una? Si la respuesta es sí, es estado y StateFlow es correcto. Si es no, es un evento y necesitas un SharedFlow sin conflación —o un Channel si además debe consumirlo exactamente uno.

// Estado: idempotente, sobrevive a la reconstrucción de la pantalla.
val perfil: StateFlow<Perfil> = _perfil.asStateFlow()

// Evento: cada aparición cuenta, ninguna se puede conflar.
val avisos: SharedFlow<Aviso> = _avisos.asSharedFlow()

Queda un último rasgo, fácil de olvidar y con consecuencias en las pruebas: StateFlow tampoco completa nunca. Su collect no retorna, y por eso hay que acotarlo con el ámbito o con operadores como first y take. Y su igualdad como objeto es de identidad: dos StateFlow distintos con el mismo valor no son iguales entre sí, aunque distinctUntilChanged aplicado sobre uno de ellos sea, por definición, una operación sin efecto.

Derivar estado de otro estado

Aplicar un operador a un StateFlow devuelve un Flow corriente: frío, sin valor actual y sin conflación. Eso sorprende a mucha gente que espera que map sobre un estado siga siendo un estado, y es coherente: la transformación no puede saber si tu función es barata ni si su resultado tiene sentido como valor inicial, así que no lo asume.

// Esto NO es un StateFlow: es un Flow frío que se recalcula por recolector.
val nombreVisible: Flow<String> = usuario.map { it.nombre.uppercase() }

// Esto sí, y además vuelve a conflar por igualdad tras la transformación.
val nombreEstado: StateFlow<String> = usuario
    .map { it.nombre.uppercase() }
    .stateIn(ambito, SharingStarted.WhileSubscribed(5_000), "")

La recuperación de la conflación tras el map no es un detalle menor, sino el motivo principal para derivar estado con stateIn: si dos usuarios distintos comparten el mismo nombre en mayúsculas, la proyección produce dos valores iguales consecutivos y el nuevo StateFlow suprime el segundo. La conflación, en otras palabras, se aplica en el tipo de salida y no en el de entrada, así que proyectar a un tipo más pobre reduce el número de emisiones. Es una propiedad explotable: exponer a la interfaz un estado con exactamente los campos que pinta elimina emisiones que no cambian nada visible.

Al combinar varios StateFlow con combine, el resultado también deja de ser estado y hay que volver a fijarlo. Ahí aparece un matiz temporal importante: mientras el resultado combinado sea un flujo frío, cada recolector paga la combinación entera, y como combine emite por cada cambio de cualquiera de sus fuentes, el estado derivado pasa por combinaciones intermedias antes de estabilizarse. Con stateIn esas intermedias siguen existiendo, pero solo se calculan una vez y quien llegue tarde ve directamente la última.

Y hay un matiz de rendimiento que suele ir en dirección contraria a la intuición: como equals se evalúa en cada publicación, un estado con estructuras grandes paga una comparación profunda por intento de escritura, incluso cuando el resultado es que no hay que emitir. Con listas de miles de elementos que se republican en bucle, esa comparación puede costar más que la emisión que evita. La solución no es abandonar la inmutabilidad sino reducir la granularidad de lo que se publica: si solo cambia un campo, el estado que lo contiene debería ser lo bastante pequeño como para que compararlo sea trivial.

// Comparar esto en cada publicación es caro y ocurre siempre.
data class Estado(val filas: List<Fila>, val seleccion: Int)

// Separar lo que cambia rápido de lo que cambia despacio abarata la conflación.
data class Estado(val filas: ListaEstable, val seleccion: Int)