StateFlow: el estado observable con valor actual

Un Flow frío describe valores que existirían si alguien los pidiera. El estado de una pantalla es otra cosa: no es una posibilidad, es un hecho presente. Cuando la interfaz se recrea tras una rotación no quiere que le vuelvan a calcular el estado, quiere que le digan cuál es ahora mismo, inmediatamente y sin esperar. StateFlow es exactamente esa figura: un flujo caliente que siempre tiene un valor, que lo entrega en el acto a quien se suscriba y que no termina nunca. Tres rasgos que suenan modestos y que, tomados en serio, convierten a StateFlow en el sitio donde el Model de MVI quería vivir desde el principio.

Siempre hay un valor, y siempre te lo dan

La firma lo dice todo: MutableStateFlow(valorInicial) no admite construirse vacío. No existe un StateFlow que todavía no tenga valor, igual que no existe una pantalla que todavía no tenga aspecto. Esa obligación, que al principio parece una molestia burocrática, es la que borra una familia entera de defensas: no hay que comprobar si el estado es nulo, no hay que dibujar un caso “aún no ha llegado nada”, no hay carrera entre la primera composición y la primera emisión. La pantalla arranca con el estado inicial que tú escribiste, que además es la mejor documentación posible de cómo se ve la pantalla antes de que ocurra nada.

data class TareasState(
    val cargando: Boolean = false,
    val tareas: List<Tarea> = emptyList(),
    val error: String? = null,
)

class TareasViewModel(private val repo: TareasRepo) : ViewModel() {
    private val _state = MutableStateFlow(TareasState())   // valor inicial obligatorio
    val state: StateFlow<TareasState> = _state.asStateFlow()  // solo lectura hacia fuera

    fun leerAhora(): TareasState = state.value   // acceso sincrono, sin suspender
}

Dos gestos merecen atención. El primero es asStateFlow: expone el flujo sin su capacidad de escritura, de modo que la interfaz puede leer y observar pero no puede mutar. La asimetría es deliberada y es la misma que estudiaste en el ciclo unidireccional: el estado se modifica en un solo sitio, y desde fuera solo se mira. El segundo es value, que devuelve el estado actual sin suspender: es la puerta síncrona que permite consultar el estado en un test, en un manejador de eventos o en una comprobación puntual sin montar una corrutina.

Ese value es también la frontera conceptual con el mundo frío. Un Flow frío no tiene un valor actual porque no hay nada corriendo; preguntar “¿cuál es tu valor?” no significa nada. Un StateFlow está caliente: hay un valor guardado en memoria, con o sin observadores, y sigue ahí cuando el último se va. Por eso no termina jamás —no tiene sentido que una fotografía se acabe— y por eso collect sobre un StateFlow es una suspensión perpetua que solo la cancelación interrumpe.

Conflado y deduplicado: la semántica que la interfaz necesita

El segundo rasgo es la conflación. Si el estado cambia diez veces mientras un coleccionista está ocupado dibujando, ese coleccionista no recibirá diez emisiones al reanudarse: recibirá una, la última. Los valores intermedios se pierden, y esa pérdida es una virtud, no un defecto. Una interfaz no necesita repintar los nueve fotogramas que ya caducaron; necesita mostrar el actual. StateFlow no tiene búfer ni cola de pendientes: tiene una casilla que se sobrescribe.

El tercer rasgo es la deduplicación por igualdad. Si asignas un valor igual —según equals— al que ya había, no se emite nada. De ahí se sigue una consecuencia práctica de primer orden: la inmutabilidad de tu clase de estado deja de ser una preferencia estética y pasa a ser un requisito operativo. Si tu data class de estado contiene una lista mutable y la modificas en el sitio, el equals seguirá diciendo que nada cambió y la interfaz no se enterará; peor aún, será un fallo silencioso, sin excepción ni aviso. La regla que lo evita es la del nivel uno: estado inmutable, cambios siempre con copy.

flowchart TD
S[MutableStateFlow con un unico valor guardado] --> C{Llega un valor nuevo}
C -->|Igual al actual segun equals| N[No se emite nada]
C -->|Distinto| E[Se sobrescribe y se emite el ultimo]
E --> L[Coleccionista lento ve solo el ultimo]
E --> R[Suscriptor nuevo recibe el actual al instante]
style S fill:#89b4fa,color:#11111b
style N fill:#f9e2af,color:#11111b
style R fill:#a6e3a1,color:#11111b

Esa conflación tiene una implicación que conviene aceptar sin resistencia: StateFlow no es un registro fiel de la historia. Si el estado pasa por A, B y C mientras nadie mira, quien llegue después verá C y no sabrá jamás que existieron A y B. Para una interfaz eso es exactamente lo correcto, porque nadie quiere ver fotogramas caducados; pero significa que no debes apoyar en el estado ninguna lógica que dependa de haber visto todas las transiciones. Si necesitas contar cuántas veces pasó algo, o reaccionar a cada paso individual, ese dato no era estado y estás pidiéndole al tipo una garantía que su contrato niega explícitamente.

update: cerrar la ventana de la actualización perdida

Hay una trampa que casi todo el mundo pisa una vez. La forma intuitiva de cambiar el estado es leerlo, copiarlo y asignarlo: _state.value = _state.value.copy(cargando = true). Cada una de esas operaciones es atómica por separado, pero la secuencia entera no lo es. Entre la lectura y la escritura cabe otra corrutina que también leyó el valor viejo, copió sobre él y escribió; cuando la primera escriba, sobrescribirá el trabajo de la segunda sin enterarse. Es la actualización perdida clásica, y en un ViewModel con varias corrutinas concurrentes ocurre de verdad, aunque de forma intermitente y por eso difícil de diagnosticar.

// Fragil: leer, copiar y escribir son tres pasos, y otra corrutina cabe en medio
_state.value = _state.value.copy(cargando = true)

// Correcto: comparacion e intercambio atomicos, reintenta si alguien se adelanto
_state.update { actual -> actual.copy(cargando = true) }

fun cargar() = viewModelScope.launch {
    _state.update { it.copy(cargando = true, error = null) }
    val resultado = runCatching { repo.tareas() }
    _state.update { actual ->
        resultado.fold(
            onSuccess = { lista -> actual.copy(cargando = false, tareas = lista) },
            onFailure = { e -> actual.copy(cargando = false, error = e.message) },
        )
    }
}

update recibe una función del estado viejo al nuevo y la aplica con una comparación e intercambio atómicos: si al ir a escribir descubre que el valor ha cambiado desde que lo leyó, descarta el resultado y vuelve a ejecutar la lambda con el valor fresco. De ahí sale la única regla que hay que respetar: esa lambda debe ser pura y barata, porque puede ejecutarse más de una vez. Nada de llamadas de red dentro, nada de efectos observables; solo transformar datos.

Hay una segunda ventaja de update que se aprecia al leer código ajeno: expresa la actualización como una función del estado anterior, que es exactamente la forma en que hay que pensar el estado en MVI. Al escribir la asignación directa se pierde esa lectura, porque el estado nuevo aparece como un valor cualquiera que alguien decidió poner ahí; con update queda claro que el estado siguiente se deriva del anterior y que ninguna otra fuente participa en la decisión. La diferencia es de intención tanto como de atomicidad.

Merece subrayar la simetría con lo que ya sabes de Orbit. reduce es esta misma idea elevada a convención: una transformación pura del estado anterior al siguiente, serializada por la librería para que nunca haya dos reducciones pisándose. Cuando escribes MVI a mano sobre MutableStateFlow, update es la pieza que te da esa garantía; cuando usas Orbit, ya la tienes puesta. Reconocer que son la misma idea con dos nombres es entender qué parte del trabajo te está quitando la librería.

El hogar natural del Model

Junta ahora los tres rasgos y compáralos con lo que MVI pide de su Model. El Model debe existir siempre y ser total, sin estados indefinidos: StateFlow exige valor inicial. El Model es una fotografía de la que solo importa la más reciente: StateFlow conflaciona. El Model debe sobrevivir a que la vista muera y renazca, y entregarse íntegro al nuevo observador: StateFlow retiene el valor y lo emite al suscribirse. El Model se reemplaza entero, nunca se muta por partes: StateFlow deduplica por igualdad, lo que solo funciona bien si respetas esa disciplina. No es que StateFlow sirva para el Model; es que el contrato de StateFlow y el contrato del Model coinciden punto por punto.

@Composable
fun TareasScreen(viewModel: TareasViewModel) {
    val state by viewModel.state.collectAsStateWithLifecycle()

    when {
        state.cargando -> Indicador()
        state.error != null -> ErrorView(state.error!!)
        else -> Lista(state.tareas)
    }
}

Hay un beneficio de esa coincidencia que solo se aprecia al escribir pruebas. Como el estado es un valor consultable y no una secuencia de notificaciones, un test no necesita observadores falsos, ni esperas, ni verificaciones de llamadas: invoca la función, lee value y compara con el estado esperado. Y como la transformación es pura, el test es determinista por construcción. Esa facilidad no es un premio adicional: es el mismo rasgo —una sola verdad consultable— visto desde el banco de pruebas.

@Test
fun `cargar deja la lista y apaga el indicador`() = runTest {
    val vm = TareasViewModel(RepoFalso(listOf(Tarea("uno"))))
    vm.cargar()
    val estado = vm.state.value            // sin observadores ni esperas
    assertEquals(false, estado.cargando)
    assertEquals(1, estado.tareas.size)
}

collectAsStateWithLifecycle es la forma correcta en Android de cerrar el circuito: colecciona mientras la pantalla está al menos iniciada y deja de hacerlo cuando pasa a segundo plano, sin que tú escribas una línea de ciclo de vida. Al volver, el valor actual se entrega de inmediato porque StateFlow nunca dejó de tenerlo. La rotación deja de ser un caso especial: la vista muere, el ViewModel sobrevive con su estado intacto y la vista nueva pregunta y recibe. Ese es el final feliz que las banderas y los envoltorios de la era anterior intentaban simular a mano.