El modelo mental completo: cinco piezas, una composición y una frontera

Has recorrido treinta niveles y en cada uno había una pieza ocupando el centro de la pantalla. Esta lección hace la operación inversa: alejar la cámara hasta que las treinta caben en un solo plano y se ve, por fin, que nunca fueron treinta ideas sino una sola aplicada a distintas escalas. El objetivo no es repasar —repasar es releer— sino comprimir: quedarte con la imagen mínima desde la que puedas re-derivar cualquier detalle del framework aunque olvides el nombre exacto del operador. Si al terminar puedes dibujar el ciclo en una servilleta y explicar por qué el testing exhaustivo se sigue de él en lugar de añadirse a él, el track entero ha cumplido su función.

Las cinco piezas, en una sola respiración

State es el valor que contiene todo lo que la feature sabe. Action es el enum que enumera todo lo que le puede ocurrir. El Reducer es la función pura que traduce lo segundo en una mutación de lo primero y en una descripción del trabajo pendiente. Effect es esa descripción: un valor, no una ejecución. Y el Store es el runtime que cierra el ciclo, ejecutando efectos y devolviendo sus resultados en forma de acciones nuevas. La feature completa, con las cinco piezas visibles a la vez, cabe en una pantalla.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {          // 1. todo lo que la feature sabe
    var usuario: Usuario?
    var cargando = false
  }

  enum Action: Equatable {           // 2. todo lo que le puede pasar
    case aparecio
    case respuesta(Result<Usuario, Error>)
  }

  @Dependency(\.api) var api         // la unica puerta al exterior

  var body: some ReducerOf<Self> {   // 3. la funcion pura
    Reduce { state, action in
      switch action {
      case .aparecio:
        state.cargando = true        // mutacion sincrona, aqui y ahora
        return .run { send in        // 4. descripcion de trabajo futuro
          let usuario = try await api.perfil()
          await send(.respuesta(.success(usuario)))
        } catch: { error, send in
          await send(.respuesta(.failure(error)))
        }
      case let .respuesta(resultado):
        state.cargando = false
        state.usuario = try? resultado.get()
        return .none
      }
    }
  }
}

Lo importante de este bloque no es lo que contiene sino lo que no puede contener. No hay ninguna llamada de red suelta, ningún Date(), ningún Task detached, ningún singleton. El reducer no hace: decide y describe. El Store, que es la única pieza que no escribes tú, se encarga de que lo descrito ocurra y de que su resultado vuelva a entrar por la puerta principal, como una acción más, indistinguible de la que produjo un toque del usuario.

flowchart TD
V[Vista] -->|send de una accion| S[Store]
S -->|inout state y action| R[Reducer]
R -->|muta| ST[State]
R -->|devuelve| E[Effect]
E -->|send del resultado| S
R -->|lee| D[Dependencies]
D -->|toca| W[Mundo exterior]
ST -->|observacion granular| V
style R fill:#89b4fa,color:#11111b
style E fill:#fab387,color:#11111b
style D fill:#a6e3a1,color:#11111b

La composición es un álgebra cerrada

La palabra que da nombre a la arquitectura no describe una virtud sino una propiedad algebraica: el conjunto de los reducers es cerrado bajo composición. Combinar dos reducers no produce un coordinador, ni un contenedor, ni una capa nueva con reglas propias; produce otro reducer, con exactamente la misma firma que los dos que lo formaron. Por eso una app de cincuenta pantallas no es cincuenta arquitecturas conviviendo, sino un único valor anidado que se monta y se desmonta por partes.

@Reducer
struct App {
  @ObservableState
  struct State: Equatable {
    var perfil = Perfil.State()                              // hijo fijo
    var tareas: IdentifiedArrayOf<Tarea.State> = []          // hijos por id
    @Presents var hoja: Hoja.State?                          // hijo opcional
    var ruta = StackState<Ruta.State>()                      // hijos en pila
  }

  var body: some ReducerOf<Self> {
    Scope(state: \.perfil, action: \.perfil) { Perfil() }
    Reduce { state, action in .none }   // solo lo que ningun hijo decide solo
    .forEach(\.tareas, action: \.tareas) { Tarea() }
    .ifLet(\.$hoja, action: \.hoja) { Hoja() }
    .forEach(\.ruta, action: \.ruta) { Ruta() }
  }
}

Los cuatro operadores responden a las cuatro relaciones que un padre puede tener con sus hijos —uno siempre presente, muchos identificados, uno que puede no existir, muchos apilados— y los cuatro hacen lo mismo por dentro: extraen el trozo de estado con un key path, extraen el trozo de acción con un case path, ejecutan el reducer hijo y vuelven a envolver los efectos que devuelva. Aprendidos los cuatro, no queda un quinto por aprender: queda combinarlos. Y hay un corolario práctico que ahorra discusiones de diseño: cuando una pieza de tu app se resiste a entrar en el body, casi siempre es porque no era lógica de estado. Un formateador es una función pura y vive en un extension; una animación es presentación y vive en la vista; un cliente de red es mundo exterior y vive en una dependencia. La prueba es mecánica: si no puedes escribirlo como algo que recibe estado y acción y devuelve un efecto, no pertenece al reducer, y forzarlo solo acopla lo que ya estaba separado.

La frontera: efectos y dependencias

El mundo entra por una sola puerta y esa puerta tiene dos hojas. Effect responde a cuándo ocurre algo que no es instantáneo: lo aparta del reducer y lo convierte en un valor que el Store ejecutará. @Dependency responde a qué concreto se ejecuta: lo aparta del código y lo convierte en un valor que el contexto decide. Sin la primera, el reducer dejaría de ser síncrono; sin la segunda, dejaría de ser determinista. Se necesitan las dos.

@DependencyClient
struct APIClient {
  var perfil: () async throws -> Usuario
}

extension APIClient: DependencyKey {
  static let liveValue = APIClient(perfil: { try await Red.pedirPerfil() })
  static let previewValue = APIClient(perfil: { .ejemplo })
  // testValue lo genera la macro: cada endpoint falla si el test no lo sobrescribe
}

Que el valor por defecto en tests sea una implementación que falla no es una comodidad: es la que convierte cada test en una declaración explícita de qué partes del mundo participan. Si el test pasa, sabes que lo hizo con exactamente las dependencias que nombraste, porque cualquier otra habría detonado. Y como el reducer es puro y las dependencias son valores, el TestStore puede afirmar el estado carácter a carácter y quedarse esperando cada efecto pendiente.

let store = TestStore(initialState: Perfil.State()) {
  Perfil()
} withDependencies: {
  $0.api.perfil = { .ejemplo }        // el unico trozo de mundo permitido
}

await store.send(.aparecio) { $0.cargando = true }
await store.receive(\.respuesta.success) {
  $0.cargando = false
  $0.usuario = .ejemplo
}

El invariante del que todo se deduce

Toda la arquitectura se puede comprimir en una frase que se lee como una definición y funciona como una ley: todo lo que la feature sabe está en State, todo lo que le puede pasar está en Action, todo lo que hace está en el reducer, y todo lo que el mundo aporta entra por las dependencias. Nada más. Las cuatro cláusulas son afirmaciones de exhaustividad, y de su exhaustividad se sigue todo lo demás.

Se sigue el testing determinista, porque si el estado está completo y las entradas están enumeradas, reproducir una ejecución es reproducir una secuencia de valores. Se sigue la navegación como dato, porque estar en la pantalla de detalle es algo que la feature sabe y por tanto no puede vivir en ningún otro sitio que no sea el estado. Se sigue el deep linking gratis, porque construir un estado a mano es todo lo que hace falta para arrancar en cualquier punto del árbol. Se sigue la modularidad, porque una feature cuyo mundo entra por dependencias no necesita conocer a nadie para compilar. Y se sigue el viaje en el tiempo, porque una secuencia de valores se puede guardar y volver a recorrer.