Controlado vs no controlado: React o el DOM

Cada valor que un usuario teclea tiene que descansar en algun lugar entre pulsacion y pulsacion, y en React solo existen dos lugares posibles: dentro del estado del componente o dentro del propio nodo del DOM. Esa bifurcacion —tan pequeña que cabe en la eleccion entre escribir value o defaultValue— divide en dos el universo entero de los formularios. En un campo controlado, React es la unica fuente de verdad y cada tecla viaja hasta el estado y vuelve; en un campo no controlado, el DOM guarda el valor y React lo ignora hasta que alguien lo pide. La decision parece de fontaneria, pero determina si validas en vivo, si puedes enmascarar la entrada, y cuantos re-render pagas por cada letra. Esta leccion mide ese coste sin metaforas, porque es la clave que explica por que las librerias de formularios mas rapidas huyen del modelo controlado ingenuo.

Dónde vive el valor

Un campo controlado entrega su valor a React y renuncia a tener memoria propia. Le pasas la prop value tomada del estado y un onChange que, en cada pulsacion, actualiza ese estado. El elemento del DOM ya no decide lo que muestra: lo que muestra es siempre un reflejo del estado de React. La fuente de verdad es una y esta en React, con toda la comodidad y todo el coste que eso implica.

// Controlado: el valor vive en React y el DOM solo lo refleja
function CampoControlado() {
  const [valor, setValor] = useState("");
  return (
    <input
      value={valor}
      onChange={(e) => setValor(e.target.value)}
    />
  );
}

Un campo no controlado hace lo contrario: deja que el valor viva en el DOM, como ha vivido siempre en HTML, y React se limita a plantar un valor inicial con defaultValue y a desentenderse. React no se entera de cada tecla; el valor solo se lee cuando hace falta, ya sea con una ref que apunta al nodo, ya sea a traves del objeto FormData que el navegador construye al enviar el formulario.

// No controlado: el valor vive en el DOM y se lee de forma perezosa
function CampoNoControlado() {
  const ref = useRef<HTMLInputElement>(null);
  const leer = () => console.log(ref.current?.value);
  return <input defaultValue="" ref={ref} onBlur={leer} />;
}

La diferencia de fondo no es sintactica sino de quien es la fuente de verdad. En el controlado, React manda y el DOM obedece en cada instante; en el no controlado, el DOM guarda la verdad y React solo la consulta cuando le interesa. Todo lo demas —la validacion, el formateo, el rendimiento— son consecuencias de esta unica decision.

Conviene notar que la eleccion no es de todo o nada a nivel de formulario, sino campo por campo. Un mismo formulario puede tener un campo controlado para el importe que se formatea al vuelo y diez campos no controlados para el resto, que solo se leen al enviar. Pensar la fuente de verdad como una propiedad de cada campo, y no como una religion del formulario entero, es el primer signo de madurez en este terreno.

El coste de re-render, medido sin metáforas

Aqui esta el nudo de la leccion. En un campo controlado, cada pulsacion dispara un setState, y cada setState dispara un render del componente que posee ese estado. Si —como suele ocurrir— ese estado vive en el componente raiz del formulario, teclear una sola letra vuelve a renderizar el formulario entero: los diez campos, sus etiquetas, sus mensajes de error, todo. El usuario escribe “hola” y React ha reconciliado el formulario cuatro veces completas.

flowchart LR
K[pulsacion de tecla] --> O[onChange]
O --> SS[setState en la raiz]
SS --> RR[render de todo el formulario]
RR --> DOM[reconciliacion de todos los campos]
style K fill:#89b4fa,color:#11111b
style SS fill:#f38ba8,color:#11111b
style RR fill:#f38ba8,color:#11111b
style DOM fill:#f9e2af,color:#11111b

Para un formulario de tres campos esto es invisible: un render de mas cada pocos milisegundos no lo nota nadie. El coste se vuelve real cuando el formulario es grande, cuando cada campo es un componente pesado —un selector con busqueda, un editor enriquecido— o cuando hay logica cara en el render. Entonces cada tecla arrastra un arbol entero y la escritura empieza a notarse con retardo. La leccion no es “el controlado es lento”, sino “el controlado paga un render por tecla, y ese precio se dispara con el tamaño”.

El campo no controlado no paga ese precio porque no hay setState por tecla: el DOM absorbe la escritura a su velocidad nativa y React ni se entera. La contrapartida es que React no conoce el valor hasta que lo pide, asi que pierdes la reaccion instantanea al contenido. De ese intercambio salen las dos estrategias que veras en la practica: aislar el estado controlado en el componente mas pequeño posible para que el render por tecla afecte a poco, o usar el modelo no controlado y leer los valores solo cuando de verdad importan.

Podria pensarse que las mejoras del propio React —el agrupado de actualizaciones, el renderizado concurrente— borran este coste, pero no lo hacen: reducen los renders redundantes y permiten interrumpirlos, no eliminan el trabajo de reconciliar un arbol grande en cada tecla cuando el estado vive arriba. El agrupado ayuda cuando varias actualizaciones caen juntas; aqui cada pulsacion es una unica actualizacion, y esa se paga entera. La arquitectura del formulario sigue mandando sobre el coste por encima de cualquier optimizacion del framework.

De ahi que la unica forma honesta de decidir sea medir, no intuir. Un profiler de renders te dira, para tu formulario concreto y tus componentes concretos, si el modelo controlado desde la raiz cuesta microsegundos imperceptibles o milisegundos que el usuario nota al escribir rapido. La regla practica es no reescribir por sospecha: mide primero, localiza si el problema era la altura del estado o de verdad el modelo, y solo entonces cambia lo justo.

Qué gana cada enfoque y hacia dónde va React

Cada modelo compra una cosa distinta. El controlado compra reactividad: como React conoce el valor en cada instante, puedes validar en vivo, habilitar o deshabilitar el boton segun el contenido, enmascarar y formatear la entrada mientras se teclea —un telefono, un importe—, o mostrar y ocultar campos en funcion de lo que ya se escribio. Todo eso exige que React sepa el valor ahora, no al enviar. El no controlado compra rendimiento y sencillez: menos codigo, cero renders por tecla y una lectura perezosa que encaja de maravilla cuando el formulario solo necesita sus valores al final.

Hay ademas un campo que no admite eleccion: el de tipo file. Por seguridad, el navegador no deja que ningun script fije el valor de un selector de archivos —seria abrir la puerta a subir ficheros sin que el usuario los elija—, asi que un campo de archivo es siempre no controlado y solo se lee, nunca se escribe. Es el recordatorio mas claro de que la eleccion entre controlar y no controlar no siempre es tuya: a veces la plataforma ya decidio, y tu modelo mental debe acomodarse a ella en lugar de pelearse.

Los controles que no son texto —casillas, radios, selectores— tienen su propia version del dilema. Un checkbox controlado lee su checked del estado en vez de su value, y un grupo de radios comparte un unico valor controlado; en su version no controlada, el DOM guarda que hay marcado y tu lo lees al final. El principio es identico —donde vive la verdad—, pero conviene saber que cada tipo de control lo expresa con una prop distinta, y que confundirlas es una fuente habitual de campos que parecen no responder al usuario.

Esta tension explica, por adelantado, la leccion cuatro. React Hook Form es rapido precisamente porque adopta el modelo no controlado como base —registra los campos con ref en lugar de controlarlos— y solo re-renderiza los componentes que se suscriben a un campo concreto. No es magia: es la eleccion de este capitulo llevada a libreria. Y el propio React empuja en la misma direccion: las Server Actions y el patron de FormData en el envio recuperan la vieja virtud del formulario no controlado, dejando que el navegador recoja los valores y reservando el estado de React para lo que de verdad necesita ser reactivo.

Hay ademas un matiz de honestidad intelectual que conviene no perder. La reactividad del campo controlado no exige que el estado viva arriba: exige que exista en React, en el nivel mas bajo posible. Por eso la falsa dicotomia “controlado igual a lento, no controlado igual a rapido” se disuelve en cuanto separas dos preguntas que suelen ir juntas por pereza —donde vive el valor y en que altura del arbol vive—. La primera decide que puedes hacer con el; la segunda decide cuanto cuesta. Confundirlas es lo que lleva a reescribir formularios enteros a no controlado cuando bastaba con mover un useState un piso mas abajo.