Cancelación al desaparecer: efectos que sobreviven a su feature

Un temporizador no sabe que su pantalla ya no existe. Un bucle for await sobre un stream tampoco. Ambos siguen despertándose, emitiendo acciones y manteniendo vivas por retención todas las cosas que capturaron, mucho después de que el usuario haya vuelto atrás y de que el estado que les daba sentido se haya descartado. Es la fuga más común de una arquitectura de efectos, y también la más silenciosa: no hay excepción, no hay bloqueo, solo una batería que baja más rápido, una lista que se duplica al reentrar y un contador que corre al doble de velocidad porque hay dos temporizadores donde debería haber uno. La respuesta de TCA a este problema no es un recordatorio de disciplina —acuérdate de cancelar— sino algo más fuerte: atar la vida del efecto a la vida del estado, para que descartar lo segundo mate lo primero sin que nadie tenga que acordarse de nada.

La vida del efecto y la vida del estado

Empieza por ver la fuga con nitidez. Una pantalla arranca un reloj al aparecer y nadie lo detiene nunca.

case .alAparecer:
  return .run { send in
    for await _ in clock.timer(interval: .seconds(1)) {
      await send(.tic)
    }
  }
  .cancellable(id: CancelID.reloj)

Entras, sales, vuelves a entrar. Ahora hay dos bucles vivos —o uno solo, si pusiste cancelInFlight, pero igualmente eterno— y el contador avanza al ritmo equivocado. Repítelo cinco veces y tendrás cinco. Cada uno retiene la closure, la closure retiene el send, y el send mantiene enganchado el camino hasta el store: la memoria no se libera porque, técnicamente, alguien sigue usándola. El defecto no es que falte una línea, es que la duración del efecto y la duración del estado son, por defecto, dos hechos independientes que nadie ha relacionado.

Vale la pena catalogar los síntomas, porque casi nunca se presentan como una fuga y por eso se diagnostican tarde. El más reconocible es la aceleración: un contador que avanza al doble o al triple, un sondeo que pasa de una llamada por minuto a seis. El segundo es la duplicación: cada mensaje entrante se inserta dos veces en la lista, o una notificación se muestra por partida doble. El tercero es el consumo: la app gasta batería y datos con la pantalla apagada porque un stream sigue despierto. Y el cuarto, el más desconcertante, es el estado zombi: una acción vuelve del pasado, entra en un reducer cuya feature ya no está en pantalla y muta un estado que sigue existiendo en memoria pero que ya nadie mira, hasta que el usuario vuelve a entrar y encuentra la pantalla en una situación que no recuerda haber provocado.

flowchart TB
E1[entrada 1 arranca reloj] --> V1[efecto vivo]
E2[entrada 2 arranca reloj] --> V2[efecto vivo]
E3[entrada 3 arranca reloj] --> V3[efecto vivo]
V1 --> ST[store recibe tic por triplicado]
V2 --> ST
V3 --> ST
ST --> B[contador al triple y bateria que baja]
style B fill:#f38ba8,color:#11111b

Atar el efecto al estado con ifLet y forEach

Aquí está la pieza que convierte el problema en un no-problema, y que mucha gente usa sin saber que la tiene. Cuando un reducer hijo se integra en el padre con ifLet, ifCaseLet o forEach, esos combinadores no se limitan a enrutar acciones: cancelan automáticamente los efectos del hijo en cuanto su estado deja de existir.

@Reducer
struct Padre {
  @ObservableState
  struct State: Equatable {
    @Presents var detalle: Detalle.State?
    var filas: IdentifiedArrayOf<Fila.State> = []
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .cerrarDetalle:
        state.detalle = nil
        return .none
      // ...
      }
    }
    .ifLet(\.$detalle, action: \.detalle) { Detalle() }
    .forEach(\.filas, action: \.filas) { Fila() }
  }
}

Poner state.detalle = nil no es solo vaciar un campo: es el hecho que da de baja todos los efectos que el hijo tuviera en vuelo. Igual con forEach: quitar un elemento de la colección cancela los efectos de ese elemento y solo de ese. La consecuencia práctica es importante y libera de mucha ceremonia: si tu feature vive dentro de un opcional presentado o de una colección gestionada por estos combinadores, no necesitas escribir una acción de desaparición ni un .cancel(id:) de despedida. La condición para que ocurra es la que TCA lleva pidiendo desde el nivel 3 —modelar la navegación y la pertenencia como datos dentro del estado del padre— y esta es una de sus recompensas menos anunciadas: cuando quién existe es un dato, dejar de existir es un evento que el sistema puede observar y sobre el que puede actuar.

Por qué onDisappear no es un buen ancla

La tentación evidente es cancelar en el gemelo de onAppear. Es frágil por tres motivos independientes, y conviene conocerlos porque el fallo resultante es difícil de atribuir. Primero, no es fiable: en contenedores perezosos, una celda que sale del área visible recibe onDisappear sin que su estado haya desaparecido, y cancelarías un efecto que sigue siendo necesario. Segundo, no es exhaustivo: hay configuraciones de navegación y desmontajes bruscos donde el aviso llega tarde o no llega, y confiar en él deja la fuga intacta justo en los caminos raros, que son los que nadie prueba a mano. Tercero, y más de fondo: onDisappear habla de la vista, y lo que quieres atar es la feature. Son dos ciclos de vida distintos y solo coinciden por casualidad.

.task { await store.send(.task).finish() }

Cuando de verdad quieres el ciclo de vida de la vista, esa es la forma honesta de pedirlo: task arranca al aparecer y cancela su tarea al desmontarse, y el .finish() mantiene la tarea abierta mientras el efecto siga vivo. Sirve para suscripciones que solo tienen sentido con la pantalla delante. Para todo lo que deba sobrevivir a un cambio de pestaña o a una presentación modal por encima, el ancla correcta es el estado, no la vista.

La pregunta que desambigua los tres anclajes es siempre la misma, y conviene formularla en voz alta antes de escribir el efecto: ¿de qué depende que este trabajo siga teniendo sentido? Si depende de que exista un dato —un detalle abierto, una fila en la lista—, el ancla es ese dato y los combinadores se ocupan. Si depende de que el usuario esté mirando —una animación, un vídeo, una suscripción cara que no aporta nada en segundo plano—, el ancla es la vista y el modificador task es la respuesta. Y si no depende de nada porque la feature es la raíz de la app, entonces eres tú quien debe decidir explícitamente cuándo deja de tener sentido, porque no hay ningún acontecimiento del sistema que lo señale por ti.

Fugas típicas y cómo se ven

La tercera fila es la más sutil y la que más cuesta ver en una revisión de código. Si el padre, al presentar el detalle, devuelve él mismo el efecto que carga los datos del detalle, ese efecto queda registrado en el ámbito del padre y ifLet no lo alcanza: descartar el hijo no lo mata, porque nunca fue del hijo. El arreglo es de responsabilidad, no de sintaxis: el efecto de una feature debe devolverlo esa feature. Cuando la propiedad de los efectos coincide con la propiedad del estado, la cancelación automática cubre todo el terreno; cuando se desalinean, aparecen justo los huecos que la tabla enumera.

La cuarta fila enuncia el principio general de todo el nivel, aplicado a la coexistencia: una identidad solo distingue lo que es capaz de distinguir. Dos instancias de la misma feature que puedan estar vivas a la vez bajo el mismo ámbito necesitan identidades distintas, y la forma de conseguirlo es incorporar al CancelID aquello que las diferencia —el ID del elemento, el identificador del documento abierto— tal como viste en la lección 2.

Y hay una red de seguridad que conviene aprender a leer como diagnóstico y no como molestia. El TestStore falla al terminar un test si queda cualquier efecto en vuelo, con un mensaje que nombra el efecto sin consumir. Ese fallo es el detector de fugas: un test que ejercite entrar, hacer algo y salir revienta si tu feature deja algo corriendo, y revienta en tu máquina, en segundos, en vez de reportarse como un consumo de batería anómalo tres versiones después.

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

  await store.send(.abrirDetalle) { $0.detalle = Detalle.State() }
  await store.send(.detalle(.presented(.alAparecer)))
  await clock.advance(by: .seconds(1))
  await store.receive(\.detalle.presented.tic) { $0.detalle?.segundos = 1 }
  await store.send(.cerrarDetalle) { $0.detalle = nil }   // aqui muere el reloj
}

Si borraras el .ifLet de la integración, ese último send dejaría el temporizador con vida y el test fallaría al terminar. Merece la pena interiorizar la implicación: la cancelación al desaparecer no es una propiedad que se comprueba mirando el consumo de batería en un dispositivo, es una propiedad que se afirma en un test unitario de doce líneas y que la integración continua vigila en cada commit.