El ViewModel como hogar del container MVI

Llevas tres lecciones acumulando propiedades de un objeto: sobrevive a la destrucción de la pantalla, trae un scope de corrutinas que muere con él y tiene un canal para cruzar la muerte del proceso. Ahora pon esa lista al lado de la que escribiste en el nivel del container: la lógica MVI necesita un sitio que retenga el estado más allá de la vista, un scope donde ejecutar los intent sin fugarse y una forma de rehidratarse cuando el sistema la haya borrado. Las dos listas son la misma lista. Que el container de Orbit viva dentro de un ViewModel no es una convención heredada ni un gesto de cortesía hacia Android: es la constatación de que alguien ya había resuelto, con nombres distintos, los tres problemas de infraestructura que el patrón daba por resueltos.

Por qué el container vive aquí

Cada garantía del ViewModel responde a una necesidad del patrón, y la correspondencia es punto por punto. El estado MVI es una única fuente de verdad que debe seguir viva mientras el usuario permanezca en la pantalla, aunque el sistema haya reconstruido esa pantalla siete veces: eso lo da la retención por ViewModelStore. Los intent son corrutinas que hacen trabajo asíncrono y deben cancelarse en cuanto la intención del usuario termine, sin dejar nada colgando: eso lo da viewModelScope, sobre el que la fábrica container de orbit-viewmodel construye directamente. Y la semilla desde la que ese estado se reconstruye tras la muerte del proceso llega por SavedStateHandle, que se inyecta en el constructor. Tres necesidades, tres garantías, cero infraestructura propia.

@HiltViewModel
class PerfilViewModel @Inject constructor(
    private val repo: PerfilRepo,
    handle: SavedStateHandle,
) : ContainerHost<PerfilState, PerfilEfecto>, ViewModel() {

    private val usuarioId: String = checkNotNull(handle["usuarioId"])

    override val container = container<PerfilState, PerfilEfecto>(
        initialState = PerfilState(usuarioId = usuarioId),
    ) {
        cargar()   // onCreate: se ejecuta al primer observador
    }
}

Merece detenerse en el bloque final. Ese onCreate de la fábrica no se dispara al construir el objeto, sino la primera vez que alguien empieza a observar el container, y solo esa primera vez. La diferencia es la que separa una pantalla que recarga sus datos en cada rotación de una que los carga una vez y los conserva: como el ViewModel es el mismo objeto tras el cambio de configuración, su container ya está creado y el bloque no vuelve a ejecutarse. La carga inicial se escribe una vez y se comporta bien sin condicionales defensivos del tipo comprobar si ya había datos.

El reparto dentro de la clase

Con el hogar elegido, la clase se ordena en tres zonas nítidas, y no hay una cuarta. La primera es el estado: una data class inmutable declarada fuera, con valores por defecto, que representa todo lo que la pantalla puede mostrar. No hay campos sueltos en el ViewModel que compitan con él: si un dato influye en lo que se pinta, está dentro del estado; si es una dependencia colaboradora —un repositorio, un caso de uso—, es una propiedad privada del constructor.

Conviene ser estricto con esa primera zona, porque la tentación de añadir un campo suelto es constante. Cualquier propiedad mutable que viva fuera del estado —una bandera para saber si ya se cargó, un contador de reintentos, la última consulta enviada— crea una segunda fuente de verdad que no se emite, no se serializa y no aparece en ninguna prueba. Si influye en lo que ocurre, va dentro del estado, aunque la pantalla no lo pinte.

La segunda zona son los intent, que en la práctica son las funciones públicas de la clase y constituyen su API entera. Aquí importa el vocabulario: se nombran por lo que el usuario hizo, no por lo que el sistema debe hacer a continuación. refrescar, pulsarSeguir, escribirBusqueda son buenos nombres porque describen hechos ocurridos en la interfaz; mostrarDialogo o navegarADetalle son malos porque describen decisiones de presentación y, al colarse en la firma pública, hacen que la vista mande sobre la lógica en lugar de informarla.

fun pulsarSeguir() = intent {
    reduce { state.copy(enviando = true) }
    runCatching { repo.seguir(state.usuarioId) }
        .onSuccess { reduce { state.copy(enviando = false, siguiendo = true) } }
        .onFailure {
            reduce { state.copy(enviando = false) }
            postSideEffect(PerfilEfecto.Aviso("No se pudo completar"))
        }
}

Hay una consecuencia del vocabulario que suele pasar inadvertida y que decide la calidad del diseño a medio plazo: si las funciones públicas nombran hechos del usuario, el ViewModel puede cambiar por completo su reacción sin que la vista se entere. Que pulsar seguir dispare una confirmación, una petición optimista o una cola diferida es una decisión interna. Si en cambio la función se llamara mostrar diálogo de confirmación, esa decisión habría quedado congelada en la firma, y cambiarla obligaría a tocar todas las pantallas que la invocan.

La tercera zona son los side effects, declarados como una sealed interface externa y emitidos únicamente con postSideEffect. Fíjate en el ejemplo: el fallo produce dos cosas distintas y deliberadamente separadas. Por un lado un reduce que devuelve el estado a la normalidad, porque el hecho de que ya no se esté enviando es estado; por otro un efecto con el aviso, porque mostrar un mensaje una vez no es estado. Esa separación, que estudiaste a nivel de tipos en el container, se materializa aquí como disciplina de escritura línea a línea.

flowchart TD
UI[Vista] -->|llama funciones publicas| VM[ViewModel que es ContainerHost]
VM --> CT[container sobre viewModelScope]
CT --> RD[reduce actualiza el estado]
CT --> PS[postSideEffect emite un evento]
RD --> SF[stateFlow]
PS --> SE[sideEffectFlow]
SF -->|colecciona| UI
SE -->|colecciona| UI
SH[SavedStateHandle] --> CT
style CT fill:#a6e3a1,color:#11111b
style UI fill:#89b4fa,color:#11111b
style SH fill:#f9e2af,color:#11111b

La frontera con la vista

Mira el diagrama y verás que la frontera no es simétrica, y esa asimetría es el diseño entero. Hacia dentro entran llamadas a funciones: gestos discretos, con nombre, sin valor de retorno. Hacia fuera no sale nada llamable: salen dos flujos que la vista observa. La vista nunca pregunta ni tira del estado, y el ViewModel nunca conoce a la vista. Esa asimetría es lo que hace que el mismo ViewModel sirva sin cambios para una pantalla en Compose, una pantalla en vistas clásicas, una prueba instrumentada o un test unitario: ninguno de esos consumidores es especial, todos hacen lo mismo.

@Composable
fun PerfilScreen(viewModel: PerfilViewModel = hiltViewModel()) {
    val state by viewModel.collectAsState()

    viewModel.collectSideEffect { efecto ->
        when (efecto) {
            is PerfilEfecto.Aviso -> mostrarAviso(efecto.texto)
            is PerfilEfecto.Volver -> navegador.atras()
        }
    }

    PerfilContenido(state = state, onSeguir = viewModel::pulsarSeguir)
}

Esa asimetría tiene además una lectura temporal. Las funciones que entran son momentos: ocurren una vez, no se repiten y no dejan rastro por sí mismas. Los flujos que salen son continuidades: siempre tienen algo que ofrecer a quien se asome, incluso a quien se asoma tarde. Confundir ambas direcciones —pedir un dato al ViewModel con una función que devuelva el estado, o entregar un evento a la vista mediante una propiedad que se lee— es lo que rompe el modelo, porque introduce lecturas que no reaccionan y valores que se consumen sin que nadie sepa cuándo.

El detalle que conviene notar es que el Composable que de verdad pinta —PerfilContenido— no recibe el ViewModel, sino un estado y unas funciones. Elevar así el estado deja el árbol de interfaz completamente ignorante de que existe Orbit, de que existe Android y de dónde vinieron los datos, lo que lo hace previsualizable y probable de forma aislada. El ViewModel es entonces la única pieza que conoce a ambos mundos, y su tamaño mide bien lo sano que está el diseño: si crece, casi siempre es porque está haciendo trabajo que pertenecía al dominio o a la vista.

Esa frontera también resuelve una duda habitual sobre la granularidad. Una pantalla con varias secciones no necesita un ViewModel por sección: necesita un estado con varias partes y funciones que nombren los gestos de cada una. Multiplicar los ViewModel dentro de una misma pantalla reparte la fuente de verdad, obliga a sincronizarlos entre sí y devuelve por la puerta de atrás justo el problema que el patrón venía a eliminar. La regla razonable es un container por intención del usuario, y una pantalla suele ser exactamente eso.

@Test
fun `pulsar seguir marca enviando y termina siguiendo`() = runTest {
    val vm = PerfilViewModel(repoFalso, SavedStateHandle(mapOf("usuarioId" to "42")))
    vm.test(this) {
        expectInitialState()
        containerHost.pulsarSeguir()
        expectState { copy(enviando = true) }
        expectState { copy(enviando = false, siguiendo = true) }
    }
}