يجب إزالة الغموض عن رد الفعل

أثناء التطوير في React ، هل تساءلت يومًا عن متى ولماذا يتم تشغيل طريقة العرض () للمكون؟ أو متى يجب استخدام طرق دورة حياة أقل وضوحًا يجب أن يكون ComponentUpdate ()؟

إذا كان الجواب نعم ، فقد يواجه تطبيقك مشكلات في الأداء. اقرأ جيدًا وستتمكن من إصلاحها بسهولة.

يعود الأمر كله إلى كيفية عمل React تحت الغطاء. إن الوعد الكبير لـ React هو أنها سريعة جدًا في عرض العناصر على الصفحة.

للقيام بذلك ، تحتفظ React بنسختين من DOM:

  • إصدار DOM المعروض حاليًا
  • سيتم عرض الإصدار التالي من DOM

يقوم بمقارنة الاثنين وتحديث DOM المعروض بالأجزاء التي تغيرت فقط. هذه العملية تسمى تسوية الشجرة. جذر الشجرة التي تم تقييمها للتسوية هو مكون تم تغيير الخاصيات.

عظيم. الآن سواء كنت تخطط لذلك أم لا ، فإن تطبيق الويب الخاص بك يتبع تقسيم مكونات الحاوية / العرض إلى حد ما. انظر هنا وهنا للتعريفات. هذا يعني أن كل عرض معقد في تطبيقك يتكون من مكون حاوية يحمل المنطق ويحتوي على الكثير من مكونات العرض فقط كأطفال.

هذا نمط جيد جدا إذا نظرت عن كثب ، فهذا يعني أن أي تفاعل للمستخدم في العرض سيؤثر على الحاوية نفسها وسيؤدي إلى عرض لها وجميع العناصر الفرعية الخاصة بها. لنفترض أن لديك قائمة بالعناصر مع عرض خيالي للنص والصورة وزر "إضافة إلى المفضلة" بنجمة صفراء اللون. يمكن أن يكون النموذج الأدنى لعنصر القائمة هو:

product = { imageUrl: '...', title: '...', isFavourite: false }

يمكن أن تأتي قائمة المفضلة من مصدر آخر للبيانات. بغض النظر ، من المحتمل أن تبدو مؤسسة المكونات الخاصة بك على النحو التالي:

يتم استدعاء المعالج عند نقر المستخدم ويحفظ جانب خادم المعلومات (أو يستمر في متجر أو أي شيء آخر) ويقوم بإجراء تغيير في this.props.elements.

تؤدي نتيجة النقرة الواحدة إلى تشغيل عرض الحاوية وجميع الصفوف في القائمة لتحديث مربع اختيار واحد فقط.

هذا هو المكان الذي يلعب فيه shouldComponentUpdate (). يمكنك إخبار React بعدم عرض الصفوف التي لا تحتاج إلى استخدام هذه الطريقة.

class ListItem extends Component { shouldComponentUpdate(nextProps, nextState) { return nextProps.isFavourite != this.props.isFavourite; } ... }

إليك حالة ملموسة: في مشروع تطبيق سوق ، كان لدينا عرض لإدارة المنتجات للبائعين. تحتوي القائمة على نمط "تحميل المزيد أثناء قيام المستخدم بالتمرير لأسفل" وإجراءات عنصر مضمنة "إظهار / إخفاء" لتعيين رؤية كل منتج. كان كل شيء على ما يرام عندما كان البائعون يديرون <100 منتج في لوحة القيادة الخاصة بهم. ثم بدأ بائع معين في الدخول والإعلان عن أكثر من 300 منتج ...

كان هناك تأخير يبلغ 600 مللي ثانية قبل تحديث واجهة المستخدم بعد أن نقر المستخدم على أيقونة "تمكين / تعطيل". كان الفارق مرئيًا بالتأكيد من قبل المستخدم النهائي. باستخدام أداة تعريف Chrome ، رأينا أن الأمر استغرق حوالي 2 مللي ثانية من React لتصيير صف واحد. مرة 300 ... حصلنا على 600 مللي ثانية. أضفنا عمليات التحقق shouldComponentUpdate () للظروف المناسبة. وقت العرض بعد نقر المستخدم أقل من 10 مللي ثانية ...

لقد أعددت مشروعًا صغيرًا يسمح بإعادة إنتاج هذه الحالة هنا. قم بتشغيله واقرأ تعليقات الكود لترى أن السحر يحدث.

تحذير لمستخدمي Redux

قد تحدث المشكلة الموضحة أعلاه في كثير من الأحيان إذا كنت تستخدم Redux وأعد التحديد (أو مكتبات خطوط عمل مماثلة "قائمة على المتجر").

باستخدام Redux وإعادة التحديد ، يمكنك دفع الإجراءات إلى المتجر وتوصيل المستمعين لتخزين التغييرات ، ويعرف أيضًا باسم المحددات. تتوفر المحددات عالميًا في التطبيق وفي تطبيق كبير ، من السهل جدًا تعيين العديد من المكونات لنفس المحددات. قد تؤدي التغييرات التي يتم إجراؤها على المتجر إلى حدوث تغييرات في الدعائم وبالتالي تصبح غير ذات صلة تمامًا ببعض المكونات.

إليك النصيحة المحيرة: لا تستخدم shouldComponentUpdate () لمنع عمليات العرض في مثل هذه الحالات. يجب أن ينظر المنطق الداخلي shouldComponentUpdate فقط في ما يتعلق بالمكون. لا ينبغي أبدًا توقع السياقات التي يستخدم فيها المكون. والسبب هو أن التعليمات البرمجية الخاصة بك ستصبح سريعًا غير قابلة للاستمرار.

إذا كان لديك هذا النوع من المشاكل ، فهذا يعني أن بنية متجرك خاطئة أو أن المحددات ليست محددة بما يكفي. تحتاج إلى الوصول إلى جولة نمذجة جديدة.

أوصي بهذه الإرشادات المعيارية الرائعة. إنها تعزز تغليف المتجر لكل حاوية عالية المستوى مع منطقة عالمية لهياكل البيانات الرئيسية التي تمتد عبر التطبيق بأكمله. هذه طريقة آمنة جدًا لتجنب أخطاء تصميم المتجر.

شكرا للقراءة! إذا أعجبك ، يرجى الضغط على زر التصفيق أدناه. يساعد الآخرين على رؤية القصة.