Hola Habr! Le presento la traducción del artículo "Las entradas de formulario controladas y no controladas en React no tienen que ser complicadas" por Gosha Arinich.Es posible que haya visto muchos artículos que dicen, "no debe usar" setState ", mientras que los documentos afirman que" los árbitros son malos ". Todo esto es muy contradictorio. A veces, es difícil descubrir cómo hacer las cosas bien, y cuáles son los criterios para elegir entre estos métodos.Entonces, ¿cómo se hacen los formularios? Después de todo, los formularios son fundamentales para muchas aplicaciones web. Y, sin embargo, el procesamiento de formularios en React es la piedra angular, ¿no?Sin embargo, no lo es tan difícil Déjame mostrarte las diferencias entre estos enfoques, así como cuándo debes usar cada uno de ellos.Componentes no gestionados
Los componentes no administrados son como los formularios HTML normales:class Form extends Component {
render() {
return (
<div>
<input type="text" />
</div>
);
}
}
Recuerdan todo lo que escribiste. Entonces puede obtener su valor usando ref. Por ejemplo, en el controlador onClick:
class Form extends Component {
handleSubmitClick = () => {
const name = this._name.value;
}
render() {
return (
<div>
<input type="text" ref={input => this._name = input} />
<button onClick={this.handleSubmitClick}>Sign up</button>
</div>
);
}
}
En otras palabras, debe "extraer" los valores del campo cuando lo necesite. Esto se puede hacer al enviar el formulario.Esta es la forma más fácil de implementar formularios. Por supuesto, debe haber una buena razón para usarlo, a saber: las formas más simples, ya sea durante el estudio de React.Sin embargo, este método no es tan flexible, así que echemos un vistazo a los componentes administrados.Componentes gestionados:
El componente administrado acepta su valor actual como accesorios, así como una devolución de llamada para cambiar este valor. Puede decir que esta es una forma más "reactiva" de controlar el componente, sin embargo, esto no significa que siempre deba usar este método.
<input value={someValue} onChange={handleChange} />
Todo esto es muy bueno, pero el valor del formulario de entrada debe existir en algún estado. Por lo general, un componente que representa un formulario de entrada (es decir, un formulario) los guarda en su estado:
class Form extends Component {
constructor() {
super();
this.state = {
name: '',
};
}
handleNameChange = (event) => {
this.setState({ name: event.target.value });
};
render() {
return (
<div>
<input
type="text"
value={this.state.name}
onChange={this.handleNameChange}
/>
</div>
);
}
}
(Por supuesto, puede estar en el estado de otro componente o incluso en una tienda de estado separada, por ejemplo, Redux).Cada vez que ingresa un nuevo carácter, se llama a handleNameChange. Toma el nuevo valor del formulario de entrada y lo escribe en estado.
- Todo comienza con una línea vacía - '';
- Ingresa la letra 'a' y handleNameChange la obtiene y llama a setState. Luego, el formulario de entrada se representa nuevamente con el valor 'a';
- Ingresa la letra 'b' y handleNameChange obtiene el valor 'ab' y lo establece en estado. Se representa el formulario de entrada Opet, pero ahora con el valor 'ab'.
Esta secuencia parece "empujar" los cambios en el formulario, por lo que el componente siempre tiene el valor actual de los datos de entrada, sin requerir una solicitud de actualización explícita.Esto significa que sus datos (estado) e interfaz de usuario (formulario de entrada) siempre están sincronizados. El estado le da valor al formulario, mientras que el formulario cambia el valor del estado actual.También significa que los formularios pueden responder inmediatamente a los cambios, lo que a su vez es necesario para:- retroalimentación rápida, como validación;
- deshabilite un botón específico hasta que todos los campos del formulario sean válidos;
- permitiendo el procesamiento de ciertos formatos de campo de entrada, como números de tarjetas de crédito.
Pero si no lo necesita y cree que los componentes no administrados son mucho más simples, utilícelos.¿Qué hace que un componente sea "manejable"?
Por supuesto, hay otros elementos de formulario, como: casillas de verificación, radio, textarea y select.Un componente se vuelve manejable cuando establece su valor de uso de accesorios. Eso es todo.Sin embargo, cada uno de los elementos del formulario tiene diferentes formas de establecer el valor, así que aquí hay una pequeña tabla para una comprensión general:recomendaciones
Los componentes administrados y no administrados tienen ventajas y desventajas. Evaluar una situación específica y elegir un enfoque: si esto funciona para usted, ¿por qué no aprovecharlo?Si su formulario es increíblemente simple en términos de interacción con la interfaz de usuario, los componentes no administrados son perfectos para usted. No tiene que escuchar lo que varios artículos dicen que es malo.
Además, elegir un tipo de componente no es una decisión que se tome de una vez por todas: siempre puede reemplazar componentes no administrados por otros administrados. La transición de uno a otro no es tan difícil.