cancelInFlight: un solo efecto vivo por identidad

La lección anterior dejó dos operaciones separadas: registrar un efecto bajo un nombre y dar de baja lo que viva bajo ese nombre. Casi siempre las quieres juntas y en ese orden —cancela lo anterior, arranca lo nuevo—, y por eso .cancellable acepta un segundo parámetro que las funde en un solo gesto. Escrito así parece un atajo de comodidad, y es mucho más: cancelInFlight: true no ahorra una línea, establece un invariante. A partir de ese momento, para esa identidad, el sistema garantiza que hay como mucho un efecto vivo. Y como pasa siempre con los invariantes buenos, lo interesante no es lo que impide sino todo lo que permite dejar de comprobar aguas abajo.

Una plaza única por nombre

El parámetro se lee casi como su definición: antes de anotar la tarea nueva en el registro, cancela la que estuviera anotada bajo esa misma identidad.

private enum CancelID { case busqueda }

case let .consultaCambiada(texto):
  state.consulta = texto
  return .run { [texto] send in
    await send(.respuesta(try await cliente.buscar(texto)))
  }
  .cancellable(id: CancelID.busqueda, cancelInFlight: true)

Con esto, el buscador de la lección 1 queda arreglado en un parámetro. Cada pulsación mata la petición anterior y ocupa su plaza; la red solo ve viva, en cada instante, la consulta más reciente. Conceptualmente equivale a devolver .merge(.cancel(id: X), efecto.cancellable(id: X)), pero el store lo hace como una sola operación sobre el registro, sin la ventana en la que ambos efectos podrían coexistir.

sequenceDiagram
participant S as Store
participant R as Registro
participant E1 as Efecto de swif
participant E2 as Efecto de swift
S->>R: registrar busqueda para E1
R->>E1: vive
S->>R: registrar busqueda para E2 con cancelInFlight
R->>E1: cancelado, no emite nada
R->>E2: ocupa la plaza y vive

Fíjate en la línea que más importa del diagrama: no emite nada. El efecto cancelado no manda una acción de éxito, ni de fallo, ni de cancelación. Desde el punto de vista del reducer, es como si nunca hubiera existido. Esa desaparición limpia es lo que permite razonar sobre el estado sin llevar la contabilidad de lo que quedó a medias.

Y el orden importa tanto como el silencio. Que la baja del anterior ocurra antes de dar de alta al nuevo, y no después, es lo que impide un cruce venenoso: si el registro se hiciera primero, el .cancel posterior encontraría en la plaza al efecto recién nacido y se mataría a sí mismo. Ese fallo —el efecto que se suicida por culpa de su propio predecesor— es exactamente lo que ocurre cuando alguien intenta reproducir el patrón a mano con dos retornos separados en el orden equivocado, y es la razón por la que conviene usar el parámetro en vez de improvisar la secuencia.

El invariante y todo lo que simplifica

Un invariante vale por lo que te ahorra. Este vale bastante, y conviene enumerarlo porque su efecto se nota en sitios que a primera vista no tienen que ver con la cancelación.

El caso de la idempotencia merece desarrollo, porque es el que más bugs discretos resuelve. En SwiftUI, el ciclo de vida de una vista no es tan predecible como uno querría: una vista puede aparecer, desaparecer y reaparecer en una navegación por pila, y en ciertas composiciones el onAppear se dispara más veces de las que esperas. Si la acción de aparición abre un stream, cada disparo extra deja un observador de más.

case .alAparecer:
  return .run { send in
    for await notificacion in centro.mensajes() {
      await send(.mensajeRecibido(notificacion))
    }
  }
  .cancellable(id: CancelID.escucha, cancelInFlight: true)

Sin el parámetro, aparecer tres veces deja tres bucles vivos y cada mensaje del centro llega al reducer por triplicado —con lo que eso implica si el reducer inserta en una lista o incrementa un contador—. Con él, la acción alAparecer se vuelve idempotente: ejecutarla una vez o siete deja el sistema en el mismo estado. Es una propiedad muy valiosa en cualquier sistema donde no controlas del todo cuántas veces te van a llamar.

El ahorro de código que produce el invariante se ve mejor comparando las dos versiones del mismo reducer. Sin unicidad, la acción de respuesta se convierte en un pequeño tribunal que dictamina si el dato que le llega merece entrar:

// Sin invariante: cada consumidor arrastra la comprobacion
case let .respuesta(texto, items):
  guard texto == state.consulta else { return .none }
  state.peticionesVivas -= 1
  state.cargando = state.peticionesVivas > 0
  state.resultados = items
  return .none

// Con invariante: no hay nada que dictaminar
case let .respuesta(items):
  state.cargando = false
  state.resultados = items
  return .none

Cuatro líneas menos y, más importante, un campo menos en el estado y un valor asociado menos en la acción. Ese es el patrón que conviene aprender a reconocer: cuando una comprobación aparece repetida en varios consumidores, casi siempre existe un punto único, más arriba, donde se puede volver innecesaria.

Cuando exigir unicidad es un error

El invariante es fuerte, y por eso hay que aplicarlo solo donde de verdad describe el dominio. Preguntarse ¿estos dos efectos compiten por el mismo sitio o son trabajos independientes? casi siempre da la respuesta correcta.

El error más caro de la tabla es el tercero. Si todas las filas de un forEach registran su carga bajo la misma identidad y encima con cancelInFlight, al desplazarse por la lista cada fila que aparece mata la carga de la anterior, y el usuario ve un rosario de celdas que empiezan a cargar y se quedan a medias sin ningún error. El síntoma es desconcertante justo porque no hay excepción ni fallo: el efecto cancelado, ya lo sabes, no dice nada. La corrección es la de la lección 2 —un caso con valor asociado por elemento— y con ella la unicidad pasa a significar lo que debía significar: como mucho una carga viva por fila.

También hay un límite conceptual que conviene tener presente: cancelInFlight implanta una política de último que llega, gana. Existen dominios donde la política correcta es la contraria, primero que llega, gana —una petición crítica que no debe reiniciarse porque el usuario toque dos veces—, y eso no se expresa con este parámetro sino con una guarda en el estado que ignore la acción si ya hay algo en curso. Elegir entre ambas no es un detalle técnico; es una decisión de producto que el código debe reflejar de forma explícita.

Y una advertencia sobre operaciones que escriben en el servidor. Cancelar una lectura es inofensivo, porque no deja rastro; cancelar una escritura es otra cosa. Una petición cancelada del lado del cliente puede haber llegado igualmente al servidor y haberse ejecutado allí: lo que matas es tu espera de la respuesta, no necesariamente el efecto remoto. Por eso cancelInFlight es la opción natural para búsquedas, sugerencias y refrescos, y una decisión que hay que pensar dos veces para envíos, pagos o borrados, donde lo correcto suele ser impedir el segundo disparo antes que cancelar el primero.

Verificar el invariante, no solo confiarlo

Un invariante que solo existe en la cabeza del que lo escribió dura hasta la siguiente refactorización. El TestStore permite fijarlo como aserción, y el test resultante es corto y contundente: dos acciones seguidas, una sola respuesta.

@Test
func soloSobreviveLaUltimaBusqueda() async {
  let llamadas = LockIsolated(0)
  let store = TestStore(initialState: Busqueda.State()) {
    Busqueda()
  } withDependencies: {
    $0.clienteBusqueda.buscar = { _ in
      llamadas.withValue { $0 += 1 }
      return [.demo]
    }
  }
  await store.send(.consultaCambiada("sw")) { $0.consulta = "sw" }
  await store.send(.consultaCambiada("swift")) { $0.consulta = "swift" }
  await store.receive(\.respuesta) { $0.resultados = [.demo] }
}

La prueba de fuego es el receive solitario. Si el efecto de sw hubiera sobrevivido, el TestStore terminaría con una acción emitida y no afirmada, y fallaría. Es decir: la exhaustividad que el nivel 3 presentó como una exigencia incómoda resulta ser, aquí, el mecanismo que detecta que la unicidad se rompió. No hace falta una herramienta especial para auditar efectos vivos; la que ya tienes falla por defecto cuando sobra alguno.