El `Coordinator`: devolver eventos al mundo declarativo

UIKit comunica hacia fuera con delegados, con el par objetivo y acción, con notificaciones y con cierres. Los tres primeros mecanismos exigen algo que en SwiftUI no existe: un objeto de referencia que viva más que un instante y al que se pueda apuntar. Una struct que se recrea en cada evaluación del body no puede ser el delegado de nada, porque para cuando llegue el mensaje ya no existirá la instancia que se registró. El Coordinator resuelve esa carencia con precisión quirúrgica: es el único objeto con identidad estable que tú controlas dentro de un envoltorio, vive exactamente lo que vive la vista de UIKit y su trabajo consiste en recibir eventos imperativos y traducirlos a escrituras sobre el estado declarativo. Todo lo que sale mal en la vuelta del puente sale mal por confundir la vida de ese objeto con la vida de la struct que lo creó.

Un objeto con identidad dentro de un valor

SwiftUI llama a makeCoordinator una sola vez, antes de makeUIView, y conserva el objeto resultante mientras la identidad de la vista siga existiendo. Ese objeto llega después en el context de todos los métodos y en el parámetro de dismantleUIView. Es, literalmente, la caja de estado imperativo que el sistema te presta.

struct CampoDeBusqueda: UIViewRepresentable {
    @Binding var texto: String
    var alEnviar: (String) -> Void

    func makeCoordinator() -> Coordinator { Coordinator(self) }

    func makeUIView(context: Context) -> UISearchBar {
        let barra = UISearchBar()
        barra.delegate = context.coordinator
        return barra
    }

    func updateUIView(_ barra: UISearchBar, context: Context) {
        context.coordinator.envoltorio = self
        if barra.text != texto { barra.text = texto }
    }

    final class Coordinator: NSObject, UISearchBarDelegate {
        var envoltorio: CampoDeBusqueda

        init(_ envoltorio: CampoDeBusqueda) { self.envoltorio = envoltorio }

        func searchBar(_ barra: UISearchBar, textDidChange nuevo: String) {
            envoltorio.texto = nuevo
        }

        func searchBarSearchButtonClicked(_ barra: UISearchBar) {
            envoltorio.alEnviar(barra.text ?? "")
        }
    }
}

Hay dos detalles de propiedad de memoria que conviene tener claros desde el principio. El primero: SwiftUI retiene el coordinador, así que tú no necesitas guardarlo en ninguna parte. El segundo: casi todas las propiedades de delegado en UIKit son débiles, de modo que si el coordinador no estuviera retenido por el sistema, el delegado se evaporaría y los mensajes dejarían de llegar sin ningún error visible. Esa combinación —el sistema retiene, la vista apunta débilmente— es exactamente la correcta y no hay que tocarla.

La referencia que caduca

La línea más importante del ejemplo anterior es la que reasigna el envoltorio en cada actualización, y es también la que más se omite. El razonamiento erróneo es tentador: el coordinador ya recibió el envoltorio en su inicializador, así que ya tiene lo que necesita. Pero el envoltorio es una struct, se copió por valor en aquel momento y esa copia quedó congelada con los valores del primer instante. Si el Binding proviene de otra rama del árbol, si un cierre captura una versión antigua del modelo o si una propiedad simple cambió después, el coordinador seguirá operando sobre datos de hace diez segundos.

Existe una alternativa a reasignar el envoltorio entero, y en equipos grandes suele ser preferible: que el coordinador no conozca la struct sino solo las piezas que necesita, declaradas como cierres. Reduce el acoplamiento, hace obvio en la firma qué eventos salen del envoltorio y facilita la prueba del coordinador por separado. El precio es que hay que actualizar esos cierres en cada llamada a updateUIView, exactamente por la misma razón que antes.

final class Coordinator: NSObject, UITextViewDelegate {
    var alCambiarTexto: (String) -> Void = { _ in }
    var alTerminarEdicion: () -> Void = { }
    var actualizacionProgramatica = false

    func textViewDidChange(_ vista: UITextView) {
        guard !actualizacionProgramatica else { return }
        alCambiarTexto(vista.text)
    }
}

El eco y cómo se corta

El ciclo natural del puente es simple: el estado cambia, updateUIView lo escribe en la vista de UIKit, la vista notifica al delegado que su contenido cambió y el delegado escribe en el estado. Ese último paso cierra un círculo que no debería existir, porque el cambio no vino de la persona usuaria sino de tu propia sincronización. En el mejor caso se desperdicia una invalidación; en el peor, el cursor de escritura salta, la selección se pierde o se establece una oscilación entre dos valores que se pisan.

La solución canónica tiene dos capas y conviene aplicar ambas. La primera es comparar antes de asignar, que ya evita la mayoría de los ecos porque no se escribe si el valor no cambió. La segunda es marcar la ventana programática con una bandera en el coordinador, porque hay controles que notifican incluso cuando se les asigna un valor idéntico, y otros que notifican efectos derivados —cambio de selección, cambio de desplazamiento— que ninguna comparación de texto puede prever.

func updateUIView(_ vista: UITextView, context: Context) {
    context.coordinator.alCambiarTexto = { texto = $0 }
    guard vista.text != texto else { return }
    context.coordinator.actualizacionProgramatica = true
    let seleccion = vista.selectedRange
    vista.text = texto
    vista.selectedRange = seleccion
    context.coordinator.actualizacionProgramatica = false
}

flowchart LR
A[Estado de SwiftUI] -->|updateUIView| B[Vista de UIKit]
B -->|delegado| C[Coordinator]
C -->|escribe en el binding| A
C -.->|bandera programatica| D[Evento descartado]
style C fill:#89b4fa,color:#11111b
style D fill:#f38ba8,color:#11111b

Hay una tercera fuente de eventos que se suele olvidar y que el coordinador gestiona igual de bien: las notificaciones y las suscripciones. Si tu vista envuelta necesita reaccionar al teclado, a un cambio de orientación o a un flujo de datos, el observador se registra en el inicializador del coordinador o en makeUIView, se guarda ahí mismo y se cancela en dismantleUIView. Guardar suscripciones en el envoltorio no funciona, porque el envoltorio muere en cuanto termina la evaluación del body; guardarlas en la vista de UIKit funciona pero mezcla responsabilidades. El coordinador es el sitio.

Cuándo el coordinador sobra

No todo envoltorio necesita coordinador, y añadirlo por costumbre engorda el código sin motivo. La regla es directa: si el flujo de información es de una sola dirección —del valor de SwiftUI hacia la configuración de UIKit— y la vista envuelta no comunica nada hacia fuera, no hay nada que coordinar. Un envoltorio de UIActivityIndicatorView, de una vista de blur o de un UIProgressView es puro camino de ida.