La C de Composable: componer reducers

Cuando Point-Free bautizó su arquitectura, puso el acento en la palabra del medio. Reactividad la tienen todas; la disciplina de mutación unidireccional la heredó de Elm y de Redux, que ya conoces del bloque anterior. Lo que distingue a The Composable Architecture es que la unidad misma de esa disciplina —el reducer— es un valor de primera clase que se compone con otros como se enchufan piezas de Lego. Una feature grande no se escribe como un reducer gigante: se ensambla a partir de reducers diminutos que ni siquiera saben que viven dentro de otro. Esta lección diseca el pegamento que hace posible ese ensamblaje —los operadores Scope, ifLet y forEach— y el body que los lista.

El reducer como valor, body como composición

En Redux clásico el reducer es una función desnuda y compones con combineReducers. En TCA el reducer es un protocolo, Reducer, con un State y un Action asociados, y su propiedad body devuelve some ReducerOf<Self>: otro reducer, construido por @ReducerBuilder, un result builder que te deja listar varios reducers para que corran en secuencia sobre el mismo estado y la misma acción. La macro @Reducer genera el andamiaje —conformidad, CasePathable sobre las acciones— y te deja escribir solo lo esencial.

@Reducer
struct Contador {
  @ObservableState
  struct State: Equatable {
    var cuenta = 0
  }
  enum Action {
    case incrementar
    case decrementar
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .incrementar:
        state.cuenta += 1
        return .none
      case .decrementar:
        state.cuenta -= 1
        return .none
      }
    }
  }
}

La sutileza que lo cambia todo: body no es la lógica del reducer, es una composición de reducers. Reduce es la hoja que carga la mutación imperativa —recibe inout State y devuelve un Effect—, pero body puede enumerar varios reducers, y TCA los ejecuta de arriba abajo por cada acción que entra. Esa enumeración es el lugar donde vive la composición: en cuanto tienes más de una hoja en body, estás componiendo.

Scope: incrustar el dominio de un hijo

Cuando una app tiene features, el State del padre incrusta el State del hijo como un campo, y el Action del padre incrusta el Action del hijo como un caso. Scope conecta ambos: toma un key path de escritura hacia el estado del hijo y un key path de caso hacia su acción, y corre el reducer hijo sobre esa rebanada del dominio del padre.

@Reducer
struct AppFeature {
  @ObservableState
  struct State: Equatable {
    var contador = Contador.State()
    var perfil = Perfil.State()
  }
  enum Action {
    case contador(Contador.Action)
    case perfil(Perfil.Action)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.contador, action: \.contador) {
      Contador()
    }
    Scope(state: \.perfil, action: \.perfil) {
      Perfil()
    }
    Reduce { state, action in
      // coordinación entre hijos, si hiciera falta
      return .none
    }
  }
}

El key path de caso \.contador existe porque @Reducer marca el enum de acciones como @CasePathable, lo que da a cada caso un key path simétrico al de los campos. Fíjate en el orden: los Scope corren primero y despachan cada acción a su hijo; el Reduce final corre después y ve el estado completo de la app, que es el sitio idóneo para la coordinación entre features. Y fíjate en lo que Contador no sabe: ignora por completo que vive dentro de AppFeature. Esa ignorancia deliberada —el hijo jamás alcanza hacia arriba— es la propiedad Lego: un reducer que no conoce su contexto se puede enchufar en cualquier otro.

ifLet y forEach: opcional y colección

Scope sirve para un hijo que siempre existe. Dos operadores más cubren el hijo que puede no existir —opcional— y el que existe muchas veces —colección—. Ambos se aplican como modificadores sobre el reducer padre, no como elementos hermanos.

ifLet gobierna estado opcional, típicamente el de una presentación. Con @Presents var hijo: Hijo.State? y un caso hijo(PresentationAction<Hijo.Action>):

var body: some ReducerOf<Self> {
  Reduce { state, action in
    // ...
    return .none
  }
  .ifLet(\.$hijo, action: \.hijo) {
    Hijo()
  }
}

ifLet corre el reducer hijo solo cuando el estado es no nulo y, en el instante en que pasa a nulo, cancela automáticamente los efectos en vuelo de ese hijo. Ese desmontaje automático es una corrección que en Redux tendrías que escribir a mano y olvidarías la mitad de las veces.

forEach gobierna una colección de estados hijos identificados por ID:

@ObservableState
struct State: Equatable {
  var filas: IdentifiedArrayOf<Fila.State> = []
}
enum Action {
  case filas(IdentifiedActionOf<Fila>)
}
var body: some ReducerOf<Self> {
  Reduce { state, action in return .none }
  .forEach(\.filas, action: \.filas) {
    Fila()
  }
}

IdentifiedArrayOf mantiene los elementos direccionables por un ID estable, de modo que una acción enrutada a \.filas viaja acompañada del ID de la fila que le toca; forEach corre el reducer hijo sobre exactamente ese elemento y, como ifLet, cancela los efectos de una fila cuando la fila desaparece.

flowchart TD
App[AppFeature body] --> S1[Scope contador]
App --> S2[Scope perfil]
App --> IL[ifLet hijo opcional]
App --> FE[forEach filas]
App --> R[Reduce coordinacion]
S1 --> C1[Contador reducer]
S2 --> C2[Perfil reducer]
IL --> D[Hijo reducer solo si existe]
FE --> F[Fila reducer por elemento]