مرحبا يا هابر! أقدم لكم ترجمة المقال "لا يجب أن تكون مدخلات النموذج الخاضعة للرقابة وغير الخاضعة للرقابة في React معقدة" بقلم Gosha Arinich.ربما تكون قد رأيت العديد من المقالات التي تقول ، "لا يجب استخدام" setState "، بينما تدعي المستندات أن" refs bad ". هذا كله متناقض للغاية. في بعض الأحيان يكون من الصعب معرفة كيفية تصحيح الأمور ، وما هي معايير الاختيار من بين هذه الأساليب.إذن كيف تصنع النماذج؟ بعد كل شيء ، تعد النماذج مركزية للعديد من تطبيقات الويب. ومع ذلك ، فإن معالجة النماذج في React هي حجر الزاوية ، أليس كذلك؟ومع ذلك ، فهي ليست صعب للغاية دعني أريك الاختلافات بين هذه الأساليب ، وكذلك متى يجب عليك استخدام كل منها.مكونات غير مُدارة
المكونات غير المُدارة تشبه نماذج HTML العادية:class Form extends Component {
render() {
return (
<div>
<input type="text" />
</div>
);
}
}
يتذكرون كل ما كتبته. ثم يمكنك الحصول على قيمتها باستخدام المرجع. على سبيل المثال ، في معالج 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>
);
}
}
وبعبارة أخرى ، تحتاج إلى "سحب" القيم خارج الحقل عندما تحتاج إليها. يمكن القيام بذلك عند تقديم النموذج.هذه هي أسهل طريقة لتنفيذ النماذج. بالطبع ، يجب أن يكون هناك سبب وجيه لاستخدامه ، وهو: أبسط الأشكال ، إما أثناء دراسة تفاعل.ومع ذلك ، هذه الطريقة ليست مرنة للغاية ، لذلك دعونا نلقي نظرة أفضل على المكونات المدارة.المكونات المدارة:
يقبل المكون المُدار قيمته الحالية كدعائم ، بالإضافة إلى رد اتصال لتغيير هذه القيمة. يمكنك القول أن هذه طريقة أكثر "تفاعلية" للتحكم في المكون ، ولكن هذا لا يعني أنه يجب عليك دائمًا استخدام هذه الطريقة.
<input value={someValue} onChange={handleChange} />
كل هذا جيد جدًا ، ولكن يجب أن توجد قيمة نموذج الإدخال في بعض الحالات. عادة ، يقوم المكون الذي يعرض نموذج إدخال (أي نموذج) بحفظها في حالتها:
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>
);
}
}
(بالطبع ، يمكن أن يكون في حالة مكون آخر أو حتى في متجر دولة منفصل ، على سبيل المثال ، Redux).في كل مرة تقوم فيها بإدخال حرف جديد ، يتم استدعاء handleNameChange. يأخذ القيمة الجديدة لنموذج الإدخال ويكتبها للدولة.
- يبدأ كل شيء بخط فارغ - ""؛
- يمكنك إدخال الحرف "a" و handleNameChange يحصل عليه والمكالمات setState. ثم يتم تقديم نموذج الإدخال مرة أخرى بالقيمة 'a'؛
- أدخل الحرف "b" و handleNameChange تحصل على القيمة "ab" وتضبطها على الحالة. يتم تقديم نموذج إدخال Opet ، ولكن الآن مع القيمة 'ab'.
يبدو أن هذا الدفق "يدفع" التغييرات في النموذج ، وهذا هو السبب في أن المكون لديه دائمًا القيمة الحالية لبيانات الإدخال ، دون الحاجة إلى طلب تحديث صريح.وهذا يعني أن بياناتك (الحالة) وواجهة المستخدم (نموذج الإدخال) متزامنة دائمًا. تعطي State قيمة للنموذج ، بينما يغير النموذج قيمة الحالة الحالية.وهذا يعني أيضًا أن النماذج يمكن أن تستجيب على الفور للتغيرات ، والتي بدورها ضرورية من أجل:- ردود فعل سريعة ، مثل التحقق من الصحة ؛
- تعطيل زر معين حتى تكون جميع حقول النموذج صالحة ؛
- تمكين معالجة بعض تنسيقات حقول الإدخال ، مثل أرقام بطاقات الائتمان.
ولكن إذا لم تكن بحاجة إليها وكنت تعتقد أن المكونات غير المُدارة أبسط من ذلك بكثير ، فاستخدمها.ما الذي يجعل المكون "قابلاً للإدارة"؟
بالطبع ، هناك عناصر نموذجية أخرى ، مثل: مربعات الاختيار والراديو و textarea وحدد.يصبح المكون قابلاً للإدارة عند تعيين دعائم استخدام القيمة الخاصة به. هذا كل شئ.ومع ذلك ، لكل عنصر من عناصر النموذج طرقًا مختلفة لتحديد القيمة ، لذا إليك جدول صغير للفهم العام:الموجودات
لكل من المكونات المُدارة وغير المُدارة مزايا وعيوب. قم بتقييم موقف معين واختيار نهج - إذا كان هذا مناسبًا لك ، فلماذا لا تستفيد منه؟إذا كان نموذجك بسيطًا بشكل لا يصدق من حيث التفاعل مع واجهة المستخدم ، فإن المكونات غير المُدارة مثالية لك. ليس عليك الاستماع إلى ما تقوله مختلف المقالات بأنها سيئة.
بالإضافة إلى ذلك ، لا يعد اختيار نوع المكون قرارًا يتم اتخاذه نهائيًا: يمكنك دائمًا استبدال المكونات غير المُدارة بأخرى مُدارة. الانتقال من واحد إلى آخر ليس بالأمر الصعب.