La lección universal: el efecto como un dato que un runtime ejecuta

A lo largo de este nivel hemos visto a Elm hacer una y otra vez el mismo gesto: tomar algo que en otros lenguajes es una acción —pedir a la red, leer el reloj, escuchar el teclado— y convertirlo en un valor. Un Cmd no ejecuta una petición, la describe; una Sub no engancha un oyente, lo declara; y el runtime, un actor ajeno a tu código, es el único que ejecuta de verdad. Conviene ahora subir un peldaño y ver esa idea desnuda, separada de la sintaxis de Elm, porque es mucho más grande que Elm. La idea es esta: un efecto puede representarse como un dato inmutable, y quien lo ejecuta no eres tú sino un intérprete que recibe esa descripción. Formulada así, no pertenece a ningún lenguaje. Es tan portátil que ha saltado la valla de Elm y ha reaparecido, con otros nombres y en otras comunidades, en arquitecturas escritas por gente que quizá nunca compiló una línea de Elm. Esta última lección del nivel trata de esa migración: de por qué la idea es tan robusta que se reinventa sola, y de qué revela sobre la computación el hecho de que describir sea casi siempre mejor que hacer.

Una idea que salta la valla del lenguaje

Reduzcamos el nivel entero a una sola frase y quitémosle la ropa de Elm. Tu lógica de estado es una función pura que, ante un evento, decide dos cosas: cómo queda el estado y qué efectos deberían ocurrir. Lo segundo no lo ejecuta; lo devuelve, empaquetado en un valor. Ese valor es una receta inerte —se puede guardar, pasar, comparar, combinar, descartar— y hay un único lugar, el runtime, que la lee y la lleva a cabo. El resultado del efecto no regresa por una vía privilegiada: reentra como un evento más, por la misma puerta que todo lo demás.

-- El gesto de Elm, reducido a su esencia: decidir devuelve una descripcion
update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        PulsarCargar ->
            -- no se ejecuta ninguna peticion aqui: se devuelve su descripcion
            ( { model | estado = Cargando }, pedirUsuario )

El Cmd de la derecha es el dato. update lo fabrica y lo entrega; no lo ejecuta. Cambia el nombre Cmd por otro cualquiera y el patrón sigue intacto: una función pura que produce una representación del efecto, y un intérprete que la consume al borde del sistema. Eso es exactamente lo que hicieron otros, en otros lenguajes, sin pedir permiso.

Y conviene notar que el nivel te mostró la idea dos veces, no una. Un Cmd reifica el efecto de salida —lo que tú inicias— y una Sub reifica la escucha de entrada —lo que te llega—; ambos son el mismo movimiento aplicado a las dos direcciones del tiempo. Cuando un diseño repite el mismo gesto en contextos distintos, deja de parecer un truco puntual y empieza a delatar un principio. El principio es que la frontera entre decidir y obrar puede materializarse en un valor que la cruza.

El mismo patrón con otros nombres

En The Composable Architecture, la biblioteca de Point-Free para Swift, el reducer no devuelve solo el estado: devuelve un Effect. Un Effect es un tipo de valor que describe trabajo asíncrono —una llamada de red, un temporizador, una tarea— sin ejecutarlo; el Store es quien lo realiza y reinyecta las acciones resultantes por el mismo reducer. La firma es la tupla de Elm con acento Swift: mutas el estado y devuelves una descripción de efectos, y Effect.none es el gemelo exacto de Cmd.none. El dividendo de esa decisión se cobra en las pruebas con un rigor casi contable: el TestStore de TCA obliga a declarar, paso a paso, qué acciones esperas y qué efectos deberían seguir vivos, y falla si al terminar queda un efecto en vuelo que no afirmaste. Solo se puede exigir tanto porque los efectos son valores que el store puede enumerar y contrastar, no acciones ya disueltas en el mundo.

redux-saga lleva la idea a un extremo especialmente didáctico. Una saga es un generador, y cada yield no ejecuta un efecto: produce un objeto plano de JavaScript que lo describe. El efecto call(api.fetchUsuario, id) no llama a la API; devuelve un objeto —un registro con el tipo del efecto, la función y sus argumentos— que el middleware interpretará más tarde.

// redux-saga: yield produce una descripcion, no una ejecucion
function* cargarUsuario(id: string) {
  // call(...) NO invoca la API: devuelve un objeto que describe la llamada
  const usuario = yield call(api.fetchUsuario, id)
  yield put({ type: "USUARIO_OK", usuario })
}

La prueba de una saga es la demostración más limpia de por qué esto importa: recorres el generador con next() y afirmas que el valor emitido es igual a call(api.fetchUsuario, id) —comparas dos objetos, dos descripciones— sin tocar jamás la red. Verificas la intención, no el efecto. Y redux-loop es el préstamo más literal de todos: reintroduce la tupla de Elm en Redux. Un reducer, que en Redux ortodoxo solo puede devolver estado, pasa a poder devolver loop(estado, cmd), donde cmd es un valor construido con Cmd.run que describe un efecto. Un enhancer del store lo desempaqueta, lo ejecuta y despacha de vuelta las acciones que produzca. Es, casi carácter por carácter, ( Model, Cmd Msg ) trasplantado a JavaScript.

// redux-loop: el reducer devuelve estado y una descripcion de efecto
function usuarios(state = inicial, action) {
  switch (action.type) {
    case "CARGAR":
      // loop(...) no ejecuta nada: empaqueta estado mas Cmd como un valor
      return loop(
        { ...state, estado: "cargando" },
        Cmd.run(api.fetchUsuario, {
          successActionCreator: usuarioOk,
          failActionCreator: usuarioError,
          args: [action.id],
        })
      )
    default:
      return state
  }
}

El reducer sigue siendo puro —devuelve un valor y nada más— y el Cmd.run es la receta que el enhancer del store ejecutará por su cuenta, despachando usuarioOk o usuarioError según lo que devuelva la red. Cámbiale los nombres y esa rama CARGAR es, línea por línea, la rama PulsarCargar de Elm con la que abrimos la lección.

flowchart TD
Elm[Elm Cmd Msg] --> Idea[Efecto como dato]
TCA[TCA Effect] --> Idea
Saga[redux-saga objeto yield] --> Idea
Loop[redux-loop loop y Cmd] --> Idea
Idea --> RT[Un interprete lo ejecuta y devuelve un mensaje]
style Idea fill:#f9e2af,color:#11111b
style RT fill:#cba6f7,color:#11111b

Los cuatro difieren en el sabor —tipos estáticos en Elm y Swift, objetos dinámicos en JavaScript, un generador que se lee como código secuencial en saga— pero comparten la espina dorsal: en ninguno de ellos la función que decide es la función que ejecuta. Esa coincidencia entre comunidades que apenas se hablan entre sí es la mejor evidencia de que la idea no era un capricho local de Elm, sino algo que estaba esperando a ser descubierto varias veces.

Por qué la idea es tan robusta

El dibujo es el mismo trácese en Elm, en Swift o en JavaScript: una lógica pura decide y devuelve un valor, un intérprete lo ejecuta contra el mundo, y el resultado vuelve como un mensaje que reentra por la lógica. De esa forma cuelgan tres propiedades que ninguna arquitectura basada en ejecución en línea puede ofrecer a la vez.

flowchart LR
Logica[Logica pura] -->|devuelve| Efecto[Efecto como valor]
Efecto --> RT[Runtime interprete]
RT -->|ejecuta| Mundo[Mundo exterior]
Mundo -->|resultado como mensaje| Logica
style Logica fill:#a6e3a1,color:#11111b
style Efecto fill:#f9e2af,color:#11111b
style RT fill:#cba6f7,color:#11111b

La primera es la pureza. La lógica no realiza el efecto, lo devuelve; por tanto sigue siendo una función de entradas a salidas, sin dependencias ocultas del mundo. Toda la impureza que el programa necesita —y alguna necesita, o no serviría para nada— queda acorralada en el intérprete, un único lugar pequeño y ajeno a tu lógica, en vez de repartida por cada rama que toca la red.

La segunda es la testabilidad sin simulacros. Como el efecto es un valor, la prueba compara valores: se afirma que la lógica devolvió la descripción esperada, sin simular la red ni el reloj, porque no se ejecuta nada. Se inspecciona la receta, no el plato. La prueba de la saga —recorrer el generador y comparar el objeto emitido— y la del update de Elm —aplicar un mensaje y comparar el Cmd devuelto— son, en el fondo, la misma prueba escrita en dos idiomas distintos.

La tercera es el determinismo y el rebobinado. La misma entrada produce siempre la misma descripción de efecto, y como la secuencia de decisiones es una secuencia de datos, se puede grabar, reproducir y recorrer hacia atrás. El depurador con viaje en el tiempo de Elm y las herramientas de Redux no son florituras: existen porque el historial es data —una lista de valores que se puede volver a aplicar desde el principio— y no una estela de acciones ya consumidas e irrepetibles.

El criterio que te llevas, y su precio

Sería una mala lección universal la que solo cantara las ventajas. Reificar el efecto tiene un coste, y nombrarlo es lo que convierte la idea en criterio y no en dogma. El precio es la indirección: aparece una pieza nueva —el runtime, el middleware, el enhancer, el Store— que hay que construir o adoptar, y un salto mental extra entre el punto donde se decide el efecto y el punto donde de verdad ocurre. En un guion de veinte líneas que hace un fetch y termina, esa indirección es pura ceremonia y no se paga sola; ahí ejecutar el efecto en línea es lo correcto y punto.

El criterio, por tanto, es proporcional. El valor de describir en vez de hacer crece exactamente con cuánto necesites razonar, probar, reproducir o deshacer lo que el programa hace con el mundo. Una aplicación con lógica de estado rica, muchos efectos entrelazados y una exigencia real de pruebas fiables es el terreno donde la reificación se devuelve con creces; un script efímero, no. Por eso la idea madura no dice reifica siempre, sino algo más fino: aprende a reconocer cuándo el efecto en mitad de tu lógica te está costando pureza, y ten a mano la maniobra de convertirlo en un valor que otro ejecute al borde.

Nótese, además, que la simetría se cierra por el otro lado. No solo la salida se vuelve dato: la entrada también. El resultado del efecto no regresa por un callback privilegiado ni por una promesa colgada de la nada, sino como un mensaje —otro valor— que reentra por la misma puerta que cualquier evento. Describes el efecto como dato al salir y recibes su resultado como dato al volver, y entre esos dos datos vive un intérprete que es el único que conoce el mundo. Esa clausura —valores que salen, valores que entran, impureza confinada en medio— es lo que hace que el bucle entero sea inspeccionable de principio a fin.