Effect: el trabajo asíncrono como valor devuelto

Un reducer es puro y síncrono; una llamada a la red no cabe dentro de él. La respuesta de TCA a esa tensión es tan elegante como la de Elm: el reducer no ejecuta el trabajo asíncrono, lo devuelve como un valor. Ese valor es el Effect, una descripción de trabajo pendiente que el reducer entrega al runtime de la arquitectura para que lo ejecute por su cuenta y, cuando termine, realimente el sistema con nuevas acciones. El reducer, así, nunca toca el mundo: solo dice qué habría que hacer. Es el mismo truco que permite que una función pura conviva con la red, el disco y el reloj sin dejar de ser pura, porque la impureza no ocurre dentro de ella, sino después, fuera, en un lugar que la arquitectura controla y sabe reproducir.

El reducer describe, el runtime ejecuta

La distinción entre describir y ejecutar es el corazón de esta lección. Cuando el reducer termina, devuelve un Effect; ese valor no ha hecho nada todavía. Es el Store —el runtime que verás en la lección 5— quien lo recibe, lo ejecuta fuera del reducer y canaliza de vuelta cada acción que el efecto produzca. Devolver .none significa entregar una descripción vacía: la transición terminó y no hay trabajo pendiente. Devolver un .run significa entregar una tarea que el runtime arrancará por ti.

case .actualizarPulsado:
  state.cargando = true
  return .run { send in
    let items = try await cliente.cargarArticulos()
    await send(.datosRecibidos(items))
  }

Fíjate en la coreografía: el reducer muta el estado de forma síncrona —state.cargando = true— y acto seguido devuelve la descripción de lo asíncrono. La llamada a la red no ocurre en la línea del return; ocurre más tarde, cuando el runtime ejecute la closure. El reducer ya habrá acabado, puro e intacto.

.run: la asincronía como valor de primera clase

.run es el constructor central de efectos. Abre un contexto async respaldado por una Task que el store gestiona, y te entrega un send de tipo Send<Action> que es invocable: await send(.loQueSea) empuja una nueva acción al sistema. Dentro de ese contexto puedes esperar cualquier cosa, iterar sobre un stream y emitir varias acciones. El manejo de errores va en el catch final del propio .run, para que un fallo también se traduzca en una acción del dominio en vez de en una excepción perdida.

return .run { send in
  let items = try await cliente.cargarArticulos()
  await send(.datosRecibidos(items))
} catch: { error, send in
  await send(.falloDeCarga(error.localizedDescription))
}

Lo importante es que dentro de .run nunca aparecen dependencias globales: el cliente que se usa aquí llegó inyectado por @Dependency (lección 4), de modo que en un test puedes sustituirlo por una versión que devuelve datos fijos sin tocar la red. El efecto sigue siendo, por tanto, tan controlable como el reducer que lo devolvió. Además, send admite animar el cambio resultante con await send(.datosRecibidos(items), animation: .default).

Como .run puede emitir varias acciones a lo largo de su vida, es también el hogar natural de los streams: un efecto que escucha eventos —notificaciones del sistema, mensajes de un socket, posiciones del GPS— itera con for await y hace send en cada elemento, viviendo tanto como el runtime se lo permita.

case .empezarAEscuchar:
  return .run { send in
    for await evento in centro.eventos() {
      await send(.llegoEvento(evento))
    }
  }
  .cancellable(id: CancelID.escucha)

Ese único constructor —una closure async con un send— cubre así todo el espectro de lo asíncrono: desde una petición puntual que emite una acción y termina, hasta una suscripción perpetua que emite miles. La diferencia no está en el tipo de efecto, sino en si la closure retorna o se queda iterando.

El álgebra de efectos: combinar y cancelar

Los efectos son valores, y como tales se combinan con un pequeño álgebra. .none es el efecto neutro. .merge(a, b) ejecuta varios efectos en paralelo y funde sus acciones. .concatenate(a, b) los ejecuta en orden, cada uno tras terminar el anterior. Y .send(.accion) inyecta una acción de forma síncrona —útil sobre todo para que un padre avise a un hijo, no para lógica cotidiana—. La pieza que convierte todo esto en algo robusto es la cancelación por identidad: un efecto de larga vida —un temporizador, una búsqueda, un stream— se marca con .cancellable(id:) y se detiene desde otra acción con .cancel(id:).

Combinar es tan cotidiano como devolver un efecto suelto. Al aparecer una pantalla puedes arrancar a la vez la carga de datos y un reloj que tictaquea, cada uno con su propia identidad para poder cancelarlos por separado cuando la vista desaparezca.

case .alAparecer:
  return .merge(
    .run { send in
      await send(.datosRecibidos(try await cliente.cargarArticulos()))
    },
    .run { send in
      for await _ in clock.timer(interval: .seconds(1)) {
        await send(.tick)
      }
    }
    .cancellable(id: CancelID.reloj)
  )

case .desaparecer:
  return .cancel(id: CancelID.reloj)

La cancelación no es un lujo opcional: un efecto de larga vida que nadie corta es una fuga de tareas que sobrevive a la pantalla que la abrió. Por eso todo .run que itera un stream se marca con una identidad y se cancela cuando la feature deja de necesitarlo.

enum CancelID { case busqueda }

case let .consultaCambiada(texto):
  state.consulta = texto
  return .run { send in
    try await clock.sleep(for: .milliseconds(300))
    let r = try await cliente.buscar(texto)
    await send(.resultados(r))
  }
  .cancellable(id: CancelID.busqueda, cancelInFlight: true)

Ese cancelInFlight: true es el debounce idiomático de TCA: cada nueva pulsación cancela el efecto anterior con la misma identidad, así que solo la última consulta —tras 300 ms de calma— llega a la red. La identidad de un efecto es una propiedad tan real como su contenido, y gestionarla bien es lo que separa una feature que fuga tareas de una que las controla.

flowchart LR
R[reducer puro] -->|devuelve Effect| RT[runtime del store]
RT -->|ejecuta fuera del reducer| W[mundo exterior red y reloj]
W -->|resultado| RT
RT -->|send de nuevas acciones| R
style R fill:#cba6f7,color:#11111b
style RT fill:#89b4fa,color:#11111b

El eco de los Cmd de Elm

Nada de esto es nuevo: es Elm, traducido a Swift con concurrencia estructurada. En The Elm Architecture (Nivel 25), update devuelve una pareja (Model, Cmd Msg), donde Cmd es una descripción de efectos que el runtime de Elm ejecuta para producir nuevos Msg. El Effect de TCA es exactamente ese Cmd: una descripción inerte que un runtime convierte en trabajo y realimenta como acciones. Los efectos de larga vida —observar notificaciones, un reloj que tictaquea— son el equivalente de las Sub (suscripciones) de Elm. La línea genealógica es limpia: Elm inventó separar la descripción de la ejecución, Redux la reflejó con middleware y thunks, y TCA la lleva a su forma más pura sobre async/await, con cancelación estructurada y dependencias inyectables que Elm resolvía con su runtime cerrado.