Sub: suscribirse a los eventos que el mundo emite

Un Cmd resuelve la mitad del problema de los efectos: los que tú inicias y que ocurren una vez, como pedir un recurso o tirar un dado. Pero hay otra mitad de naturaleza distinta. Hay cosas que no inicias tú y que suceden en el exterior de forma continua, a su propio ritmo: el reloj que avanza segundo a segundo, los mensajes que llegan por un websocket cuando al servidor le apetece enviarlos, las teclas que el usuario pulsa, la ventana que cambia de tamaño. Frente a esas fuentes no quieres ordenar haz esto una vez, sino declarar avísame cuando esto ocurra. Esa es la función de Sub, las suscripciones. Y del mismo modo que Cmd describe un efecto como un valor, Sub describe una escucha como un valor: no enganchas ni desenganchas oyentes a mano, sino que declaras, en función del modelo actual, qué corrientes de eventos externos te interesan ahora, y dejas que el runtime traduzca esa declaración en oyentes reales.

Dos formas de efecto: iniciar y escuchar

La asimetría entre Cmd y Sub es la de dos direcciones del tiempo. Un Cmd es un impulso que sale de ti hacia el mundo y termina: lo lanzas, se ejecuta, vuelve un resultado, se acabó. Una Sub es una antena orientada hacia el mundo que permanece abierta: mientras la mantengas declarada, cada vez que la fuente emita —cada segundo, cada mensaje, cada tecla— llegará un Msg. Uno es de disparo único y lo inicia tu lógica; la otra es de flujo continuo y la inicia el exterior. Lo que comparten es el destino: ambos terminan convertidos en un Msg que reentra por update, de modo que ni la respuesta de una petición ni el tic de un reloj tienen una vía privilegiada para tocar el modelo. Todo pasa por la misma puerta.

flowchart LR
Reloj[Reloj] --> S[subscriptions del Model]
Teclado[Teclado] --> S
WS[WebSocket] --> S
S --> RT[runtime]
RT -->|Msg| U[update]
U -->|Model nuevo| S
style S fill:#89b4fa,color:#11111b
style U fill:#a6e3a1,color:#11111b

subscriptions es una función del modelo

Aquí está el detalle que suele sorprender y que encierra toda la potencia del diseño. Las suscripciones no se declaran una vez al arrancar; se declaran en una función subscriptions : Model -> Sub Msg que el runtime vuelve a llamar después de cada actualización del modelo. Es decir, qué escuchas es una función de tu estado actual. Si el modelo dice que un cronómetro está en marcha, devuelves la suscripción al reloj; si dice que está en pausa, devuelves Sub.none, y el reloj deja de entregar tics. No paras el temporizador con una orden imperativa: cambias el modelo, y la suscripción declarada cambia con él.

-- Que escuchas depende del estado: es estado derivado
subscriptions : Model -> Sub Msg
subscriptions model =
    case model.estado of
        EnMarcha ->
            Sub.batch
                [ Time.every 1000 Tic
                , Browser.Events.onKeyDown teclaDecodificador
                ]

        Pausado ->
            -- sin suscripciones: el reloj deja de emitir
            Sub.none

Time.every 1000 Tic declara que quieres un mensaje Tic cada mil milisegundos. Browser.Events.onKeyDown declara que quieres un mensaje por cada tecla pulsada, decodificado del evento del navegador. Sub.batch combina varias suscripciones en una, igual que Cmd.batch hacía con los comandos, y Sub.none es la ausencia de escucha. Un puerto de entrada, port recibir : (Valor -> msg) -> Sub msg, es la vía por la que un websocket o cualquier código JavaScript externo empuja eventos hacia Elm, y también produce un Sub.

Escucha declarativa: describir el conjunto, no gestionar oyentes

La consecuencia más profunda de que subscriptions sea una función del modelo es que la gestión de oyentes se vuelve declarativa. En una API imperativa clásica añades un oyente con una llamada y lo quitas con otra, y toda la corrección depende de que cada alta tenga su baja: si olvidas una, tienes una fuga de memoria o un oyente zombi que sigue disparando. Elm elimina esa clase entera de errores. Tú nunca añades ni quitas oyentes; solo describes, para el modelo actual, el conjunto de suscripciones que deberían estar activas. Después de cada update, el runtime llama de nuevo a subscriptions, compara el conjunto nuevo con el anterior y hace por ti las altas y bajas reales: activa las que aparecen, cancela las que desaparecen, deja las que siguen.

Piensa en un chat sobre websocket. Mientras el modelo diga que hay una sala abierta, subscriptions devuelve la escucha del puerto correspondiente; en cuanto el usuario sale y el modelo lo refleja, la función deja de devolverla y el runtime cierra la escucha. No hay un cerrarConexion disperso por los manejadores de eventos: hay un único lugar, subscriptions, que traduce sin ambigüedad el estado a un conjunto de escuchas. La corrección deja de depender de recordar emparejar altas y bajas y pasa a depender de una sola función pura del modelo, que puedes leer entera y razonar de un vistazo.