Por qué los formularios son estado complejo

Pocas piezas de interfaz parecen tan inofensivas como un formulario: unos campos, un boton y la promesa de que, al pulsarlo, algo se guardara. Esa inocencia es una trampa. Detras de cada campo no hay un dato sino cinco preguntas simultaneas —que vale ahora, si ese valor es valido, si el usuario ya lo toco, si lo ha cambiado respecto al inicial y en que punto del envio nos encontramos— y ninguna de ellas se deduce de las demas. Un formulario no es una bolsa de valores: es el producto cartesiano de varios espacios de estado que conviven sin fundirse. Este nivel entero trata de tomarse esa complejidad en serio, y arranca aqui, nombrando las dimensiones que casi todo el mundo confunde y explicando por que confundirlas es la raiz de la mayoria de los bugs de formulario que has sufrido.

Las cinco dimensiones que conviven

El modelo mental con el que casi todos empezamos es aritmetico: si un formulario tiene tres campos, tendra tres piezas de estado. Basta observar un formulario real en uso durante diez segundos para ver que la cuenta no cuadra. El usuario escribe, borra, salta de campo sin rellenarlo, corrige un error que le acaba de aparecer y, al pulsar enviar, se topa con que el servidor rechaza justo el correo que a su juicio era impecable. Cada una de esas escenas activa una dimension distinta del estado, y esas dimensiones no viven en el mismo eje.

La primera es la de los valores: lo que hay ahora mismo en cada campo. Es la unica que el modelo ingenuo reconoce, y por eso la unica que la mayoria modela bien. La segunda es la validez: si cada valor satisface sus reglas y, en caso contrario, con que mensaje. La validez no es un valor mas, es un juicio sobre el valor, y un mismo valor puede ser valido hoy e invalido cuando cambie la regla.

La tercera dimension es la memoria de la interaccion, que a su vez se desdobla: touched recuerda si el usuario llego a enfocar y abandonar un campo, y dirty recuerda si su valor difiere del inicial. La cuarta es el estado del envio: si el formulario esta ocioso, enviandose, si termino con exito o con fallo, y cuantas veces se ha intentado. La quinta son los errores del servidor, que llegan tarde, no los predice ninguna regla local y hay que fundir con los errores de validacion sin confundirlos.

La ortogonalidad: por qué ninguna se deriva de otra

Dos dimensiones son ortogonales cuando saber el valor de una no te dice nada sobre la otra. Y ese es exactamente el caso aqui. Un campo puede estar valido y sucio y sin tocar —lo rellenaste por codigo—, o invalido y sin tocar —el usuario aun no ha llegado a el—, o valido pero con error del servidor —tu regla local lo aprobo y el backend lo rechazo—. Ninguna combinacion es absurda; todas ocurren. Por eso no puedes calcular touched a partir del valor, ni la validez a partir de dirty, ni el error del servidor a partir de nada que tengas en el cliente.

Merece la pena verlo desplegado, porque el modelo ingenuo colapsa justamente cuando estas combinaciones se cruzan. Cada fila de abajo es un estado legitimo que tu formulario tendra que representar y pintar de forma distinta, y ninguna se deduce de las otras:

valido   + sucio    + sin tocar    -> lo rellenaste por codigo o autocompletado
invalido + limpio   + sin tocar    -> el usuario aun no ha llegado a ese campo
valido   + sucio    + tocado       -> lo edito, lo abandono y quedo bien
valido   + limpio   + tocado       -> entro, salio y no cambio nada
valido en local     + error remoto -> tu regla lo aprobo, el servidor lo nego

Cinco dimensiones con dos o mas valores cada una generan un espacio de estados que crece de forma multiplicativa, no aditiva. Ese es el motivo profundo de que el modelo ingenuo —un useState por campo— no escale: no captura el espacio, solo una de sus proyecciones, la de los valores, y deja las otras cuatro dimensiones a merced de banderas sueltas que hay que sincronizar a mano.

De aqui sale la distincion mas importante de la leccion: dentro de un formulario hay estado fuente y estado derivado. Los valores, el touched, el contador de envios y los errores del servidor son fuente: nadie los calcula, entran desde fuera —del teclado, del foco, de la red—. En cambio los errores de validacion, el isDirty y el isValid son derivados: son una funcion pura del estado fuente. Almacenar un derivado como si fuera fuente es el pecado original del formulario ingenuo.

// El enfoque ingenuo: un useState por dato... y por cada metadato
const [email, setEmail] = useState("");
const [emailError, setEmailError] = useState<string | null>(null); // DERIVADO guardado como fuente
const [emailTouched, setEmailTouched] = useState(false);
const [emailDirty, setEmailDirty] = useState(false);               // DERIVADO guardado como fuente
// ...multiplica esto por cada campo, y suma isSubmitting, submitError, submitCount

El problema no es solo la verbosidad de cuatro useState por campo. Es que emailError y emailDirty son derivados y estan guardados como si fueran fuente, asi que ahora existen dos copias de la misma verdad: el valor real y su juicio congelado. En cuanto una se actualiza sin la otra —cambias email pero olvidas recomputar emailError— el formulario entra en un estado imposible: dice que el correo es invalido mientras muestra uno perfectamente valido. Ese desfase, y no la falta de librerias, es la causa profunda de los bugs de formulario.

Merece la pena ver el desfase desplegado en el tiempo, porque no es un fallo puntual sino una condicion de carrera latente. En el instante cero el correo esta vacio y emailError dice “requerido”; el usuario teclea una direccion valida y actualizas email, pero el manejador que recomputa emailError corre por otra rama, o mas tarde, o no corre. Durante esos milisegundos el formulario afirma dos cosas incompatibles a la vez, y si el usuario pulsa enviar justo entonces, rechazas un dato correcto. Nada de esto ocurre si el error no se almacena: al no existir la segunda copia, no hay nada que pueda desincronizarse.

La cura tiene nombre y es un principio de diseño, no un truco: hacer que los estados ilegales sean irrepresentables. Si el error no es un dato que guardas sino una funcion que calculas de los valores, el estado “valor valido con error de requerido” simplemente no cabe en tu modelo, igual que un statechart no puede estar en dos estados a la vez. El formulario robusto no es el que corrige a tiempo sus desfases, sino el que esta construido de modo que no puedan existir.

Queda una fuente silenciosa que conviene nombrar: los valores iniciales. El dirty no compara contra la nada, sino contra un punto de partida —los datos que llegaron del servidor al abrir el formulario—, y ese punto de partida es estado que hay que guardar aparte de los valores actuales. De el dependen dos gestos cotidianos: saber si hay cambios sin guardar y poder reiniciar el formulario a su estado original. Ignorarlo lleva al bug de un formulario que se cree sucio nada mas cargar, o que al reiniciarse vuelve a un vacio que nunca fue su verdadero inicio.

flowchart TD
V[valores fuente] --> E[errores derivados]
V --> D[dirty derivado]
T[touched fuente] --> UI[que mostrar y cuando]
E --> UI
S[maquina de envio] --> UI
R[errores del servidor] --> UI
style V fill:#89b4fa,color:#11111b
style T fill:#89b4fa,color:#11111b
style S fill:#cba6f7,color:#11111b
style R fill:#cba6f7,color:#11111b
style E fill:#a6e3a1,color:#11111b
style D fill:#a6e3a1,color:#11111b
style UI fill:#f9e2af,color:#11111b

El formulario como máquina de estado

Si observas la quinta dimension con atencion, veras que no es un puñado de banderas sueltas sino una maquina de estado honesta: se parte de ocioso, un envio lleva a enviando, y de ahi solo se puede salir a exito o a fallo, nunca a los dos a la vez. Es la misma disciplina de estados que estudiaste en el nivel de statecharts, aplicada ahora al ciclo de vida de un envio. Y el formulario completo es el producto de esa maquina por el espacio de los valores y por el de la validacion: tres subsistemas que evolucionan a la vez y que solo juntos describen “en que estado esta el formulario”.

Verlo asi tiene una consecuencia inmediata y liberadora. Una libreria de formularios no es una comodidad cosmetica que te ahorra teclear value y onChange: es un gestor de estado especializado que se encarga de las cuatro fuentes, computa por ti todos los derivados y —esto sera clave en la leccion cuatro— lo hace minimizando los re-render. Cuando en las proximas lecciones aparezcan Zod, React Hook Form o TanStack Form, no los leas como herramientas nuevas, sino como distintas respuestas a la pregunta que acabamos de plantear: como domar cinco dimensiones ortogonales sin crear estados imposibles.

Ese marco ordena el nivel entero. La leccion dos decide donde vive cada valor —en React o en el DOM— y mide el coste de esa eleccion. La tres declara la validez como un contrato del que los errores caen por gravedad, sin almacenarse. La cuatro presenta a las dos librerias que hacen de gestor de estado especializado. Y la cinco lleva el formulario hasta su frontera mas dificil, el envio, donde la maquina asincrona negocia con un servidor que puede decir que no. Todo el nivel es, en el fondo, este mismo diagrama de fuentes y derivados visto a distintas escalas.