التلاعب المباشر في DOM
هذا النوع من الأخطاء شائع بشكل خاص بين المطورين الذين ينتقلون للتو من jQuery.
هل كتبت كود مثل هذا؟
ما هي المشكلة؟
في React ، يجب أن نتجنب تفاعلات DOM المباشرة. بدلاً من الحصول على مرجع إلى عقدة DOM وإضافة فئة إليها مباشرةً ، يجب عليك تغيير الحالة في المكون نفسه ، بناءً على الفئة التي ستتم إضافتها إلى العنصر.
ما هو السوء في التلاعب المباشر بعناصر DOM؟
أي تطبيق ويب يتعلق حقًا بالحالة وإدارتها. هناك علاقة مباشرة بين تعقيد البرنامج والحالة التي تصفه. إذا كان تطبيقك يخلط بين حالات DOM و React ، فإن تعقيد الحفاظ عليه سينمو بسرعة كبيرة.
حل ممكن
دعنا نلقي نظرة على كيفية استخدامنا لحالة React لتحديث سمة className في المكون الخاص بنا ، ونتيجة لذلك تخلصنا من document.querySelector. ممتاز!
لا تراقب الموارد
غالبًا ما يكتب Newbies قيد التطوير هذا الرمز عند العمل مع الأحداث. خذ ، على سبيل المثال ، مكون React بسيط يفعل ... شيئًا ما عندما يضغط المستخدم على مفتاح المسافة.
لاحظ كيف أضفنا مستمعًا للحدث ولكننا لم نهتم بإزالته في النهاية؟
هذا يمكن أن يؤدي إلى تسرب الذاكرة ومشاكل خفية في المستقبل. أفضل حل هو إزالة المشتركين قبل إزالة المكون الخاص بنا من DOM.
ألق نظرة على الحل أدناه:
رفض الاختبارات (أو عدم كفاية عددها)
إذا تم إعطائي دولارًا لكل مشروع نظرت فيه وكان الاختبار الوحيد هو الاختبار الافتراضي في تطبيق create-react-app ، فلن أكتب هذه المقالة. ولا بد أنه كان يحتسي ديكيري في مكان ما على الشاطئ.
ما الذي يميز الاختبار الذي يخيف Juns كثيرًا؟ أعتقد أن السبب يكمن في عدم تفاهة مكونات الاختبار ، خاصة إذا كانت تتطور باستمرار وتتزايد في التعقيد. غالبًا ما أرى المبرمجين المبتدئين يكتبون اختبارات الوحدة لبعض الوظائف البحتة المحددة ، لكنهم يفشلون عندما يحتاجون إلى كتابة اختبار تكامل لمكون كامل.
ربما البذرة تربكهم؟ أم أنهم يجدون صعوبة فيما يختبرونه وما لا؟
دعنا نلقي نظرة على المكون الذي كتبته للتو. هذا نموذج تسجيل دخول بسيط للغاية حيث يجب على المستخدم إدخال اسم المستخدم وكلمة المرور. عندما يؤكد الأخير المعلومات التي تم إدخالها ، نقوم بإجراء مكالمة API ، وإذا كانت الإجابة إيجابية ، فإننا نوجه العميل إلى صفحة أخرى.
إذن كيف تختبر هذا النموذج؟
أولاً ، دعنا نلقي نظرة على كيفية تفاعل المستخدم معها.
يقوم المستخدم بإدخال بياناته.
ينقر المستخدم على زر التأكيد.
يتم إعادة توجيه المستخدم إلى الصفحة "الرئيسية".
هذا كل ما نحتاج إلى اختباره.
أدناه كتبت إحدى حالات الاختبار لهذا المكون. هل يمكنك اقتراح أي سيناريوهات أخرى قد يكون من المفيد اختبارها؟
رأي أخصائي ممارسة Reksoft Frontend
لا يُنصح باستخدام المثال أعلاه مع الاختبار نظرًا للارتباط القوي بطبقة العرض وتفاصيل التنفيذ.
بالنسبة لطبقة العرض ، يمكنك اختيار أفتح ، من وجهة نظر التطوير ، بديل في شكل اختبارات بصرية من خلال لقطات ، وهذا لن يغطي جميع الاحتياجات ، لكنه سيغطي معظم المخاطر المرتبطة بالتصميم.
من خلال ربط الاختبارات بتفاصيل التنفيذ ، فإننا نحكم على أنفسنا بالحاجة إلى إعادة كتابتها باستمرار في حالة تغير هذا التنفيذ (لكن السلوك يظل كما هو) ، وبالتالي زيادة تكاليف التطوير. نتيجة لذلك ، تكون هذه الاختبارات بطيئة نوعًا ما لأنها تحاكي بيئة DOM حتى تعمل المكتبات.
تعني اختبارات التكامل الاختبارات التي تتحقق من سلوك مجموعة من الوحدات ذات الصلة ، ولكن هذا لا يعني على الإطلاق أنه يجب تضمين مكتبات الطرف الثالث في هذه الحزمة ، والتي ، على الرغم من أنها توفر واجهة برمجة تطبيقات مستقرة ، إلا أنها تتطلب محاكاة بيئة المتصفح ، مما يؤثر سلبًا على سرعة جميع عمليات التحقق ... بدلاً من هذه المكتبات ، عادةً ما يتم استخدام الكائنات الوهمية التي تحاكي سلوكها ، ولكنها غير مرتبطة بالبيئة.
إذا كنت لا تزال بحاجة إلى بعض الوسائل للتحقق من هذه المكتبات ، على سبيل المثال ، لتقليل مخاطر الانتقال إلى إصدارات جديدة ، فسيكون الحل عبارة عن مجموعة خاصة من الاختبارات ، تسمى عادةً اختبارات القبول. قبل كتابتها ، من المفيد تجميع مجموعة واضحة من الثوابت والشروط المسبقة والشروط اللاحقة التي يعتمد عليها تطبيقنا عند استخدام المكتبة. وإبرام العقود السلوكية المشكلة على شكل اختبارات. من المفيد تشغيل مكتبات حقيقية وكائنات وهمية من خلال هذه الاختبارات ، والتي تحاكي سلوك الأخير.
للتلخيص ، الاختبارات الجيدة هي تلك التي توفر تغطية كاملة للسلوكيات (السلوكيات ، وليس التطبيقات) ، وهي سهلة القراءة (يجب أن تقرأ الاختبارات أفضل من التعليمات البرمجية العادية) ، وتنفيذها بسرعة (الاختبارات البطيئة تؤثر سلبًا على الرغبة في إعادة البناء المتكررة) ، وأخيرًا ، تلك المرتبطة بالسلوك وليس التنفيذ.
Webpack سوء الفهم
عرف بعض المطورين المبتدئين الذين عملت معهم كيفية الاستخدام ، لكنهم لم يفهموا كيفية عمل Webpack. استخدموا فقط مع قاعدة الشفرة الرئيسية للمشروع واعتقدوا أن كل شيء آخر "يعمل فقط لأن". لم يتعمقوا في الأمر ، واكتشفوا بالضبط كيف يتم تحويل ودمج CSS و ES6 اللذين يكتبانهما في ما يستخدمه متصفح العميل في النهاية.
أوصي كل مطور React بأخذ الوقت الكافي لبناء مشروع معياري بسيط. بدلاً من الاعتماد على create-reaction-app و NextJS في كل مرة ، افهم كيف تعمل أدوات بناء JavaScript الحديثة معًا. سيؤدي ذلك إلى تحسين فهمك لعملك ، ونتيجة لذلك ، يجعلك مطورًا أكثر كفاءة ، خاصة عند حل مشكلات البناء.
أصلي:medium.com/frontend-digest/mistakes-junior-react-developers-make-c546b1af187d