Ports de entrada: recibir del exterior como una Sub

Si el port de salida es un buzón donde depositas cartas, el de entrada es la ranura por la que llegan las que no pediste. La diferencia no es de dirección solamente, es de iniciativa: nadie en Elm decide cuándo entra un dato. Lo decide el anfitrión, cuando le parece, tantas veces como quiera, sin coordinación con lo que la aplicación esté haciendo. Por eso el tipo de un port de entrada no es un comando sino una suscripción, y por eso comparte naturaleza con el reloj, el teclado y el redimensionado de la ventana. Desde dentro de la aplicación, el código JavaScript del anfitrión no es un colaborador al que se consulta: es una fuente de eventos externa, tan ajena e impredecible como el usuario. Esa equiparación, que al principio parece una curiosidad de diseño, resulta ser la clave para tratar con rigor lo que llega de fuera.

La firma invertida y por qué recibe una función

La declaración de un port de entrada desconcierta la primera vez que se lee, porque su parámetro es una función. Concretamente, una función que toma el dato entrante y devuelve un mensaje de tu vocabulario. La razón es que el port por sí solo no sabe qué significa para tu aplicación que llegue una cadena: solo tú sabes que eso debe convertirse en un LlegoTexto o en un ActualizarPreferencia. Al pasarle el constructor, le entregas la traducción, y el port devuelve una suscripción ya especializada en tu tipo de mensajes.

port module Externo exposing (main)

import Json.Decode


-- Recibe el constructor, devuelve la escucha ya tipada
port desdeFuera : (Json.Decode.Value -> msg) -> Sub msg


-- Al usarlo, el msg genérico se instancia con el tuyo
subscriptions : Model -> Sub Msg
subscriptions model =
    if model.conectado then
        desdeFuera LlegoDelExterior

    else
        Sub.none

Nota que la suscripción se declara condicionalmente, exactamente igual que cualquier otra. Si el modelo dice que la aplicación no está conectada, subscriptions no devuelve la escucha y el runtime la cancela. Los datos que el anfitrión empuje durante ese intervalo no se encolan ni se entregan después: se descartan. Escuchar sigue siendo estado derivado del modelo, y esa propiedad no cambia porque la fuente sea JavaScript en lugar de un reloj.

Del send del anfitrión al update de la aplicación

Del lado de JavaScript, cada port de entrada aparece como un objeto con un método de envío. Llamarlo encola un mensaje que el runtime despachará por update en el próximo turno del bucle de eventos. El anfitrión puede llamarlo desde donde quiera: desde el manejador de un evento del navegador, desde la respuesta de una promesa, desde el oyente de un websocket o desde un temporizador. Para Elm, todas esas procedencias son indistinguibles.

const app = Elm.Main.init({ node: document.getElementById("raiz") });

// Un websocket empuja mensajes cuando quiere
const socket = new WebSocket("wss://ejemplo.test/sala");
socket.addEventListener("message", function (evento) {
  app.ports.desdeFuera.send(JSON.parse(evento.data));
});

// Otra fuente distinta, el mismo port
window.addEventListener("online", function () {
  app.ports.desdeFuera.send({ tipo: "conexion", estado: "recuperada" });
});

flowchart LR
WS[WebSocket o evento del navegador] --> H[anfitrion JS]
H -->|send| RT[runtime de Elm]
RT -->|solo si subscriptions lo declara| S[Sub del port]
S -->|Msg con Value crudo| U[update]
U -->|decodifica en la frontera| M[Model o error del dominio]
style H fill:#f9e2af,color:#11111b
style U fill:#89b4fa,color:#11111b
style M fill:#a6e3a1,color:#11111b

Decodificar en la frontera: el tipo declarado no es una verdad

Aquí está la lección más importante y la que más a menudo se aprende tarde. Nada impide declarar un port de entrada con un tipo concreto, por ejemplo una función que reciba un entero y devuelva un mensaje. El compilador lo aceptará y el código quedará más corto. El problema es que ese tipo no lo verifica nadie: es una promesa que el anfitrión puede incumplir, y si envía una cadena donde prometía un entero, el valor entrará en el modelo con un tipo mentido y el programa fallará más tarde, en un punto arbitrario y sin relación aparente con la causa. Es precisamente la clase de error que Elm existe para eliminar.

La disciplina correcta es declarar el port sobre Json.Decode.Value, que es el tipo de lo desconocido, y decodificar en cuanto el mensaje llega a update. Así la sospecha vive en un solo lugar, se resuelve inmediatamente y el modelo solo recibe valores cuya forma se ha comprobado.

type Msg
    = LlegoDelExterior Json.Decode.Value


type alias Aviso =
    { titulo : String, urgente : Bool }


decodificador : Json.Decode.Decoder Aviso
decodificador =
    Json.Decode.map2 Aviso
        (Json.Decode.field "titulo" Json.Decode.string)
        (Json.Decode.field "urgente" Json.Decode.bool)


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        LlegoDelExterior crudo ->
            case Json.Decode.decodeValue decodificador crudo of
                Ok aviso ->
                    ( { model | avisos = aviso :: model.avisos }, Cmd.none )

                Err error ->
                    -- El anfitrión incumplió el contrato: es un caso del dominio
                    ( { model | ultimoFallo = Just (Json.Decode.errorToString error) }
                    , Cmd.none
                    )