Pureza total: update no tiene efectos secundarios

De las cuatro piezas, update es la que carga con el compromiso más radical de todo el patrón: es una función matemática. Le das un Msg y un Model, y te devuelve un Model; con los mismos argumentos, siempre el mismo resultado, y por el camino no toca absolutamente nada del mundo exterior. No lee el reloj, no lanza un dado, no llama a una API, no escribe en disco, no imprime un log con consecuencias. Dicho así, suena bonito y también imposible: una aplicación que no puede pedir datos ni saber la hora no sirve para nada. La genialidad de Elm no está en negar los efectos, sino en un truco conceptual que los reconcilia con la pureza —tratarlos como datos— y ese truco es el que hay que entender hoy, porque es exactamente lo que Redux, TCA y MVI copiarían después.

La forma fuerte de la pureza

Que update sea pura significa dos cosas a la vez, y basta romper una para perder las garantías. Determinismo: para el mismo par de entradas produce siempre la misma salida; nada de Date.now, nada de aleatoriedad, nada de leer variables externas que puedan cambiar. Ausencia de efectos: no provoca nada observable fuera de su valor de retorno; no manda peticiones, no escribe en almacenamiento, no dispara otras funciones con consecuencias. Todo lo que necesita entra por sus dos parámetros; todo lo que produce sale por su return.

-- Una funcion matematica: (Msg, Model) determina el Model, y nada mas
update : Msg -> Model -> Model
update msg model =
    case msg of
        Incrementar ->
            { model | cuenta = model.cuenta + 1 }

        Reiniciar ->
            { model | cuenta = 0 }

En Haskell, de donde Elm hereda su linaje, esta idea se lee directamente en el tipo: una función cuya firma no menciona IO no puede, por construcción del lenguaje, tener efectos. El tipo es la promesa, y el compilador es quien la hace cumplir.

-- Sin IO en la firma: el tipo GARANTIZA que no hay efectos ocultos
update :: Msg -> Model -> Model

-- Con IO en la firma: el tipo CONFIESA que aqui puede pasar cualquier cosa
cargarDatos :: IO Model

La paradoja y su resolución: efectos como datos

Aquí surge la objeción evidente. Si update no puede hacer HTTP, ni leer el reloj, ni pedir un número al azar, ¿cómo carga una app real sus datos del servidor? La respuesta de Elm es una de las ideas más elegantes de la programación de interfaces: update no ejecuta el efecto, sino que devuelve una descripción del efecto que quiere que ocurra, y deja que el runtime —la parte impura— lo ejecute por ella.

Para eso, la firma de update crece un poco. En una app con efectos usamos Browser.element, y update pasa a devolver una tupla: el Model nuevo y un Cmd Msg, donde Cmd es un dato inerte que describe “quiero que hagas esta petición y, cuando termine, me avises con este Msg”.

type Estado
    = Inicial
    | Cargando
    | Listo String
    | Fallo

type Msg
    = Pedir
    | Recibido (Result Http.Error String)

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        Pedir ->
            -- update NO hace la peticion: devuelve un DATO que la describe
            ( { model | estado = Cargando }
            , Http.get
                { url = "/api/frase"
                , expect = Http.expectString Recibido
                }
            )

        Recibido (Ok texto) ->
            ( { model | estado = Listo texto }, Cmd.none )

        Recibido (Err _) ->
            ( { model | estado = Fallo }, Cmd.none )

Sigue todo el hilo, porque es el corazón del asunto. En la rama Pedir, update no toca la red: construye un valor Cmd que la describe y lo devuelve junto al modelo Cargando. update termina y sigue siendo pura: le diste Pedir y un modelo, te devolvió un modelo nuevo y una descripción, sin haber tocado nada. Entonces el runtime toma ese Cmd, ejecuta la petición de verdad en el mundo impuro, y cuando la respuesta llega, la envuelve en un Msg Recibido y la mete por el principio del bucle. update se ejecuta otra vez, ahora con datos ya presentes en el mensaje, y vuelve a ser una función pura de sus entradas.

flowchart LR
U[update puro] -->|devuelve Cmd como dato| R[runtime impuro]
R -->|ejecuta el efecto en el mundo| W[HTTP tiempo azar]
W -->|resultado| R
R -->|lo envuelve en un Msg| U
style U fill:#a6e3a1,color:#11111b
style R fill:#cba6f7,color:#11111b
style W fill:#f38ba8,color:#11111b

La misma idea gobierna Sub para los efectos entrantes continuos —el tic de un reloj, un websocket, el teclado—: no los escuchas tú, declaras una suscripción como dato y el runtime te manda un Msg cada vez que ocurre algo. El patrón es idéntico: tú describes, el runtime ejecuta.

Lo que la pureza compra

La pureza de update no es una exigencia estética; es una inversión que paga dividendos concretos. Testing trivial: para probar update le pasas un Msg y un Model y compruebas el Model que sale; no hay red que simular, ni reloj que congelar, ni mocks que montar, porque no hay nada externo de lo que update dependa. Reproducibilidad: como update es determinista y los Msg son datos, grabar la lista de mensajes de una sesión y reaplicarla reconstruye exactamente el mismo estado, siempre. Viaje en el tiempo: de esa reproducibilidad nace el depurador que rebobina y avanza por los estados —Elm lo tuvo antes que nadie, y de él salió, reconocido por su autor, el time-travel de las Redux DevTools—.

-- Un test de update es aritmetica: sin mocks, sin setup, sin mundo
prueba : Bool
prueba =
    update Incrementar { cuenta = 0 } == { cuenta = 1 }

Todas estas capacidades cuelgan del mismo clavo. Si update llamara a una API o leyera la hora, reproducir el historial daría resultados distintos cada vez —la API responde otra cosa, el reloj avanza—, el test necesitaría simular medio mundo y el viaje en el tiempo sería ficción. Se compran a la vez, con una sola moneda: mantener update puro y empujar los efectos al borde.

Vale la pena subrayar que ninguna de estas tres ventajas es una funcionalidad que Elm programó aparte. Nadie escribió un módulo de “testing trivial” ni un motor de “viaje en el tiempo” como características añadidas; las tres son consecuencias que caen solas en cuanto update es una función matemática. Esta es la diferencia entre una propiedad emergente y una prestación: una prestación se construye y se mantiene, una propiedad emergente simplemente ocurre porque las piezas cumplen ciertas leyes. Cuando alguien te ofrezca time-travel como un extra vistoso de su librería, la pregunta correcta no es cómo lo implementaron, sino si su transición es realmente pura y sus mensajes realmente datos; si no lo son, el extra será frágil, y si lo son, casi no habrá hecho falta implementarlo.