Enviar acciones desde UIKit

La mitad ascendente del ciclo es, en UIKit, sorprendentemente más fácil que la descendente. No hace falta ningún mecanismo nuevo: store.send es exactamente el mismo método que usa una vista de SwiftUI, y lo único que hay que resolver es cómo llegar hasta él desde los cuatro sistemas de eventos que UIKit acumuló en cuarenta años de historia. Lo difícil no es técnico sino de disciplina, porque UIKit invita constantemente a colar una decisión en el manejador: comprobar si el campo está vacío antes de enviar, deshabilitar el botón ahí mismo, guardar en una propiedad del controlador lo que el usuario acaba de escribir. Cada una de esas comodidades saca un trozo de lógica del reducer y lo esconde en un lugar donde ningún test lo alcanzará. La regla de este nivel es tan corta como severa: el manejador traduce y no piensa.

Cuatro puertas, un solo destino

El mecanismo histórico es target-action, y su traducción es un método de una línea. El moderno es UIAction, que evita el selector y permite escribir la traducción en el sitio donde se crea el control. Ambos conviven sin ninguna fricción.

private lazy var incrementar = UIButton(
  type: .system,
  primaryAction: UIAction(title: "Incrementar") { [weak self] _ in
    self?.store.send(.incrementarPulsado)
  }
)

private lazy var refrescar: UIRefreshControl = {
  let control = UIRefreshControl()
  control.addTarget(self, action: #selector(refrescarTirado), for: .valueChanged)
  return control
}()

@objc private func refrescarTirado() {
  store.send(.refrescarTirado)
}

Fíjate en que ninguno de los dos manejadores consulta nada ni decide nada. No comprueba si ya se está refrescando, no deshabilita el botón, no lee el texto de un campo para validar. Reporta un hecho: el usuario tiró para refrescar. Si ya había una petición en vuelo, ese es un problema del reducer, que tiene el estado completo para resolverlo y un test que lo demuestra. El manejador no tiene ni el estado ni el test.

La nomenclatura arrastra la misma disciplina que aprendiste con las acciones de origen: el caso se llama refrescarTirado y no refrescar, porque describe lo que pasó y no lo que hay que hacer. Un manejador que envía .guardar está dando una orden y, con ella, tomando la decisión de guardar. Uno que envía .botonGuardarPulsado está informando, y deja intacta la posibilidad de que el reducer decida no guardar porque el formulario es inválido o porque ya hay un guardado en curso.

Delegados: los que cuentan y los que preguntan

Un protocolo de delegado de UIKit mezcla dos clases de métodos que conviene separar con cuidado, porque se traducen de maneras opuestas. Están los que notifican un hecho ya consumado —textFieldDidChangeSelection, didSelectRowAt, scrollViewDidEndDragging— y están los que interrogan al presente para que el framework decida cómo comportarse —numberOfRowsInSection, shouldChangeCharactersIn, canEditRowAt—. Los primeros son acciones. Los segundos, jamás.

extension ListaViewController: UITableViewDelegate, UITableViewDataSource {
  // Interrogacion: se responde leyendo el estado, aqui y ahora.
  func tableView(_ t: UITableView, numberOfRowsInSection s: Int) -> Int {
    store.elementos.count
  }

  func tableView(_ t: UITableView, canEditRowAt i: IndexPath) -> Bool {
    store.elementos[i.row].esBorrable
  }

  // Notificacion: se traduce a una accion y se olvida.
  func tableView(_ t: UITableView, didSelectRowAt i: IndexPath) {
    store.send(.filaSeleccionada(id: store.elementos[i.row].id))
  }
}

La razón por la que un método de interrogación no puede convertirse en acción es de temporalidad, no de estilo: el framework necesita la respuesta ahora mismo, dentro de la llamada, y una acción es una petición cuyo efecto sobre el estado ocurre después de atravesar el reducer. Devolver un valor derivado del estado actual es, en cambio, perfectamente compatible con la unidireccionalidad, porque leer no altera nada. Esta separación entre preguntar y contar tiene un nombre viejo —separación entre consultas y comandos— y encontrarla incrustada en un protocolo diseñado en los años noventa dice mucho a favor de aquel diseño.

Un matiz importante en la notificación: envía identidad, no posición. Un IndexPath es una coordenada de pantalla que puede haberse desincronizado del estado si llegó una actualización entre el toque y la entrega del evento. Resolver el identificador en el manejador, como hace el ejemplo, y enviarlo dentro de la acción hace que el reducer opere sobre el elemento correcto aunque la lista se haya reordenado.

Enlaces bidireccionales de controles

Los campos de texto, los interruptores y los deslizadores son el caso incómodo, porque llevan estado interno propio que hay que mantener sincronizado en las dos direcciones. Escrito a mano son dos piezas: una lectura dentro de observe y un envío desde un manejador de cambio.

observe { [weak self] in
  guard let self else { return }
  if campo.text != store.texto { campo.text = store.texto }
  interruptor.isOn = store.notificaciones
}

@objc private func textoCambio() {
  store.send(.textoCambio(campo.text ?? ""))
}

La comparación antes de asignar no es una optimización sino una necesidad: asignar text a un campo en edición mueve el cursor al final, y sin esa guarda el usuario no puede editar el medio de una palabra. Ese tipo de asperezas es lo que abstraen los enlaces de la capa de UIKit, que permiten declarar @UIBindable sobre el store y atar el control al estado en una línea, siempre que el Action de la feature conforme BindableAction.

@UIBindable var store: StoreOf<Formulario>

override func viewDidLoad() {
  super.viewDidLoad()
  campo.bind(text: $store.texto)
  interruptor.bind(isOn: $store.notificaciones)
}

El enlace no es una puerta trasera al estado: escribe mediante la acción de vinculación, atraviesa el reducer y queda registrado como cualquier otra acción, de modo que un test puede afirmarlo. Lo único que desaparece es la fontanería.

Ese último punto resuelve un problema muy concreto de UIKit: cerrar el indicador de un UIRefreshControl cuando la recarga acaba. Como el manejador no debe decidir nada, la tentación de terminarlo ahí mismo es errónea; la forma limpia es esperar la tarea que send devuelve, que se completa cuando concluyen todos los efectos originados por esa acción.

@objc private func refrescarTirado() {
  Task { [weak self] in
    await self?.store.send(.refrescarTirado).finish()
    self?.refrescar.endRefreshing()
  }
}

flowchart TD
T[Target action o UIAction] --> S[store punto send]
D[Metodo de delegado que notifica]  --> S
B[Enlace de control con UIBindable] --> S
S --> R[Reducer decide y muta el estado]
R --> O[Bloque observe reejecutado]
O --> V[Vistas actualizadas]
Q[Metodo de delegado que interroga] --> L[Lectura directa del estado]
style S fill:#89b4fa,color:#11111b