Validación en vivo: estado derivado sin castigar al que escribe

Escribe la primera letra de un correo y el formulario ya te grita en rojo que no es válido. Claro que no lo es: acabas de empezar. Ese error, técnicamente correcto y humanamente absurdo, es el pecado original de la validación en vivo, y su castigo es doble: irrita mientras escribes y, peor, entrena para ignorar los mensajes rojos, de modo que cuando por fin aparece uno que importa ya no lo lee nadie. Validar bien no consiste en comprobar más cosas, sino en decidir con precisión cuándo el usuario merece saberlas.

La validez es una función, no una variable

La tentación es declarar una propiedad de estado con el resultado de validar y mantenerla al día desde cada punto de edición. Eso crea una segunda fuente de la verdad que empezará a mentir en cuanto alguien modifique un campo por una vía que olvidaste. La validez se deriva del estado en cada recomputación, que es exactamente lo que SwiftUI hace mejor.

enum ErrorCampo: String {
    case correoVacio = "Escribe tu correo."
    case correoMalFormado = "Falta la arroba o el dominio."
    case claveCorta = "La contraseña necesita 8 caracteres o más."
}

struct Formulario {
    var correo = ""
    var clave = ""

    var errorCorreo: ErrorCampo? {
        if correo.isEmpty { return .correoVacio }
        return correo.contains("@") ? nil : .correoMalFormado
    }
    var errorClave: ErrorCampo? {
        clave.count >= 8 ? nil : .claveCorta
    }
    var esValido: Bool { errorCorreo == nil && errorClave == nil }
}

Un ErrorCampo opcional por campo, en lugar de un booleano global, permite dos cosas que un booleano no permite: decir por qué falla ese campo concreto y componer la validez del conjunto sin duplicar reglas. El coste de recalcular estas comprobaciones en cada recomposición es despreciable; si alguna vez no lo fuera, ahí es donde entra una caché explícita, nunca antes.

Cuándo decírselo

Que un campo sea inválido y que su error deba mostrarse son proposiciones distintas. La segunda depende del historial: si el usuario ya escribió ahí, si ya salió del campo, si ya intentó enviar. Añade a cada campo un estado de maduración y mostrarás el error en el momento en que deja de ser una interrupción para convertirse en información.

stateDiagram-v2
[*] --> Intacto
Intacto --> Editando: primera pulsacion
Editando --> Editando: sigue escribiendo
Editando --> Maduro: pierde el foco
Intacto --> Maduro: intento de envio
Maduro --> Editando: vuelve a editar
Maduro --> [*]: valido y enviado

@State private var formulario = Formulario()
@State private var madurados: Set<Campo> = []
@State private var intentoDeEnvio = false
@FocusState private var campoActivo: Campo?

private func debeMostrar(_ campo: Campo) -> Bool {
    intentoDeEnvio || madurados.contains(campo)
}

var body: some View {
    Form { /* campos */ }
        .onChange(of: campoActivo) { anterior, _ in
            if let anterior { madurados.insert(anterior) }
        }
}

La pérdida de foco es el disparador natural porque coincide con el momento en que el usuario declara terminado el campo. El intento de envío madura todos a la vez, incluidos los que nunca se tocaron, que es justo lo que necesita quien pulsó enviar sin rellenar nada.

Mensajes por campo y el botón deshabilitado

El mensaje pertenece al campo, no al formulario. Colócalo junto al control que lo origina, escríbelo en términos de qué hacer y no de qué está mal, y no dependas del color para transmitirlo: hay usuarios que no lo distinguen y otros que escuchan la pantalla en lugar de verla.

VStack(alignment: .leading, spacing: 4) {
    TextField("Correo", text: $formulario.correo)
        .focused($campoActivo, equals: .correo)
    if debeMostrar(.correo), let error = formulario.errorCorreo {
        Text(error.rawValue)
            .font(.footnote)
            .foregroundStyle(.red)
            .accessibilityLabel("Error en correo. \(error.rawValue)")
    }
}

Sobre el botón: deshabilitarlo mientras el formulario no sea válido parece una cortesía y con frecuencia es un callejón sin salida. Un control atenuado no explica por qué lo está, y el usuario que rellenó todo menos un campo escondido bajo el teclado se queda mirando un botón muerto. La alternativa —botón siempre activo que, al pulsarse, madura todos los campos, muestra los errores y lleva el foco al primero defectuoso— informa en lugar de bloquear.

Comprobaciones que necesitan tiempo

Algunas reglas no se pueden decidir localmente: si un nombre de usuario está libre, si un cupón sigue vigente, si un código postal existe. Esas comprobaciones tienen latencia y pueden fallar, así que no caben en una propiedad calculada: necesitan su propio estado con un caso para el intervalo en que aún no se sabe la respuesta.

enum Disponibilidad { case sinComprobar, comprobando, libre, ocupado, error }

@State private var disponibilidad: Disponibilidad = .sinComprobar

.task(id: formulario.usuario) {
    guard formulario.usuario.count >= 3 else {
        disponibilidad = .sinComprobar; return
    }
    disponibilidad = .comprobando
    do {
        try await Task.sleep(for: .milliseconds(400))
        disponibilidad = try await servicio.estaLibre(formulario.usuario)
            ? .libre : .ocupado
    } catch is CancellationError {
        // Otra pulsación llegó antes: no toques el estado.
    } catch {
        disponibilidad = .error
    }
}

El modificador task(id:) cancela la tarea anterior cuando cambia el identificador, de modo que la espera inicial actúa como retardo y el resto de pulsaciones descartan la consulta en vuelo sin escribir un temporizador a mano. La rama de cancelación debe quedarse callada: escribir en ella un estado de error convertiría el hecho normal de seguir escribiendo en un fallo visible.