Envolver lo existente: servicios y singletons como dependencias

En toda app con años hay una clase que nadie quiere abrir. Tiene mil quinientas líneas, un nombre acabado en Manager, una propiedad estática compartida, media docena de responsabilidades que se fueron pegando y un comentario de 2020 que dice que hay que refactorizarla. La buena noticia es que para adoptar TCA no hace falta refactorizarla, ni entenderla entera, ni siquiera abrirla. Hace falta algo mucho más barato y bastante más útil: describir con precisión qué le pide tu pantalla, escribir esa descripción como un tipo, y hacer que la implementación viva se limite a reenviarle las llamadas. Eso es una costura, y una costura bien puesta convierte un obstáculo insalvable en un detalle de implementación que se puede sustituir el día que apetezca.

La costura: envolver en lugar de reescribir

El patrón es el del Nivel 13 aplicado a código que no controlas. Se declara el struct de closures que describe lo que necesitas, y el liveValue no implementa nada: reenvía a lo que ya existe. La clase original no se entera de que la están usando desde otra arquitectura, y ese es exactamente el objetivo.

@DependencyClient
struct SesionCliente {
  var usuarioActual: @Sendable () -> Usuario?
  var iniciar: @Sendable (_ correo: String, _ clave: String) async throws -> Usuario
  var cerrar: @Sendable () async -> Void
  var cambios: @Sendable () -> AsyncStream<Usuario?> = { .never }
}

extension SesionCliente: DependencyKey {
  static let liveValue = Self(
    usuarioActual: { SessionManager.shared.currentUser.map(Usuario.init) },
    iniciar: { correo, clave in
      Usuario(try await SessionManager.shared.login(email: correo, password: clave))
    },
    cerrar: { await SessionManager.shared.logout() },
    cambios: {
      AsyncStream { continuacion in
        let token = SessionManager.shared.observe { continuacion.yield($0.map(Usuario.init)) }
        continuacion.onTermination = { _ in SessionManager.shared.removeObserver(token) }
      }
    }
  )
  static let testValue = Self()
}

Tres decisiones merecen atención. El liveValue no contiene lógica, solo traducción, y esa disciplina es lo que garantiza que envolver no pueda introducir defectos nuevos. El testValue vacío que genera @DependencyClient falla ruidosamente si alguien invoca algo que el test no declaró, con lo que la costura viene con su propio detector de dependencias ocultas. Y el tipo Usuario del dominio se construye en la frontera, de modo que el modelo heredado —probablemente una clase con referencias y opcionales por todas partes— no entra en tu State.

Diseñar la interfaz que te hubiera gustado tener

Aquí está el beneficio inesperado. La costura no está obligada a parecerse a lo que envuelve: es una oportunidad de rediseño con coste cero, porque cambiar la firma de la costura no cuesta nada mientras la implementación siga siendo un reenvío. Un cliente que expone sincronizar con un cierre de finalización, una bandera booleana y un parámetro force que nadie sabe explicar puede envolverse en una función async que devuelve un valor o lanza, y ese cambio hace que el reducer se escriba en dos líneas en vez de en quince.

// Lo que existe, con su historia encima
final class SyncManager {
  static let shared = SyncManager()
  func sync(force: Bool, completion: @escaping (NSError?) -> Void) { ... }
}

// La interfaz que querías: dominio, no mecánica
@DependencyClient
struct Sincronizacion {
  var ejecutar: @Sendable (_ forzada: Bool) async throws -> Void
}

extension Sincronizacion: DependencyKey {
  static let liveValue = Self(
    ejecutar: { forzada in
      try await withCheckedThrowingContinuation { c in
        SyncManager.shared.sync(force: forzada) { fallo in
          if let fallo { c.resume(throwing: fallo) } else { c.resume(returning: ()) }
        }
      }
    }
  )
}

Dos criterios ayudan a decidir la forma de la interfaz. El primero es que hable de intenciones del dominio y no de pasos técnicos: guardarBorrador en vez de write más flush más invalidateCache. El segundo es que sea la mínima que satisface a quien la usa hoy, porque una interfaz estrecha es fácil de sustituir y una ancha se convierte en otro singleton con otra cara.

Delegados, notificaciones y todo lo que empuja

El código heredado no solo se llama, también avisa. Delegados, NotificationCenter, KVO y observadores propios son fuentes que empujan valores, y su forma natural en la costura es un AsyncStream que el reducer consume dentro de un .run, tal y como aprendiste con los efectos de larga vida del Nivel 10.

@DependencyClient
struct Conectividad {
  var estados: @Sendable () -> AsyncStream<Bool> = { .never }
}

extension Conectividad: DependencyKey {
  static let liveValue = Self(
    estados: {
      AsyncStream { continuacion in
        let observador = NotificationCenter.default.addObserver(
          forName: .reachabilityChanged, object: nil, queue: nil
        ) { nota in
          continuacion.yield(nota.userInfo?["online"] as? Bool ?? false)
        }
        continuacion.onTermination = { _ in
          NotificationCenter.default.removeObserver(observador)
        }
      }
    }
  )
}

El bloque onTermination no es opcional ni cosmético: es lo que hace que cancelar el efecto desmonte el observador. Sin él, cada aparición de la pantalla registra un oyente más y el defecto tarda semanas en manifestarse, en forma de trabajo duplicado que crece con la sesión.

Aislamiento: el peaje de Swift 6

La costura es también la aduana de concurrencia, y ahí aparecen la mayoría de los errores de compilación de una migración real. La clase heredada casi nunca es Sendable, muchas veces exige el hilo principal sin declararlo y sus modelos son clases mutables compartidas. Las tres respuestas prácticas, por orden de preferencia: aislar la closure con @MainActor cuando la clase realmente lo necesita, convertir en la frontera el modelo heredado a un valor Sendable de tu dominio, y solo en último término apoyarse en @preconcurrency o en un nonisolated(unsafe) documentado con el motivo y con fecha de revisión.

En la práctica, la mayoría de los casos se resuelven envolviendo la lectura en MainActor.assumeIsolated dentro del liveValue, que es una afirmación verificable en tiempo de ejecución y no una promesa vacía. La regla de fondo es que lo no seguro se queda dentro de la costura. Si el liveValue es el único punto del sistema que toca la clase heredada, el análisis de riesgos se reduce a auditar un archivo pequeño, en vez de rastrear cuarenta llamadas repartidas por la app.

flowchart LR
R[Reducer] --> D[Dependencia declarada]
D --> L[liveValue que solo delega]
D --> T[testValue sin implementar]
D --> P[previewValue con datos fijos]
L --> S[Singleton heredado sin tocar]
S --> N[NotificationCenter y delegados]
N --> A[AsyncStream con onTermination]
style D fill:#89b4fa,color:#11111b
style S fill:#fab387,color:#11111b