La idea de composición: el todo con la forma de las partes

La palabra composición se usa con tanta ligereza en arquitectura de software que ha perdido casi todo su filo. Se dice que dos objetos se componen cuando uno guarda una referencia al otro; se dice que dos capas se componen cuando una llama a la otra. TCA usa la palabra en su sentido matemático, mucho más estrecho y mucho más exigente: dos reducers se componen cuando el resultado de juntarlos es, otra vez, un reducer —del mismo protocolo, con las mismas capacidades, apto para ser juntado de nuevo con un tercero sin que nada en el sistema note la diferencia—. Esta lección establece esa idea antes de que veas el operador que la implementa, porque el operador es fácil y la idea no lo es.

Un reducer dentro de otro reducer

Empecemos por la pieza que se deja componer. Una feature hoja no sabe nada del mundo: declara su propio State, su propio Action y la mutación que los relaciona. Nada en su código menciona un contenedor, un padre o una aplicación.

@Reducer
struct Fila {
  @ObservableState
  struct State: Equatable, Identifiable {
    let id: UUID
    var titulo: String
    var marcada = false
  }
  enum Action {
    case marcaAlternada
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .marcaAlternada:
        state.marcada.toggle()
        return .none
      }
    }
  }
}

Ahora el padre. Para embeber a Fila, Panel debe hacer exactamente dos cosas, y ninguna más: darle sitio a su estado y darle sitio a sus acciones. El estado del hijo pasa a ser un campo del struct del padre; las acciones del hijo pasan a ser un caso del enum del padre, un caso que transporta como valor asociado la acción entera del hijo.

@Reducer
struct Panel {
  @ObservableState
  struct State: Equatable {
    var cabecera = Cabecera.State()
    var fila = Fila.State(id: UUID(), titulo: "Primera")
  }
  enum Action {
    case cabecera(Cabecera.Action)
    case fila(Fila.Action)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.cabecera, action: \.cabecera) { Cabecera() }
    Scope(state: \.fila, action: \.fila) { Fila() }
  }
}

Lee Panel con atención y fíjate en lo que no tiene: no tiene lógica. Su body es pura tubería. Panel es un reducer que no reduce nada por su cuenta; su trabajo íntegro consiste en decir dónde vive el estado de cada hijo y bajo qué caso viajan sus acciones. Esa es la forma canónica de un contenedor, y el hecho de que sea escribible sin una sola sentencia imperativa es la primera evidencia de que la composición aquí es estructural y no algorítmica.

Para apreciar lo que se gana conviene mirar la alternativa que casi todo el mundo escribe primero: un solo reducer gigante que lo hace todo, sin hijos.

// La versión sin composición: funciona, y no se deja partir
@Reducer
struct PanelMonolitico {
  @ObservableState
  struct State: Equatable {
    var tituloCabecera = ""
    var filaTitulo = ""
    var filaMarcada = false
  }
  enum Action {
    case tituloCambiado(String)
    case marcaAlternada
  }
  var body: some ReducerOf<Self> { Reduce { state, action in /* ... */ .none } }
}

Este código no está mal escrito y hace exactamente lo mismo. Lo que no tiene es fronteras: nadie puede decir qué campos pertenecen a la cabecera y cuáles a la fila salvo por el prefijo del nombre, que no es una garantía sino una costumbre. No hay forma de arrancar solo la fila en una preview, ni de probar la cabecera sin instanciar el panel entero, ni de reutilizar ninguna de las dos partes en otra pantalla. La versión compuesta paga por adelantado un poco de ceremonia —dos tipos, dos incrustaciones— y a cambio obtiene tres propiedades que el monolito no puede conceder a ningún precio.

Producto en el estado, suma en la acción

La incrustación no es simétrica, y la asimetría es la parte interesante. El estado del padre es un struct: contiene el estado de Cabecera y el de Fila, los dos a la vez, siempre. La acción del padre es un enum: es una acción de Cabecera o una de Fila, nunca las dos. En vocabulario de teoría de tipos, el estado compone como producto cartesiano y la acción como suma —también llamada coproducto—.

Esa diferencia no es una preferencia sintáctica de Swift: es una lectura fiel del dominio. En cualquier instante, todos los estados de todas las features vivas coexisten —la cabecera tiene un título mientras la fila tiene una marca—, y por eso su combinación es una conjunción. En cualquier instante, en cambio, el sistema está procesando exactamente una acción —el usuario pulsó esto o llegó aquella respuesta de red, jamás ambas simultáneamente—, y por eso su combinación es una disyunción. El tipo del padre no describe una decisión de arquitectura: describe cómo es el mundo.

La autosemejanza del árbol

Aquí llega la consecuencia que da nombre a la lección. Panel conforma Reducer. Fila conforma Reducer. Y si mañana una Pantalla embebe a Panel, esa Pantalla conformará Reducer con exactamente las mismas obligaciones y los mismos poderes. No existe en TCA un tipo distinto para la raíz, ni un protocolo especial para los contenedores, ni una clase base para las hojas. Hay un único protocolo y todo lo habita.

flowchart TD
App[AppFeature es un Reducer] --> P1[Panel es un Reducer]
App --> P2[Ajustes es un Reducer]
P1 --> H1[Cabecera es un Reducer]
P1 --> H2[Fila es un Reducer]
P2 --> H3[Perfil es un Reducer]
H2 --> N1[Etiqueta es un Reducer]
style App fill:#f38ba8,color:#11111b
style H1 fill:#a6e3a1,color:#11111b
style H2 fill:#a6e3a1,color:#11111b
style H3 fill:#a6e3a1,color:#11111b
style N1 fill:#a6e3a1,color:#11111b

Esa uniformidad es la definición técnica de una operación cerrada: componer reducers devuelve un reducer, igual que sumar enteros devuelve un entero. Y como es cerrada, es asociativa en la práctica —da igual si agrupas primero dos hijos en un panel y luego el panel en la app, o si reorganizas el árbol entero— y admite anidamiento sin límite sin introducir un solo concepto nuevo. La complejidad de una app de doscientas pantallas no es cualitativamente distinta de la de una app de dos: solo hay más aplicaciones de la misma operación.

Conviene además reparar en el elemento neutro, porque completa la analogía y no es un adorno teórico. EmptyReducer es un reducer que no muta nada y no devuelve efectos; componerlo con cualquier otro deja a ese otro intacto, exactamente como sumar cero. Aparece de verdad en el código cuando un contenedor solo necesita aplicar operadores de ciclo de vida sin tener lógica propia:

var body: some ReducerOf<Self> {
  EmptyReducer()
    .ifLet(\.$hoja, action: \.hoja) { Hoja() }
}

Con una operación cerrada, asociativa y con neutro, lo que tienes entre manos ya no es un patrón de diseño: es una estructura algebraica, y las estructuras algebraicas se comportan igual a toda escala. Esa es, literalmente, la razón por la que la app entera cabe en el mismo diagrama que una de sus hojas.