Eventos: toda interacción produce un mensaje

Pulsar un botón parece la operación más simple de una interfaz, y sin embargo es donde se juega casi toda la arquitectura. En el modelo habitual, el manejador que se asocia a esa pulsación es una función capaz de hacer cualquier cosa: modificar variables que viven fuera de su alcance, disparar peticiones, tocar el almacenamiento, provocar navegaciones y llamar a otros manejadores. El resultado es que el comportamiento de una aplicación queda esparcido por sus hojas, y que responder a la pregunta qué pasa cuando el usuario pulsa aquí exige leer el árbol entero, porque el efecto puede estar en cualquier nodo. Elm hace lo contrario, y lo hace con una restricción que parece pobre hasta que se ve funcionar: el manejador no puede ejecutar nada. Lo único que puede hacer es nombrar el mensaje que se emitirá. Ese mensaje sale de la vista, entra en el runtime y vuelve a la aplicación por la puerta de update, que es el sitio único y central donde se decide qué significa cada cosa que el usuario hace. La vista, entonces, no reacciona a los eventos: los traduce a vocabulario.

El manejador declara vocabulario, no comportamiento

Las tres funciones de uso diario del módulo de eventos dicen todo lo que hay que saber sobre el diseño. La que atiende la pulsación recibe directamente un mensaje, porque el hecho de que alguien pulse no aporta ningún dato adicional: el evento es la información completa. La que atiende la escritura recibe en cambio una función que va de una cadena a un mensaje, porque el evento sí trae un dato, el texto actual del campo, y hay que decir cómo se empaqueta ese dato dentro del vocabulario de la aplicación. La que atiende el envío de un formulario vuelve a recibir un mensaje directo y además cancela el comportamiento por defecto del navegador, que consistiría en recargar la página.

onClick  : msg -> Attribute msg
onInput  : (String -> msg) -> Attribute msg
onSubmit : msg -> Attribute msg


type Msg
    = Incrementado
    | TextoEscrito String
    | FormularioEnviado


view : Model -> Html Msg
view model =
    Html.form [ onSubmit FormularioEnviado ]
        [ input [ value model.texto, onInput TextoEscrito ] []
        , button [ onClick Incrementado ] [ text "Sumar" ]
        ]

Merece la pena detenerse en lo que ocurre al escribir un constructor sin aplicarlo del todo. En el ejemplo, TextoEscrito no es un mensaje sino una función que espera una cadena y devuelve un mensaje, y por eso encaja exactamente en la firma que pide onInput. No hay ninguna magia ni ninguna conversión implícita: los constructores de un tipo unión con datos son funciones ordinarias, y aquí se aprovechan como tales. Esa coincidencia entre lo que un evento aporta y lo que un constructor necesita es la razón de que el código de eventos en Elm sea tan corto sin dejar de estar tipado en cada punto.

El campo controlado y el ciclo cerrado

El caso del campo de texto es el que mejor enseña la forma del bucle, porque es donde la intuición heredada falla más. En el modelo tradicional, el campo es el dueño de su contenido: el usuario escribe, el elemento guarda lo escrito y el programa lo consulta cuando lo necesita. En Elm el campo no es dueño de nada. El atributo que fija su contenido lee del modelo, así que lo que se ve en pantalla siempre es lo que el modelo dice. Cuando el usuario teclea, no se modifica el campo: se emite un mensaje con el texto propuesto, update decide qué hacer con él, y el nuevo modelo produce un nuevo árbol donde el campo muestra el valor resultante. El recorrido es completo y pasa por el centro, siempre.

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        TextoEscrito propuesto ->
            ( { model | texto = String.toUpper propuesto }, Cmd.none )

        FormularioEnviado ->
            ( { model | enviando = True }, enviar model.texto )

        Incrementado ->
            ( { model | cuenta = model.cuenta + 1 }, Cmd.none )

Ese detalle aparentemente anecdótico del texto convertido a mayúsculas contiene toda la tesis. La transformación no ocurre en la vista ni en el elemento del documento, ocurre en el único punto donde se toma decisiones, y por eso vale igual para el texto que llega tecleado, para el que llega pegado desde el portapapeles y para el que llega de una respuesta del servidor. Validar, normalizar, truncar o rechazar una entrada dejan de ser trucos aplicados en el borde y se convierten en reglas del dominio escritas una sola vez. La regla práctica que se sigue de aquí es simple: si algo debe ocurrir cuando cambia un dato, no hay ningún lugar donde escribirlo salvo update.

flowchart LR
U[Usuario teclea] --> E[onInput]
E --> M[Msg con el texto]
M --> R[Runtime]
R --> A[update decide]
A --> N[Modelo nuevo]
N --> V[view]
V --> P[Campo con el valor final]
style M fill:#89b4fa,color:#11111b
style A fill:#a6e3a1,color:#11111b
style P fill:#cba6f7,color:#11111b

Eventos personalizados: la frontera pasa por un decodificador

Las funciones cómodas del módulo cubren lo frecuente, pero no son primitivas: todas se construyen sobre un mecanismo general en el que un evento se declara con su nombre y con un decodificador que extrae del objeto entregado por el navegador exactamente el dato que interesa. Esto importa porque ese objeto es un valor del mundo exterior, sin tipo y sin garantías, y el sistema de Elm no lo deja entrar por la puerta de atrás: entra por la misma aduana que cualquier respuesta de red. Si el campo que se busca no existe o no tiene la forma declarada, el decodificador falla y sencillamente no se emite ningún mensaje.

-- El mecanismo general: nombre del evento mas decodificador
on : String -> Decoder msg -> Attribute msg


-- Un evento propio: pulsar Enter dentro de un campo
onEnter : msg -> Attribute msg
onEnter mensaje =
    on "keydown"
        (Decode.field "key" Decode.string
            |> Decode.andThen
                (\tecla ->
                    if tecla == "Enter" then
                        Decode.succeed mensaje

                    else
                        Decode.fail "otra tecla"
                )
        )

El detalle elegante está en el fallo del decodificador. En este diseño, fallar no es un error que haya que tratar: es la manera de decir que ese evento concreto no interesa. Pulsar cualquier tecla distinta produce un decodificador fallido, no se emite mensaje, update no se ejecuta y la vista no se recalcula. El filtrado del evento se expresa así con la misma herramienta que la extracción del dato, sin condicionales imperativos ni cancelaciones. Cuando además hace falta gobernar la propagación o el comportamiento por defecto, existen variantes que devuelven, junto al mensaje, las decisiones correspondientes; y la variante más general devuelve un registro con el mensaje y ambas banderas, de modo que también esas decisiones se calculan a partir del dato decodificado en vez de fijarse a mano.

-- Variantes que deciden junto al mensaje
stopPropagationOn : String -> Decoder ( msg, Bool ) -> Attribute msg
preventDefaultOn  : String -> Decoder ( msg, Bool ) -> Attribute msg


-- Leer el valor del campo sin usar onInput
onCambio : (String -> msg) -> Attribute msg
onCambio aMensaje =
    on "change" (Decode.map aMensaje (Decode.at [ "target", "value" ] Decode.string))