`@Presents` y `PresentationAction`: el hueco y su canal

Un opcional en el estado parece decir ya todo lo que hace falta para presentar una pantalla: si hay valor hay pantalla, si no hay valor no la hay. Casi. Lo que un opcional pelado no sabe es que su contenido tiene vida propia —un reducer corriendo, efectos en vuelo, una identidad que SwiftUI necesita para distinguir una presentación nueva de una mutación de la anterior— y que esa vida debe empezar y terminar exactamente en los dos instantes en que el valor cruza la frontera de lo nulo. @Presents es la anotación que convierte el opcional en un hueco de presentación con ese contrato incorporado. PresentationAction es su hermano al otro lado, en el mundo de las acciones: un solo caso en el enum del padre que transporta dos mensajes de naturaleza distinta, todo lo que el hijo diga mientras esté vivo y el hecho escueto de que ha dejado de estarlo.

El hueco: un opcional con ciclo de vida

La forma mínima de una presentación tiene tres piezas que se declaran juntas y no funcionan por separado: un campo opcional anotado, un caso de acción envuelto y un ifLet al final del body.

@Reducer
struct Inventario {
  @ObservableState
  struct State: Equatable {
    var articulos: IdentifiedArrayOf<Articulo> = []
    @Presents var detalle: Detalle.State?
  }

  enum Action {
    case articuloPulsado(Articulo.ID)
    case detalle(PresentationAction<Detalle.Action>)
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .articuloPulsado(id):
        guard let articulo = state.articulos[id: id] else { return .none }
        state.detalle = Detalle.State(articulo: articulo)
        return .none

      case .detalle:
        return .none
      }
    }
    .ifLet(\.$detalle, action: \.detalle) {
      Detalle()
    }
  }
}

Presentar el detalle es una asignación; descartarlo será poner nil. Todo lo demás es consecuencia. La pregunta interesante es qué aporta la anotación, porque el código de arriba compilaría casi igual con un opcional sin anotar y luego fallaría de formas difíciles de diagnosticar. @Presents es un envoltorio de propiedad que guarda, junto al valor, un identificador de presentación: un token que cambia cada vez que el hueco pasa de nulo a no nulo. Ese token es lo que permite a TCA responder tres preguntas que el Optional no puede responder. Primera, si el estado que tengo delante es la misma presentación de hace un segundo o una nueva que sustituyó a la anterior, distinción indispensable para que la vista anime en vez de reemplazar de golpe. Segunda, a qué presentación pertenece cada efecto en vuelo, para poder cancelarlos todos al descartar y solo esos. Y tercera, hacia dónde debe viajar la petición de cierre cuando el hijo dice que ha terminado, asunto que ocupa la cuarta lección de este nivel.

El valor proyectado —lo que se escribe \.$detalle— es lo que expone ese envoltorio completo, y por eso los combinadores lo piden con el dólar mientras que la vista, que solo quiere el valor, usará el key path corriente. Es la misma distinción entre valor y envoltorio que ya conoces de @Binding, aplicada aquí a la navegación.

El canal: dos mensajes en un solo caso

Del lado de las acciones no hay dos casos sino uno, case detalle(PresentationAction<Detalle.Action>), y ese único caso multiplexa dos clases de mensaje muy distintas.

La asimetría es deliberada. Las acciones envueltas en presented son el vocabulario entero de la feature hija viajando hacia arriba, y el padre puede observarlas —aunque, por lo que aprendiste sobre acciones delegate, solo debería mirar la parte publicada—. El caso dismiss, en cambio, no pertenece al hijo: es un mensaje sobre el hijo, emitido por quien sea que constate su desaparición, y su semántica es siempre la misma con independencia de la feature.

case let .detalle(.presented(.delegate(.articuloGuardado(articulo)))):
  state.articulos[id: articulo.id] = articulo
  return .none

case .detalle(.dismiss):
  return .none                      // ifLet ya ha puesto el hueco a nil

case .detalle:
  return .none                      // el interior del hijo no es asunto del padre

En los tests y en cualquier sitio donde uses rutas de caso, PresentationAction se atraviesa sin nombrarlo: \.detalle.delegate.articuloGuardado funciona porque la ruta salta el presented automáticamente. La ceremonia está en el tipo, no en el uso.

Un solo hueco para varios destinos

Cuando una pantalla puede presentar tres cosas distintas, la tentación es declarar tres opcionales anotados. Es exactamente el error que el bloque de modelado de dominio enseñó a detectar: tres opcionales admiten ocho combinaciones y solo cuatro son legales. Un @Reducer enum de destino colapsa esas ocho en cuatro por construcción.

@Reducer
struct Inventario {
  @Reducer
  enum Destino {
    case detalle(Detalle)
    case editar(Editor)
    case ajustes(Ajustes)
  }

  @ObservableState
  struct State: Equatable {
    var articulos: IdentifiedArrayOf<Articulo> = []
    @Presents var destino: Destino.State?
  }

  enum Action {
    case articuloPulsado(Articulo.ID)
    case ajustesPulsado
    case destino(PresentationAction<Destino.Action>)
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .articuloPulsado(id):
        guard let articulo = state.articulos[id: id] else { return .none }
        state.destino = .detalle(Detalle.State(articulo: articulo))
        return .none

      case .ajustesPulsado:
        state.destino = .ajustes(Ajustes.State())
        return .none

      case .destino:
        return .none
      }
    }
    .ifLet(\.$destino, action: \.destino)
  }
}

Repara en el ifLet sin closure final: la macro @Reducer aplicada a un enum sintetiza el estado suma, la acción suma y un reducer que despacha cada caso a su feature, de modo que no hay nada que pasarle. Y repara en la consecuencia semántica de tener un único hueco: cambiar de destino es reasignar el mismo campo, así que abrir los ajustes desde el detalle cierra el detalle sin que nadie escriba una línea de cierre. La exclusión mutua entre pantallas dejó de ser una invariante que mantener a mano y pasó a ser una propiedad del tipo.

flowchart LR
N[destino igual a nil] -->|asignar un caso| P[destino presentado]
P -->|PresentationAction presented| R[reducer hijo dentro de ifLet]
R --> P
P -->|PresentationAction dismiss| N
P -->|el padre asigna nil| N
N -->|ifLet cancela efectos del hijo| N
style P fill:#89b4fa,color:#11111b
style N fill:#a6e3a1,color:#11111b