Acciones anidadas: el árbol de enums y su enrutamiento

El State de una aplicación en TCA es un tipo producto anidado: una struct que contiene otras struct. La Action es su imagen especular, un tipo suma anidado: un enum cuyos casos envuelven otros enum. Esa dualidad no es una coincidencia estética sino la condición que hace posible la composición, porque un reducer hijo solo puede correr dentro de un padre si existe una forma canónica de bajar hasta su rebanada de estado y de subir hasta su rebanada de acciones. En el estado se baja con un key path; en las acciones se baja con un case path. Esta lección recorre el árbol completo: cómo se construye, cómo se enruta hacia abajo, en qué orden se procesa y dónde puede el padre intervenir.

El árbol: un caso por hijo

Componer dominios significa incrustar: el estado del hijo se convierte en un campo del padre y las acciones del hijo se convierten en un caso del padre. La macro @Reducer marca el enum como @CasePathable, y eso da a cada caso un case path simétrico al key path de un campo.

@Reducer
struct AppFeature {
  @ObservableState
  struct State: Equatable {
    var lista = Lista.State()
    @Presents var editor: Editor.State?
  }
  enum Action {
    case lista(Lista.Action)
    case editor(PresentationAction<Editor.Action>)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.lista, action: \.lista) { Lista() }
    Reduce { state, action in .none }
      .ifLet(\.$editor, action: \.editor) { Editor() }
  }
}

Una acción concreta se escribe entonces como una ruta completa desde la raíz hasta la hoja. Enviar .lista(.fila(.init(id: id, action: .view(.favoritoPulsado)))) no es verbosidad gratuita: es la dirección postal exacta del suceso dentro de la topología de features, y contiene toda la información necesaria para que el runtime sepa a qué reducer entregarlo y sobre qué porción de estado hacerlo correr.

No todos los eslabones del camino tienen la misma forma, y conviene reconocer los tres envoltorios que TCA añade según la cardinalidad del hijo. Un hijo único se incrusta desnudo; uno opcional o presentado viaja dentro de PresentationAction, que suma a las acciones del hijo el caso dismiss; una colección viaja dentro de IdentifiedActionOf, que empareja cada acción con el identificador del elemento; y una pila de navegación usa StackAction, que añade el índice del elemento y los avisos de apilado y desapilado.

enum Action {
  case cabecera(Cabecera.Action)                 // uno, siempre
  case editor(PresentationAction<Editor.Action>) // cero o uno
  case filas(IdentifiedActionOf<Fila>)           // cero o muchos
  case ruta(StackAction<Ruta.State, Ruta.Action>)// pila
}

Cada envoltorio aporta exactamente la información que el operador correspondiente necesita para localizar la rebanada de estado sobre la que correr el hijo. Esa correspondencia entre forma del caso y operador es total: el tipo del caso ya dice qué operador lo enruta.

flowchart TD
A[AppFeature Action] --> L[caso lista]
A --> E[caso editor]
L --> LF[caso fila con id]
LF --> FV[Fila Action view]
LF --> FD[Fila Action delegate]
E --> EP[PresentationAction presented]
EP --> EV[Editor Action view]

Case paths: el dual del key path

Un key path \State.lista es una pareja de operaciones sobre un producto: extraer el campo y escribirlo. Un case path \Action.Cases.lista es la pareja dual sobre una suma: intentar extraer el valor si el enum está en ese caso, y envolver un valor para construirlo. La asimetría es exactamente la que separa producto de suma: en el producto la extracción siempre tiene éxito, en la suma puede fallar, y por eso devuelve un opcional.

Esa dualidad es lo que permite que Scope, ifLet y forEach tengan la misma firma conceptual: reciben un camino hacia el estado y un camino hacia la acción, y con ambos construyen la lente completa que embebe el dominio del hijo en el del padre. Cuando llega una acción, el operador aplica el case path; si la extracción devuelve nil, la acción no era para ese hijo y el operador la deja pasar sin hacer nada. El enrutamiento es, literalmente, pattern matching sobre el prefijo de la ruta.

Los case paths no viven solo dentro de los operadores: son valores de primera clase que puedes usar en switch, en filtros y en los tests. El TestStore los aprovecha para afirmar sobre la forma de una acción sin escribir su carga completa, lo que resulta indispensable cuando el valor asociado no es Equatable o cuando solo interesa la rama.

await store.receive(\.lista.filas[id: fila].delegate.favoritoMarcado)

Esa expresión es una ruta compuesta por pasos de caso encadenados, y el compilador la verifica entera: si mañana renombras un caso intermedio, el test deja de compilar en lugar de fallar en ejecución con un mensaje opaco.

El orden: quién ve la acción primero

Que dos reducers vean la misma acción exige saber cuál actúa antes, porque el segundo observa el estado ya mutado por el primero. TCA fija el orden con dos reglas distintas según la forma sintáctica.

Los elementos listados en body corren en el orden en que aparecen, de arriba abajo. Por eso el idioma habitual coloca los Scope primero y el Reduce de coordinación al final: cada hijo procesa lo suyo y el padre observa después el resultado consolidado.

Los operadores ifLet y forEach, en cambio, corren siempre el hijo antes que el padre, con independencia de dónde se escriba el modificador. La razón es de corrección, no de gusto: el padre debe poder anular el estado del hijo como reacción a una acción del hijo, y si el orden fuera el inverso, el hijo recibiría una acción sobre un estado que el padre acaba de destruir. Al correr primero, el hijo termina su trabajo y solo entonces el padre puede desmontarlo y disparar la cancelación automática de sus efectos en vuelo.

var body: some ReducerOf<Self> {
  Scope(state: \.cabecera, action: \.cabecera) { Cabecera() }  // 1
  Reduce { state, action in                                    // 2 respecto a Scope
    // ...
    return .none
  }
  .ifLet(\.$editor, action: \.editor) { Editor() }             // corre antes que el Reduce
}

Interceptar sin acoplar

El padre no se limita a enrutar: puede reaccionar a cualquier acción del hijo con solo escribir el patrón anidado completo en su switch. Esta capacidad es potente y por eso conviene disciplinarla.

Reduce { state, action in
  switch action {
  case let .editor(.presented(.delegate(.documentoGuardado(id)))):
    state.recientes.insert(id, at: 0)
    state.editor = nil
    return .none
  default:
    return .none
  }
}

La regla práctica es interceptar solo el subenum delegate, que existe precisamente para eso. Un padre que reacciona a .editor(.presented(.view(.guardarPulsado))) está espiando gestos que no le conciernen y se acopla a la interfaz interna del hijo: el día que el hijo renombre su botón, el padre deja de compilar sin que nada haya cambiado en el dominio compartido.