El problema de los formularios: una acción por campo no escala

Hasta aquí la arquitectura ha sido cómoda porque los ejemplos tenían pocos sucesos y todos significaban algo: se pulsó un botón, llegó una respuesta, expiró un temporizador. Un formulario rompe esa comodidad de golpe. La edición de un campo de texto no es un suceso interesante —nadie quiere leerlo en una traza, nadie quiere testearlo aisladamente— pero necesita exactamente el mismo canal que los sucesos que sí importan, porque la vista no puede escribir en el estado por su cuenta. El resultado es un enum Action cuya mitad son setters disfrazados de mensajes. Este nivel entero existe para resolver esa tensión sin sacrificar ninguna de las garantías que la hacen valiosa: mutación en un solo punto, trazabilidad completa, testabilidad exhaustiva.

El formulario escrito a mano

Considera una pantalla de alta de perfil con seis campos: nombre, apellidos, correo, biografía, notificaciones y visibilidad. Escrita con las herramientas de los niveles anteriores, la feature tiene esta forma, y no hay ningún atajo honesto que la haga más corta.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {
    var nombre = ""
    var apellidos = ""
    var correo = ""
    var biografia = ""
    var notificaciones = false
    var visibilidad: Visibilidad = .privado
  }

  enum Action: Equatable {
    case nombreCambiado(String)
    case apellidosCambiados(String)
    case correoCambiado(String)
    case biografiaCambiada(String)
    case notificacionesCambiadas(Bool)
    case visibilidadCambiada(Visibilidad)
    case guardarPulsado
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .nombreCambiado(v):          state.nombre = v;          return .none
      case let .apellidosCambiados(v):      state.apellidos = v;       return .none
      case let .correoCambiado(v):          state.correo = v;          return .none
      case let .biografiaCambiada(v):       state.biografia = v;       return .none
      case let .notificacionesCambiadas(v): state.notificaciones = v;  return .none
      case let .visibilidadCambiada(v):     state.visibilidad = v;     return .none
      case .guardarPulsado:                 return .none
      }
    }
  }
}

En la vista, cada control necesita fabricar a mano un Binding que lea del estado y escriba enviando su acción, porque un control de SwiftUI no acepta otra cosa.

TextField("Nombre", text: Binding(
  get: { store.nombre },
  set: { store.send(.nombreCambiado($0)) }
))

Seis campos son seis casos, seis ramas, seis bindings artesanales y —si el proyecto exige cobertura— seis tests que afirman que asignar un valor asigna ese valor. Añadir un campo toca cuatro sitios. Renombrarlo, cuatro. El coste no es la primera vez: es que crece linealmente y nunca compra nada.

Las tres salidas falsas

Antes de aceptar la propuesta de TCA conviene entender por qué fracasan las alternativas que todo el mundo intenta primero, porque cada fracaso ilumina una restricción que la solución buena debe respetar.

La primera es mutar el estado desde la vista, exponiendo un binding que escriba en store.state directamente. Esto compila en algunas variantes y destruye la propiedad central de la arquitectura: aparece una segunda puerta de escritura que ni la traza ni TestStore ven, y a partir de ahí ningún test demuestra lo que cree demostrar, porque el estado puede haber cambiado sin que ninguna acción lo cuente.

La segunda es un único caso genérico sin tipar, del estilo case establecer(String, Any), donde el primer componente nombra el campo. Colapsa la explosión, sí, pero paga el precio en la moneda más cara de Swift: pierde la comprobación de tipos, convierte los errores de nombre en fallos silenciosos en tiempo de ejecución y hace que la Action deje de ser Equatable de forma útil, con lo que las aserciones del TestStore se vuelven inservibles.

La tercera es mantener un modelo observable paralelo para el formulario y volcarlo al estado solo al pulsar guardar. Funciona hasta que aparece el primer requisito real —validar mientras se escribe, habilitar el botón según el contenido, precargar desde red— y entonces hay dos fuentes de verdad que hay que sincronizar a mano, que es exactamente el problema que la arquitectura existía para eliminar.

flowchart TD
P[Formulario con N campos] --> A[N casos en el enum]
P --> B[N ramas en el switch]
P --> C[N bindings artesanales]
A --> D[Action deja de ser catalogo de sucesos]
B --> D
C --> D
D --> S1[Salida falsa: mutar desde la vista]
D --> S2[Salida falsa: caso generico sin tipar]
D --> S3[Salida falsa: modelo paralelo]
S1 --> X[Rompe traza y tests]
S2 --> X
S3 --> X
D --> OK[Caso parametrico con key path tipado]
style OK fill:#a6e3a1,color:#11111b

La forma de la solución

Las tres salidas falsas comparten un diagnóstico: intentan reducir el número de casos eliminando información. La propuesta de TCA hace lo contrario —conserva toda la información y la mueve del nombre del caso a su carga—. En lugar de que el caso se llame nombreCambiado y transporte un String, existe un solo caso llamado binding que transporta un valor capaz de decir, con tipos verificados, dos cosas: qué propiedad del estado hay que escribir y con qué valor.

enum Action: BindableAction {
  case binding(BindingAction<State>)
  case guardarPulsado
}

Ese valor empaqueta un key path escribible hacia una propiedad del State junto con el nuevo contenido, y sabe aplicarse a sí mismo sobre una instancia del estado. La pieza que lo aplica es un reducer dedicado que se coloca en el body y que, al recibir el caso binding, ejecuta la escritura sin que tú redactes una sola asignación. Los seis casos se convierten en uno, las seis ramas en ninguna, y los seis bindings artesanales en seis expresiones de la forma $store.campo que la vista obtiene gratis.