El efecto como valor devuelto: describir el trabajo en vez de hacerlo

Hay una sola línea en TCA que contiene toda su filosofía, y es la firma del reducer: recibe el estado como inout, recibe una acción y devuelve un Effect<Action>. No devuelve Void, no devuelve una promesa a la que engancharse, no devuelve el resultado de la red: devuelve una descripción del trabajo pendiente. Esa elección de tipo es la que separa a TCA de casi todo lo que has escrito antes, porque convierte lo que en otras arquitecturas es una llamada —lanza la petición, arranca el temporizador, escribe en disco— en un valor que existe, que se puede guardar, combinar, cancelar y sustituir entero, y que todavía no ha hecho absolutamente nada. El reducer no actúa sobre el mundo: redacta un encargo y lo firma.

La firma es la tesis

Quítale las macros al reducer y queda el contrato desnudo, que cabe en una línea. Esa línea dice tres cosas: que el estado se muta en el sitio a través de un parámetro inout, que la acción es la única entrada de información del exterior, y que la salida no es un resultado sino un Effect parametrizado por el mismo tipo de acción que entró.

func reduce(into state: inout State, action: Action) -> Effect<Action>

Que el Effect esté parametrizado por Action y no por un tipo de resultado cualquiera es la pieza que cierra el círculo: lo único que un efecto puede devolverle al sistema son acciones, es decir, hechos ya nombrados en el dominio. No hay canal lateral, no hay retorno directo, no hay callback que escriba en el estado a escondidas. Si algo del mundo exterior quiere influir en tu aplicación, tiene que hacerlo pronunciando una de las palabras que tú declaraste en el enum Action.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {
    var nombre = ""
    var cargando = false
  }
  enum Action {
    case aparecer
    case perfilRecibido(Usuario)
  }
  @Dependency(\.api) var api

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .aparecer:
        state.cargando = true
        return .run { send in
          await send(.perfilRecibido(try await api.perfil()))
        }
      case let .perfilRecibido(usuario):
        state.cargando = false
        state.nombre = usuario.nombre
        return .none
      }
    }
  }
}

Observa la coreografía del primer caso. La mutación —state.cargando = true— es síncrona y ocurre ya. La red no ocurre: se describe. En la línea del return no viaja ni un byte; se construye un valor que envuelve una closure que algún día alguien ejecutará. Cuando el reducer termina, el trabajo asíncrono sigue sin haber empezado, y el estado ya refleja que está a punto de empezar. Esa distancia de tiempo entre declarar que voy a hacerlo y hacerlo es exactamente el espacio donde vive la testabilidad de TCA.

Describir no es ejecutar

El Effect que devuelves es un valor inerte. Por dentro no es más que una envoltura sobre una operación que puede ser vacía, una closure asíncrona o un publicador de Combine; por fuera es algo que puedes pasar por parámetro, guardar en una variable, combinar con otros y devolver desde una función. Quien lo despierta es el Store: recibe la acción, corre el reducer, se queda con el efecto devuelto, lo envuelve en una Task que él administra y canaliza de vuelta hacia el propio reducer cada acción que ese efecto emita.

flowchart LR
A[Action] --> R[reducer puro muta el State]
R -->|devuelve un Effect inerte| S[Store el unico runtime]
S -->|arranca una Task fuera del reducer| M[Mundo red disco reloj]
M -->|nuevas acciones| A
style R fill:#cba6f7,color:#11111b
style S fill:#89b4fa,color:#11111b

De esa asimetría se derivan consecuencias muy concretas. El store sabe cuántos efectos hay vivos, porque los arrancó él; puede cancelarlos por identidad, porque guarda la Task; puede esperarlos en un test, porque conoce su ciclo de vida; y puede, si el estado de una feature hija se anula, matar de golpe todo lo que esa hija había lanzado. Nada de eso sería posible si el reducer hubiera ejecutado el trabajo por su cuenta, porque entonces el trabajo no sería de nadie.

Que el efecto sea un valor no es una metáfora: se comporta como tal en todos los sentidos que importan. Puedes construirlo en un método aparte y devolverlo, guardarlo en una propiedad, meterlo en un array o elegir entre dos con un condicional, y nada de eso ejecuta absolutamente nada.

private func cargarPerfil() -> Effect<Action> {
  .run { send in
    await send(.perfilRecibido(try await api.perfil()))
  }
}

private var pulsoDeReloj: Effect<Action> {
  .run { send in
    for await _ in clock.timer(interval: .seconds(60)) {
      await send(.minutoCumplido)
    }
  }
}

Al leer esas dos definiciones no ocurre ninguna petición y no arranca ningún reloj; solo se han fabricado dos descripciones que esperan a que alguien las devuelva desde un reducer. Esta es también la razón de que la reutilización en TCA se haga extrayendo métodos que devuelven efectos y no reenviando acciones: un método es composición de descripciones, y reenviar una acción es dar una vuelta entera por el runtime.

Lo que compra la pureza

La disciplina de devolver en vez de hacer no es un ejercicio de estética funcional: es una compra, y conviene saber qué te llevas por ese precio.

Hay además una ganancia menos evidente y quizá más profunda: la reproducibilidad. Si toda influencia del exterior entra por el enum Action, entonces la secuencia de acciones que un usuario provocó es un registro completo de su sesión. Reproducir un fallo deja de ser adivinar qué pasó y pasa a ser volver a alimentar el reducer con la misma lista de acciones desde el mismo estado inicial. Eso solo funciona mientras nadie mute el estado por un camino que no sea una acción.

Esa propiedad tiene una manifestación cotidiana que conviene usar desde el primer día. El operador de depuración imprime cada acción recibida junto al diferencial exacto del estado que provocó, y leerlo es leer la historia de tu aplicación contada por ella misma.

var body: some ReducerOf<Self> {
  Reduce { state, action in
    // ...
  }
  ._printChanges()
}

Si esa traza contiene todo lo que pasó, es porque nada pasó fuera de ella. En una arquitectura donde el trabajo se hace dentro de la vista o del modelo de vista, la traza equivalente estaría llena de agujeros: cambios de estado sin acción que los explique, provocados por una closure que se resolvió en algún hilo. Aquí no hay agujeros por construcción, y esa ausencia de agujeros es lo que hace del registro una herramienta de diagnóstico y no una curiosidad.