Estado opcional: una feature hija que existe o no existe

Un contador siempre existe; una lista contiene cero o muchos elementos. Entre esos dos extremos vive la cardinalidad que gobierna casi toda la navegación de una app real: cero o uno. La hoja de edición existe mientras el usuario la tiene abierta y no existe el resto del tiempo. El detalle del artículo existe mientras se está mirando. La alerta existe durante los tres segundos que tarda alguien en pulsar aceptar. Modelar esto con un booleano y un estado que permanece a la espera es la costumbre heredada, y es también el origen de una familia entera de fallos: datos rancios de la vez anterior, efectos que siguen corriendo tras cerrar la pantalla, banderas que se desincronizan. TCA lo modela como lo que es —un valor opcional— y le da un operador propio, ifLet, que no se limita a enrutar acciones: define un ciclo de vida completo con nacimiento, vida y muerte.

La cardinalidad cero-o-uno

En el Nivel 14 compusiste con Scope un hijo que está siempre presente, y en el Nivel 15 multiplicaste un reducer sobre una colección con forEach. Queda el caso intermedio, y la declaración es tan sencilla que engaña: un campo opcional.

@Reducer
struct Padre {
  @ObservableState
  struct State: Equatable {
    var titulo = ""
    var edicion: Edicion.State?
  }
  enum Action {
    case editarTocado
    case guardarTocado
    case edicion(Edicion.Action)
  }
}

Lo importante no es la interrogación, es lo que significa. Cuando edicion vale nil no hay un estado de edición vacío esperando turno: no hay estado de edición en absoluto. El dominio entero de esa feature hija —sus campos, sus invariantes, sus acciones posibles— deja de existir. Compáralo con el patrón habitual de una bandera mostrandoEdicion junto a un Edicion.State siempre residente: ahí el dominio del hijo persiste, con sus datos de la sesión anterior, y hay que acordarse de limpiarlo. Con el opcional, la limpieza es la desaparición misma; no se puede olvidar porque no es un paso.

Esto tiene una consecuencia sutil sobre las invariantes. El State del hijo puede exigir, por ejemplo, que su texto no esté vacío o que tenga un identificador válido, y esa exigencia solo debe cumplirse mientras el hijo vive. Al escribir nil no violas ninguna invariante del hijo: la retiras del universo de discurso. Modelar así es lo que permite que el tipo del hijo sea estricto sin que el padre tenga que fabricar valores de relleno para los ratos en que la pantalla no está abierta.

ifLet: nacer, vivir, morir

El operador se aplica como modificador sobre el reducer padre y toma el key path al opcional, el key path de caso a la acción del hijo y el reducer hijo.

var body: some ReducerOf<Self> {
  Reduce { state, action in
    switch action {
    case .editarTocado:
      state.edicion = Edicion.State(texto: state.titulo)
      return .none
    case .guardarTocado:
      state.titulo = state.edicion?.texto ?? state.titulo
      state.edicion = nil
      return .none
    case .edicion:
      return .none
    }
  }
  .ifLet(\.edicion, action: \.edicion) {
    Edicion()
  }
}

El nacimiento es una asignación y nada más. No hay una llamada de presentación, ni un coordinador que se entere, ni una vista a la que avisar: se escribe un valor donde había nil y con eso la feature hija empieza a existir. La vida es el enrutado: mientras el estado sea no nulo, toda acción .edicion alcanza al reducer del hijo, que corre antes que el Reduce del padre. Ese orden es la misma decisión que viste en forEach y por el mismo motivo: si el padre corriera primero podría anular el estado al procesar la acción, y el hijo jamás llegaría a reaccionar a su propio mensaje. La muerte es otra asignación, nil, y es el momento cargado de consecuencias que estudiarás a fondo en la cuarta lección de este nivel: todos los efectos que el hijo tuviera en vuelo se cancelan solos.

El opcional presentado: cuando la vista también puede matar

Hay una variante del opcional en la que la desaparición no siempre la decide el reducer. Cuando el hijo se muestra como hoja, alerta o pantalla empujada, el usuario puede descartarlo con un gesto, y esa noticia llega desde el sistema de vistas hacia dentro. Para ese caso TCA marca el opcional con @Presents y envuelve la acción en PresentationAction.

@ObservableState
struct State: Equatable {
  @Presents var edicion: Edicion.State?
}
enum Action {
  case editarTocado
  case edicion(PresentationAction<Edicion.Action>)
}

var body: some ReducerOf<Self> {
  Reduce { state, action in
    switch action {
    case .editarTocado:
      state.edicion = Edicion.State(texto: state.titulo)
      return .none
    case .edicion:
      return .none
    }
  }
  .ifLet(\.$edicion, action: \.edicion) {
    Edicion()
  }
}

PresentationAction unifica dos mensajes en un solo tipo: .presented(accionDelHijo) para todo lo que ocurre dentro del hijo, y .dismiss para la retirada. El padre puede escuchar ambos, y el propio hijo puede pedir su retirada sin conocer al padre usando la dependencia @Dependency(\.dismiss). La diferencia con el ifLet sin @Presents no es cosmética: la versión presentada garantiza que el estado y lo que hay en pantalla no puedan desincronizarse, porque el enlace es bidireccional y el descarte por gesto se traduce en una anulación del estado igual que si la hubieras escrito tú.

flowchart LR
N[Estado nil sin dominio hijo] -->|el padre asigna un valor| V[Estado no nil hijo vivo]
V -->|acciones enrutadas al reducer hijo| V
V -->|el padre asigna nil o llega dismiss| M[Muerte del hijo]
M -->|cancelacion automatica de efectos| N
style V fill:#a6e3a1,color:#11111b
style M fill:#f38ba8,color:#11111b

En el test, el ciclo de vida se afirma con la misma naturalidad con la que se escribe, y esa simetría es lo que convierte la navegación en algo comprobable.

await store.send(.editarTocado) {
  $0.edicion = Edicion.State(texto: "borrador")
}
await store.send(.edicion(.presented(.textoCambio("final")))) {
  $0.edicion?.texto = "final"
}
await store.send(.edicion(.dismiss)) {
  $0.edicion = nil
}