Bonjour, Habr! Je vous présente la traduction de l'article "Les entrées de formulaire contrôlées et non contrôlées dans React ne doivent pas être compliquées" par Gosha Arinich.Vous avez peut-être vu de nombreux articles dire: "vous ne devriez pas utiliser" setState ", tandis que les documents affirment que" les références sont mauvaises ". Tout cela est très contradictoire. Parfois, il est difficile de comprendre comment faire les choses correctement, et quels sont les critères de choix entre ces méthodes.Alors, comment créer des formulaires? Après tout, les formulaires sont au cœur de nombreuses applications Web. Et pourtant, le traitement des formulaires dans React est la pierre angulaire, n'est-ce pas?Cependant, ce n'est pas si dur Permettez-moi de vous montrer les différences entre ces approches, ainsi que quand vous devez utiliser chacune d'entre elles.Composants non gérés
Les composants non gérés sont comme des formulaires HTML classiques:class Form extends Component {
render() {
return (
<div>
<input type="text" />
</div>
);
}
}
Ils se souviennent de tout ce que vous avez tapé. Ensuite, vous pouvez obtenir leur valeur en utilisant ref. Par exemple, dans le gestionnaire 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 d'autres termes, vous devez «extraire» les valeurs du champ lorsque vous en avez besoin. Cela peut être fait lors de la soumission du formulaire.Il s'agit de la manière la plus simple d'implémenter des formulaires. Bien sûr, il doit y avoir une bonne raison de l'utiliser, à savoir: les formes les plus simples, soit lors de l'étude de React.Cependant, cette méthode n'est pas si flexible, alors examinons mieux les composants gérés.Composants gérés:
Le composant géré accepte sa valeur actuelle comme accessoires, ainsi qu'un rappel pour modifier cette valeur. Vous pouvez dire que c'est une façon plus «réactive» de contrôler le composant, mais cela ne signifie pas que vous devez toujours utiliser cette méthode.
<input value={someValue} onChange={handleChange} />
Tout cela est très bien, mais la valeur du formulaire d'entrée doit exister dans un certain état. En règle générale, un composant qui rend un formulaire d'entrée (c'est-à-dire un formulaire) les enregistre dans son état:
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>
);
}
}
(Bien sûr, il peut être dans l'état d'un autre composant ou même dans un magasin d'état séparé, par exemple, Redux).Chaque fois que vous entrez un nouveau caractère, handleNameChange est appelé. Il prend la nouvelle valeur du formulaire d'entrée et l'écrit à l'état.
- Tout commence par une ligne vide - '';
- Vous entrez la lettre «a» et handleNameChange l'obtient et appelle setState. Ensuite, le formulaire d'entrée est rendu à nouveau avec la valeur «a»;
- Vous entrez la lettre «b» et handleNameChange obtient la valeur «ab» et la définit à l'état. Le formulaire d'entrée Opet est rendu, mais maintenant avec la valeur 'ab'.
Ce flux semble «pousser» les modifications dans le formulaire, c'est pourquoi le composant a toujours la valeur actuelle des données d'entrée, sans nécessiter de demande de mise à jour explicite.Cela signifie que vos données (état) et votre interface utilisateur (formulaire de saisie) sont toujours synchronisées. L'état donne de la valeur au formulaire, tandis que le formulaire modifie la valeur de l'état actuel.Cela signifie également que les formulaires peuvent répondre immédiatement aux changements, ce qui à son tour est nécessaire pour:- rétroaction rapide, comme la validation;
- désactiver un bouton spécifique jusqu'à ce que tous les champs du formulaire soient valides;
- permettant le traitement de certains formats de champs de saisie, par exemple les numéros de carte de crédit.
Mais si vous n'en avez pas besoin et que vous pensez que les composants non gérés sont beaucoup plus simples, utilisez-les.Qu'est-ce qui rend un composant «gérable»?
Bien sûr, il existe d'autres éléments de formulaire, tels que: cases à cocher, radio, zone de texte et sélectionnez.Un composant devient gérable lorsque vous définissez sa valeur utiliser des accessoires. C'est tout.Cependant, chacun des éléments du formulaire a différentes façons de définir la valeur, voici donc un petit tableau pour une compréhension générale:résultats
Les composants gérés et non gérés présentent des avantages et des inconvénients. Évaluez une situation spécifique et choisissez une approche - si cela fonctionne pour vous, alors pourquoi ne pas en profiter?Si votre formulaire est incroyablement simple en termes d'interaction avec l'interface utilisateur, les composants non gérés sont parfaits pour vous. Vous n'avez pas à écouter ce que divers articles disent de mauvais.
De plus, le choix d'un type de composant n'est pas une décision à prendre une fois pour toutes: vous pouvez toujours remplacer des composants non managés par des composants managés. La transition de l'un à l'autre n'est pas si difficile.