Efectos y ciclo de vida: qué muere cuando el estado se vuelve nil

Un temporizador no sabe que su pantalla se cerró. Una petición de red tampoco, ni un bucle sobre un stream de notificaciones. En cualquier arquitectura donde la duración de un trabajo asíncrono y la duración del estado que le dio sentido sean dos hechos independientes, la fuga es cuestión de tiempo y de olvido. Los operadores de este nivel toman una decisión distinta y silenciosa: al dar vida a un hijo también asumen la responsabilidad de matarlo, y esa responsabilidad incluye todo lo que el hijo tuviera en marcha. Anular el estado no es limpiar un campo; es terminar una vida, con su temporizador detenido, su petición abortada y su suscripción liberada. Conviene entender exactamente cómo ocurre eso, porque es la garantía sobre la que descansa buena parte de la corrección de una app en TCA, y porque tiene fronteras precisas que hay que saber reconocer.

El ámbito de cancelación implícito

Cuando ifLet corre el reducer hijo y este devuelve un efecto, el operador no lo entrega tal cual al store: lo envuelve en un ámbito de cancelación cuya identidad deriva del propio punto de composición y del dominio del hijo. Es, conceptualmente, un cancellable(id:) que no escribiste. Mientras el estado hijo exista, ese ámbito sigue abierto y los efectos corren con normalidad. En el instante en que el estado pasa a nil, el operador cancela el ámbito entero, y con él todo lo que hubiera dentro.

@Reducer
struct Edicion {
  @ObservableState
  struct State: Equatable { var texto = ""; var latidos = 0 }
  enum Action { case alAparecer, latido, textoCambio(String) }

  @Dependency(\.continuousClock) var clock

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .alAparecer:
        return .run { send in
          for await _ in self.clock.timer(interval: .seconds(1)) {
            await send(.latido)
          }
        }
      case .latido:
        state.latidos += 1
        return .none
      case let .textoCambio(t):
        state.texto = t
        return .none
      }
    }
  }
}

El padre que monta esta feature con .ifLet(\.$edicion, action: \.edicion) no escribe ni una línea de limpieza. Asigna nil al cerrar y el bucle for await termina, la tarea se cancela y la memoria que retenía se libera. Lo mismo vale para ifCaseLet: salir de un caso equivale a anular ese dominio, así que los efectos del hijo que vivía en él mueren igual. Y lo mismo vale para forEach con la identidad del elemento, como viste en el Nivel 15. Los tres operadores comparten mecanismo porque comparten tesis: la vida del efecto es la vida del estado.

El instante exacto: primero el hijo, después el padre, después la muerte

El orden importa y merece precisión, porque hay una secuencia concreta dentro de un mismo paso del store. Cuando entra una acción, el operador comprueba si el estado hijo existe y, si existe, corre el reducer hijo, que puede devolver efectos nuevos. Solo después corre el reducer del padre, que es quien típicamente decide anular el estado. Y solo cuando el padre termina, el operador vuelve a mirar: si antes había estado y ahora no lo hay, cancela el ámbito.

flowchart TD
A[llega una accion] --> B{el estado hijo existe}
B -->|no| Z[no se muta nada y se avisa]
B -->|si| C[corre el reducer hijo y puede lanzar efectos]
C --> D[corre el reducer del padre]
D --> E{el estado hijo sigue existiendo}
E -->|si| F[los efectos del hijo siguen vivos]
E -->|no| G[se cancela el ambito entero del hijo]
style G fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

Esa secuencia explica un comportamiento que sorprende la primera vez: un hijo puede lanzar un efecto y ver ese efecto cancelado en el mismo paso, si el padre decide cerrarlo al procesar la misma acción. No es un fallo, es la consecuencia deseada del orden. También explica por qué el orden inverso sería inservible: si el padre corriera primero y anulara el estado, el hijo nunca recibiría el mensaje que motivó su propio cierre y no tendría ocasión de reaccionar a él.

Hay un corolario práctico que conviene fijar. El efecto muere porque el dominio desapareció, no porque la pantalla dejara de verse. Son dos hechos que en el mundo imperativo se confunden constantemente, porque el gancho disponible era siempre visual —un viewWillDisappear, un onDisappear— y por tanto la limpieza quedaba atada a una circunstancia poco fiable: una vista puede desaparecer sin que el estado muera, como al empujar otra pantalla encima, y puede morir sin haberse llegado a mostrar. En TCA el criterio es puramente estructural y no consulta a la interfaz para nada. Si el valor está, el hijo vive; si no está, el hijo murió. Eso hace que la regla se pueda razonar leyendo el reducer, sin abrir la vista y sin saber cómo se presenta.

Para la primera de esas cuatro fugas, la del efecto que el padre lanza en nombre del hijo, el remedio es corto y merece verse escrito, porque es el que más aparece en revisiones de código.

private enum CancelID { case sincronizacion }

case .editarTocado:
  state.edicion = Edicion.State(texto: state.titulo)
  return .run { send in
    for await evento in self.sincronizador.eventos() {
      await send(.edicion(.presented(.eventoRemoto(evento))))
    }
  }
  .cancellable(id: CancelID.sincronizacion)

case .edicion(.dismiss):
  return .cancel(id: CancelID.sincronizacion)

Ese efecto alimenta al hijo pero pertenece al padre, así que el ámbito implícito no lo alcanza y hace falta el identificador explícito del Nivel 11. La pregunta que resuelve el caso siempre es la misma: ¿quién devolvió este efecto? Si lo devolvió el reducer hijo, morirá con su dominio; si lo devolvió el padre, vive tanto como el padre y es tuyo cancelarlo.

El TestStore como detector de supervivientes

La garantía no se comprueba leyendo el código sino ejecutando la suite, y aquí el rigor del TestStore exhaustivo del Nivel 3 se vuelve un aliado inesperado: falla si al terminar el test queda algún efecto en vuelo. Un efecto que sobrevive a su dominio no es un detalle que se le escape a la prueba; es motivo de fallo.

@Test
func elLatidoMuereConLaEdicion() async {
  let reloj = TestClock()
  let store = TestStore(initialState: Padre.State()) {
    Padre()
  } withDependencies: {
    $0.continuousClock = reloj
  }

  await store.send(.editarTocado) {
    $0.edicion = Edicion.State()
  }
  await store.send(.edicion(.presented(.alAparecer)))
  await reloj.advance(by: .seconds(1))
  await store.receive(\.edicion.presented.latido) {
    $0.edicion?.latidos = 1
  }
  await store.send(.edicion(.dismiss)) {
    $0.edicion = nil
  }
}

Ese test pasa únicamente porque ifLet canceló el temporizador al anular el estado. Quita la cancelación —o mueve el efecto al ámbito del padre— y la prueba fallará al terminar por tarea pendiente, sin que tengas que escribir aserción alguna sobre fugas. Es la propiedad más valiosa del testing exhaustivo: convierte una clase entera de defectos invisibles en errores de compilación de la suite.