Validación de formularios: estado derivado, errores por campo y envío

Escribir en el estado era la mitad fácil. La difícil es responder a la pregunta que el usuario hace mirando el botón: ¿ya puedo enviar esto? Una respuesta ingenua guarda un campo booleano y lo actualiza en cada edición, y funciona hasta la primera vez que alguien añade un campo y olvida tocar el sitio donde se recalcula; a partir de ahí el formulario miente. La respuesta buena es que la validez no es un dato que se guarda sino una consecuencia que se deriva, y que el estado almacenado debe contener solo lo que el usuario escribió más el mínimo necesario para saber qué se le puede reprochar y cuándo. Esta lección construye esa capa y cierra el nivel enseñando el envío completo, con su bloqueo, su fallo y su vuelta.

La validez se deriva, no se guarda

La regla es la misma que rige todo el modelado de estado en TCA y aquí se paga con especial rapidez: si un valor puede calcularse a partir de otros, guardarlo es crear una segunda fuente de verdad que hay que mantener sincronizada a mano. Un formulario tiene muchas de esas oportunidades, así que la disciplina se nota.

@ObservableState
struct State: Equatable {
  var nombre = ""
  var correo = ""
  var edad = ""
  var aceptaTerminos = false
  var tocados: Set<Campo> = []
  var intentoEnvio = false
  var enviando = false
  var errorRemoto: [Campo: String] = [:]

  var errores: [Campo: String] {
    var e: [Campo: String] = [:]
    if nombre.trimmingCharacters(in: .whitespaces).isEmpty {
      e[.nombre] = "El nombre es obligatorio"
    }
    if !correo.contains("@") {
      e[.correo] = "Introduce un correo valido"
    }
    if Int(edad).map({ $0 < 18 }) ?? true {
      e[.edad] = "Debes ser mayor de edad"
    }
    if !aceptaTerminos {
      e[.terminos] = "Debes aceptar los terminos"
    }
    return e.merging(errorRemoto) { _, remoto in remoto }
  }

  var esValido: Bool { errores.isEmpty }
  var puedeEnviar: Bool { esValido && !enviando }

  func errorVisible(_ campo: Campo) -> String? {
    guard tocados.contains(campo) || intentoEnvio else { return nil }
    return errores[campo]
  }
}

Lo almacenado es exactamente lo que nadie puede deducir: lo que el usuario escribió, qué campos ha tocado, si ya intentó enviar, si hay un envío en curso y qué reprochó el servidor. Todo lo demás se calcula. La consecuencia práctica es que añadir un campo con su regla es una sola edición dentro de errores: el botón, los mensajes y los tests se actualizan solos porque todos leen de la misma derivación.

Las propiedades calculadas no participan en la igualdad sintetizada ni pueden ser destino de un binding, y ambas cosas son deseables aquí. La primera evita comparaciones redundantes; la segunda hace imposible por construcción que alguien intente escribir en esValido.

Errores por campo y el momento de mostrarlos

Un formulario que enseña el nombre es obligatorio antes de que el usuario haya podido escribir nada es hostil. La solución no es retrasar la validación —que corre siempre— sino separar el hecho de que un campo sea inválido del hecho de que ya sea justo reprochárselo.

case .binding(\.nombre):   state.tocados.insert(.nombre); state.errorRemoto[.nombre] = nil; return .none
case .binding(\.correo):   state.tocados.insert(.correo); state.errorRemoto[.correo] = nil; return .none
case .binding(\.edad):     state.tocados.insert(.edad);   state.errorRemoto[.edad] = nil;   return .none
case .binding:             return .none

Cada edición marca el campo como tocado y borra el reproche remoto que pudiera arrastrar, porque un error que el servidor devolvió sobre un valor anterior deja de aplicar en cuanto el valor cambia. Mantener ese error visible mientras el usuario lo corrige es una de las frustraciones más citadas en formularios reales.

En la vista, el mensaje cuelga del campo y el botón lee la derivación.

Section {
  TextField("Nombre", text: $store.nombre)
  if let e = store.errorVisible(.nombre) {
    Text(e).font(.caption).foregroundStyle(.red)
  }
  TextField("Correo", text: $store.correo)
  if let e = store.errorVisible(.correo) {
    Text(e).font(.caption).foregroundStyle(.red)
  }
}
Button("Crear cuenta") { store.send(.enviarPulsado) }
  .disabled(!store.puedeEnviar)

flowchart TD
ED[Edicion de campo] --> BR[BindingReducer escribe]
BR --> TOC[Marcar campo tocado y limpiar error remoto]
TOC --> DER[Recalcular errores derivados]
DER --> VIS{Campo tocado o envio intentado}
VIS -->|si| MSG[Mostrar mensaje bajo el campo]
VIS -->|no| OCU[Ocultar mensaje]
DER --> BTN[Habilitar boton si valido y sin envio en curso]
BTN --> ENV[Enviar]
ENV --> OK[Exito y delegate hacia arriba]
ENV --> KO[Fallo con errores por campo]
KO --> DER
style OK fill:#a6e3a1,color:#11111b

El envío y su vuelta

El botón habilitado no basta: el envío es un efecto con estados intermedios que el usuario debe percibir y con un fallo que hay que devolver al mismo lenguaje que ya usa el formulario.

case .enviarPulsado:
  state.intentoEnvio = true
  guard state.esValido else { return .none }
  state.enviando = true
  state.errorRemoto = [:]
  return .run { [datos = Alta(state)] send in
    await send(.envioTermino(Result { try await self.api.crearCuenta(datos) }))
  }

case .envioTermino(.success):
  state.enviando = false
  return .send(.delegate(.cuentaCreada))

case let .envioTermino(.failure(error)):
  state.enviando = false
  if let validacion = error as? ErrorDeValidacion {
    state.errorRemoto = validacion.porCampo
  } else {
    state.alerta = AlertState { TextState("No se pudo crear la cuenta") }
  }
  return .none

El intentoEnvio se marca antes del guardia para que, al pulsar con el formulario incompleto, aparezcan de golpe todos los mensajes pendientes aunque el usuario no hubiera tocado esos campos. El guardia protege contra el envío inválido incluso si alguien logra activar el botón por otra vía. El vaciado del error remoto evita mezclar reproches de dos intentos distintos. Y el fallo se bifurca: si el servidor habla el idioma de los campos, sus mensajes entran por el mismo canal que la validación local y aparecen exactamente donde el usuario los espera; si es un fallo genérico, se presenta como alerta porque no pertenece a ningún campo.