El runtime por dentro: el bucle de eventos, la cola de mensajes y el instante del dibujado

Hasta ahora el runtime ha sido una palabra cómoda: eso que llama a update, eso que ejecuta los comandos, eso que se encarga del documento. Se puede escribir una aplicación entera sin abrir esa caja, y esa es precisamente su virtud. Pero llega un momento, normalmente cuando algo va más despacio de lo esperado o cuando un comportamiento no encaja con el modelo mental, en que la caja hay que abrirla. Dentro no hay magia: hay una variable que guarda el modelo, una función que se llama con un mensaje cada vez, un mecanismo que impide que dos llamadas se solapen, un conjunto de gestores que traducen descripciones de efecto en llamadas reales al navegador, y un temporizador que decide cuándo vale la pena volver a mirar la pantalla. Es un diseño sorprendentemente pequeño, y su tamaño no es accidental: la mayor parte de la complejidad que otros entornos necesitan resolver en tiempo de ejecución —qué componentes tienen estado propio, qué actualizaciones pueden interrumpirse, qué hacer si el usuario muta un valor que se le pasó a la vista— aquí simplemente no existe, porque el lenguaje la eliminó antes de compilar. Conocer el bucle no cambia lo que escribes en un día normal. Cambia tu capacidad de explicar por qué el programa hace lo que hace cuando deja de ser un día normal.

La única celda mutable de todo el sistema

Al arrancar, el runtime evalúa init, guarda el modelo resultante en una variable interna y monta la vista inicial en el documento. Esa variable es la totalidad del estado mutable del programa: no hay campos que se reasignen, ni objetos compartidos, ni referencias que dos partes del código puedan tocar a la vez. Todo lo demás es inmutable por construcción, así que la superficie sobre la que puede aparecer una inconsistencia se reduce a un único punto, y ese punto solo lo escribe el bucle. Cuando decimos que el estado está centralizado no describimos una convención de arquitectura sino un hecho literal de la implementación.

El bucle recibe mensajes de cuatro procedencias y no distingue entre ellas: un manejador de la vista que decodificó un evento del documento, un gestor de efectos que terminó una petición, una suscripción activa que emitió un valor, o un puerto de entrada por el que el anfitrión envió algo. Sea cual sea el origen, el tratamiento es idéntico y es el que ya conoces desde el primer nivel, salvo que ahora conviene verlo escrito como lo que realmente es: una secuencia estricta de cinco pasos que se ejecuta de principio a fin sin interrupciones.

-- El bucle, escrito como si fuera Elm
paso : Msg -> Estado -> Estado
paso msg estado =
    let
        ( modeloNuevo, comando ) =
            update msg estado.modelo
    in
    estado
        |> guardarModelo modeloNuevo
        |> despachar comando
        |> reconciliarSuscripciones (subscriptions modeloNuevo)
        |> marcarVistaPendiente

El detalle decisivo es que ese paso es indivisible. Si mientras se ejecuta llega otro mensaje —porque un puerto llamó a su propia devolución de forma sincrónica, o porque un efecto se resolvió al instante— no se abre una segunda ejecución encima de la primera: el mensaje espera. La consecuencia es que jamás existe un modelo a medio construir, jamás dos actualizaciones compiten por escribir la misma celda, y jamás una función lee un estado que otra está a punto de invalidar. La familia entera de errores por reentrada, que en un entorno con devoluciones de llamada es una fuente inagotable de defectos intermitentes, aquí no tiene dónde manifestarse.

Los efectos salen, los mensajes vuelven

El comando que devuelve update no ejecuta nada: es una descripción etiquetada con el gestor que sabrá interpretarla. El runtime la entrega al gestor correspondiente —el de peticiones, el del tiempo, el de la aleatoriedad, el de tus puertos— y ahí termina su responsabilidad. Cada gestor mantiene su propio estado interno, hace el trabajo impuro que haga falta y, cuando obtiene un resultado, lo empaqueta como un mensaje del vocabulario de la aplicación y lo devuelve al bucle. Ese retorno es un mensaje corriente, indistinguible de un clic, y por eso la lógica que lo trata es la misma función update de siempre.

Las suscripciones siguen la ruta simétrica y añaden un matiz que no siempre se aprecia. Después de cada actualización, el runtime vuelve a evaluar subscriptions con el modelo nuevo y compara el conjunto resultante con el anterior; lo que aparece se activa, lo que desaparece se desactiva, y lo que sigue igual no se toca. Esa reconciliación es la que convierte una declaración —qué debe estar escuchando este programa dado su estado— en las altas y bajas de escuchas reales del navegador, sin que el programador tenga que emparejar a mano ninguna suscripción con su cancelación.

-- Describir el efecto: update no lo ejecuta, lo devuelve
update msg model =
    case msg of
        PidioDatos ->
            ( { model | cargando = True }
            , Http.get { url = "/api/items", expect = Http.expectJson Recibio decoder }
            )

        Recibio resultado ->
            -- El resultado vuelve como un mensaje mas de la cola
            ( { model | cargando = False, items = fromResult resultado }, Cmd.none )

El dibujado no ocurre donde crees

Aquí está la pieza que más veces contradice el modelo mental de quien llega. Terminar un paso del bucle no repinta la pantalla: solo anota que la vista quedó obsoleta y pide al navegador un hueco en el próximo fotograma. Si en ese intervalo se procesan diez mensajes, se ejecutan diez actualizaciones y se guardan diez modelos, pero solo el último se dibuja, y de la vista solo se evalúa una versión. El trabajo de construir descripciones y compararlas queda así acotado por la frecuencia de refresco de la pantalla y no por la frecuencia con que llegan los eventos, que es la diferencia entre una aplicación que sobrevive a un flujo intenso de mensajes y una que se ahoga en él.

flowchart TD
E[Evento decodificado] --> Q[Cola de mensajes]
R[Resultado de un comando] --> Q
S[Emision de una suscripcion] --> Q
Q --> U[update sobre el modelo actual]
U --> G[Guardar modelo en la celda]
G --> D[Despachar comandos a los gestores]
G --> N[Reconciliar suscripciones]
G --> M[Marcar vista pendiente]
M --> F[Proximo fotograma dibuja una sola vez]
D --> R
style Q fill:#89b4fa,color:#11111b
style G fill:#a6e3a1,color:#11111b
style F fill:#cba6f7,color:#11111b

Esta agrupación tiene consecuencias observables que conviene tener presentes antes de diagnosticar un problema inexistente. En una pestaña de fondo el navegador deja de conceder fotogramas, así que los mensajes se siguen procesando y el modelo se sigue actualizando, pero nada se dibuja hasta que la pestaña vuelve al frente, momento en el que aparece de golpe el estado final y no la secuencia intermedia. Existe además un caso deliberado en el que el runtime renuncia a esperar y dibuja de forma sincrónica: ciertos manejadores de eventos de entrada lo fuerzan, porque un campo de texto controlado que muestre durante una fracción de segundo el valor anterior produce saltos de cursor perceptibles. Es la excepción que confirma la regla, y existe por una razón de percepción, no de corrección.

Qué puedes suponer del bucle y qué no

Conviene separar con precisión las garantías reales de las creencias que se le atribuyen sin fundamento, porque casi todos los razonamientos erróneos sobre concurrencia en Elm nacen de mezclar unas con otras. Puedes suponer cuatro cosas y las cuatro son firmes: que una actualización se ejecuta entera antes de que empiece otra; que el modelo queda comprometido en la celda antes de que se despache ningún comando, de modo que ningún efecto puede observar un estado a medio construir; que las suscripciones se reconcilian después de cada actualización y no en un instante indeterminado; y que la vista se evalúa siempre sobre un modelo comprometido y nunca sobre uno intermedio.

No puedes suponer nada sobre el tiempo. No hay garantía de que dos comandos terminen en el orden en que se despacharon, ni de que un efecto termine alguna vez, ni de que exista un fotograma entre dos actualizaciones consecutivas, ni de que una suscripción emita antes que otra. Todo aquello que dependa de esas cuestiones tiene que estar representado en el modelo, y el patrón canónico consiste en etiquetar cada petición con un identificador creciente y descartar al volver las respuestas que ya no correspondan al estado vigente. Es la traducción a datos de una garantía que ningún planificador puede ofrecer.

type Msg
    = Escribio String
    | Respondio Int (Result Http.Error (List Item))


update msg model =
    case msg of
        Escribio texto ->
            let
                token =
                    model.token + 1
            in
            ( { model | consulta = texto, token = token }
            , buscar token texto
            )

        Respondio token resultado ->
            if token /= model.token then
                -- Llego tarde: describe un estado que ya no existe
                ( model, Cmd.none )

            else
                ( aplicar resultado model, Cmd.none )