Alertas y diálogos: `AlertState` como dato testeable

De todas las cosas que una app puede poner encima de una pantalla, la alerta es la más humilde: dos líneas de texto y un par de botones que desaparecen enseguida. También es, con diferencia, la más maltratada. En el estilo imperativo se construye en el punto exacto del código donde hace falta, con closures que capturan lo que tengan a mano, y el resultado es que la lógica más delicada de la aplicación —la confirmación antes de borrar, el aviso antes de perder cambios— acaba viviendo dentro de un cierre anónimo colgado de la capa de vistas, donde ningún test la alcanza. TCA le aplica el mismo tratamiento que a todo lo demás, sin ninguna concesión: la alerta es un valor que vive en el estado, sus botones son casos de un enum, y mostrarla consiste en asignarla al mismo tipo de hueco con el que se presenta una pantalla entera. Lo que se gana con ese giro no es elegancia, es que la confirmación de borrado pase a ser código probado.

La alerta como valor

El patrón es el de una presentación cualquiera, con una diferencia: el estado presentado no es la State de una feature sino un AlertState parametrizado por el enum de sus botones.

@Reducer
struct Cuenta {
  @ObservableState
  struct State: Equatable {
    var perfil: Perfil
    @Presents var alerta: AlertState<Action.Alerta>?
  }

  enum Action {
    case borrarPulsado
    case alerta(PresentationAction<Alerta>)

    @CasePathable
    enum Alerta: Equatable {
      case confirmarBorrado
    }
  }

  @Dependency(\.cuentaClient) var cuentaClient

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .borrarPulsado:
        state.alerta = .confirmarBorrado
        return .none

      case .alerta(.presented(.confirmarBorrado)):
        return .run { _ in try await cuentaClient.borrar() }

      case .alerta:
        return .none
      }
    }
    .ifLet(\.$alerta, action: \.alerta)
  }
}

El valor de la alerta se declara aparte, como una constante estática sobre el tipo, porque es un dato y los datos con nombre se reutilizan y se comparan:

extension AlertState where Action == Cuenta.Action.Alerta {
  static let confirmarBorrado = Self {
    TextState("Borrar la cuenta")
  } actions: {
    ButtonState(role: .destructive, action: .confirmarBorrado) {
      TextState("Borrar")
    }
    ButtonState(role: .cancel) {
      TextState("Cancelar")
    }
  } message: {
    TextState("Se perderan todos los datos y la operacion no se puede deshacer.")
  }
}

Lo decisivo está en ButtonState. Su parámetro action no es una closure sino un caso del enum anidado, es decir, un dato inerte que se guarda dentro del estado y viaja después por el canal de presentación como cualquier otra acción. El botón de cancelar no lleva ninguno porque cancelar no es un hecho del dominio: es simplemente no hacer nada, y TCA lo traduce a un dismiss que ifLet resuelve vaciando el hueco. Fíjate también en que el reducer no comprueba en ningún momento si la alerta sigue en pantalla antes de borrar la cuenta; no le hace falta, porque la única forma de que llegue .confirmarBorrado es que el usuario haya pulsado ese botón concreto de esa alerta concreta.

En la vista, con el store declarado como @Bindable, un solo modificador cierra el circuito, y no recibe closures de ningún tipo:

Form { /* ... */ }
  .alert($store.scope(state: \.alerta, action: \.alerta))

Cuando la alerta es meramente informativa —un aviso con un único botón de aceptar— no hay ninguna acción que emitir, y el tipo lo dice: AlertState<Never>. Ese parámetro imposible de habitar es la forma en que el sistema de tipos afirma que de esa alerta no puede salir nada.

El diálogo de confirmación es la misma idea

ConfirmationDialogState comparte estructura, tipos y filosofía con AlertState; solo cambia la presentación en pantalla y el número razonable de opciones.

state.destino = .dialogo(
  ConfirmationDialogState {
    TextState("Que quieres hacer con el articulo")
  } actions: {
    ButtonState(action: .duplicar) { TextState("Duplicar") }
    ButtonState(action: .archivar) { TextState("Archivar") }
    ButtonState(role: .destructive, action: .borrar) { TextState("Borrar") }
    ButtonState(role: .cancel) { TextState("Cancelar") }
  }
)

Ambos encajan sin ceremonia dentro de un @Reducer enum de destino junto a las demás pantallas, porque la macro admite casos cuyo estado es uno de estos tipos. Así, una feature con un editor, un detalle y una alerta sigue teniendo un único hueco y sigue siendo incapaz de mostrar dos cosas a la vez.

Afirmar una alerta en un test

Como la alerta es un valor, el test no la busca en la pantalla: la compara. Y como los botones son casos, pulsarlos es enviar acciones.

@Test
func borradoConfirmado() async {
  let store = TestStore(initialState: Cuenta.State(perfil: .prueba)) {
    Cuenta()
  } withDependencies: {
    $0.cuentaClient.borrar = { }
  }

  await store.send(.borrarPulsado) {
    $0.alerta = .confirmarBorrado
  }

  await store.send(\.alerta.confirmarBorrado)
  await store.send(\.alerta.dismiss) {
    $0.alerta = nil
  }
}

Observa lo que este test comprueba sin tocar la interfaz: que pulsar borrar no borra nada todavía, que aparece una alerta con ese título y esos dos botones exactos, que el botón destructivo desencadena la llamada al cliente y que descartar vacía el hueco. En una arquitectura donde la alerta se construye en la vista, cada una de esas cuatro afirmaciones exige un test de interfaz, y el segundo —que el título y los botones son los correctos— no suele escribirse jamás. Aquí es una comparación de valores que el TestStore exige de todos modos por su exhaustividad.

flowchart LR
A[Accion borrarPulsado] --> S[state alerta igual a AlertState]
S --> V[Modificador alert sobre store scope]
V --> U[El usuario pulsa un boton]
U -->|caso del enum Alerta| R[Reducer decide y devuelve efecto]
U -->|boton cancel| D[PresentationAction dismiss]
D --> N[ifLet vacia el hueco]
style S fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b