رد فعل البرنامج التعليمي الجزء 19: أساليب دورة حياة المكون

في جزء اليوم من ترجمة البرنامج التعليمي React ، سيتم تقديم نظرة عامة على أساليب دورة حياة المكون.



→ الجزء 1: نظرة عامة على الدورة ، وأسباب شعبية React ، ReactDOM و JSX
→ الجزء 2: المكونات الوظيفية
→ الجزء 3: ملفات المكونات ، هيكل المشروع
→ الجزء 4: مكونات الوالدين والطفل
→ الجزء 5: بدء العمل في تطبيق TODO ، أساسيات التصميم
→ الجزء 6: حول بعض ميزات الدورة ، JSX وجافا سكريبت
→ الجزء 7: الأنماط المضمنة
→ الجزء 8: مواصلة العمل على تطبيق TODO ، الإلمام بخصائص المكونات
→ الجزء 9: خصائص المكون
→ الجزء 10: ورشة عمل حول العمل مع خصائص المكون والتصميم
→ الجزء 11: توليد العلامات الديناميكية وطريقة صفائف الخريطة
→ الجزء 12: ورشة العمل ، المرحلة الثالثة من العمل على طلب TODO
→ الجزء 13: المكونات القائمة على الفصل
→ الجزء 14: ورشة عمل حول المكونات القائمة على الفصل ، وحالة المكون
→ الجزء 15: ورش العمل الصحية المكونة
→ الجزء 16: المرحلة الرابعة من العمل على طلب TODO ، التعامل مع الأحداث
→ الجزء 17: المرحلة الخامسة من العمل على تطبيق TODO ، وتعديل حالة المكونات
→ الجزء 18: المرحلة السادسة من العمل على طلب TODO
→ الجزء 19: طرق دورة حياة المكون
الجزء 20: الدرس الأول في التقديم الشرطي
→ الجزء 21: الدرس الثاني وورشة العمل حول التقديم الشرطي
→ الجزء 22: المرحلة السابعة من العمل على تطبيق TODO ، وتنزيل البيانات من مصادر خارجية
→ الجزء 23: الدرس الأول حول العمل مع النماذج
→ الجزء 24: نماذج الدرس الثاني
→ الجزء 25: ورشة عمل حول العمل مع النماذج
→ الجزء 26: بنية التطبيق ، نمط الحاوية / المكون
→ الجزء 27: مشروع المقرر

الدرس 34. طرق دورة حياة المكون ، الجزء 1

→ الأصل

تتمثل إحدى ميزات تطوير تطبيقات React في حقيقة أننا نكتب رمز JavaScript بسيطًا جدًا يدفع الآليات الداخلية لـ React وبالتالي يمنحنا فرصًا كبيرة لتطوير واجهات التطبيق والعمل مع البيانات. في الوقت نفسه ، تمر المكونات التي نستخدمها خلال دورة حياتها بمراحل معينة. غالبًا ما يتم مقارنة ما يحدث لمكون ما في أحد التطبيقات بحياة الشخص. يولد الناس ، ويعيشون ، في حياتهم تحدث بعض الأحداث المهمة ، وبعد ذلك يموتون. تتشابه مكونات React في هذا مع الأشخاص ، حيث إنهم أيضًا "مولودون" و "مباشرون" و "يموتون". من خلال العمل مع المكونات ، يمكننا الرد على ما يحدث لهم ، وذلك بفضل أساليب دورة حياتهم التي يتم استدعاؤها في لحظات خاصة من "حياتهم".

في الآونة الأخيرة ، تجاوز فريق تطوير React ثلاث طرق لدورة حياة المكون. ومع ذلك ، سننظر في هذه الأساليب ، نظرًا لأنه لا يزال من الممكن استخدامها ، وبما أنه يمكن العثور عليها في التعليمات البرمجية الموجودة. بالإضافة إلى ذلك ، تمت إضافة طريقتين جديدتين لدورة حياة المكون إلى React ، والتي سنناقشها في الدرس التالي.

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

فيما يلي بعض المواد الجيدة عن طرق دورة حياة مكونات React التي كانت ذات صلة قبل React 16.3. هنا ، في منشور من مدونة React developer الرسمية ، يمكنك معرفة التغييرات التي حدثت في React 16.3.

الآن ، لنبدأ المناقشة حول أساليب دورة الحياة لمكونات React التي ستواجهها في أغلب الأحيان.

سنستخدم ، كما هو الحال دائمًا ، المشروع التجريبي هنا. في هذه الحالة ، نبدأ بمشروع قياسي تم إنشاؤه باستخدام create-react-app ، في ملف App.js الذي يحتوي على الكود التالي:

 import React, {Component} from "react" class App extends Component {   constructor() {       super()       this.state = {}   }     render() {       return (           <div>               Code goes here           </div>       )   } } export default App 

للبدء ، دعونا نلقي نظرة على الطريقة التي استخدمتها بالفعل مع المكونات القائمة على الفصل. هذه هي طريقة render() .

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

الآن دعونا نلقي نظرة على طريقة دورة حياة مكون آخر - componentDidMount() . يتم التصريح عن هذه الطريقة ، تمامًا مثل أي أساليب مكون أخرى تستند إلى الفصل ، في نص فئة مكون:

 componentDidMount() { } 

تسمى هذه الطريقة في وقت دورة حياة المكون ، والتي يمكن مقارنتها بـ "ولادة" هذا المكون. يتم تشغيل هذه الطريقة مرة واحدة بعد تركيب المكون (إدراج) في شجرة DOM. في الوقت نفسه ، على سبيل المثال ، بعد تغيير بعض البيانات التي تؤثر على مظهر المكون ، سيتم تقديمه مرة أخرى ، ولن يتم استدعاء طريقة componentDidMount() . يحدث هذا بسبب حقيقة أنه عند إجراء مثل هذه العمليات ، لا تتم إزالة المكون من شجرة DOM ثم يتم تضمينه مرة أخرى في الشجرة.

عادةً ما يتم استخدام أسلوب componentDidMount() لإجراء مكالمات إلى واجهات برمجة تطبيقات معينة في الحالات التي يحتاج فيها المطور إلى بيانات من مصادر خارجية. لنفترض أن المكون الذي TodoList هنا يسمى فعليًا TodoList وهو مكون يشكل قائمة TodoList في تطبيق Todo. يمكن أن تقوم طريقة componentDidMount() لمثل هذا المكون بتحميل المواد من قاعدة بيانات الخادم الضرورية للعرض الصحيح لقائمة المهام المخزنة على الخادم. نتيجة لذلك ، بعد اكتمال تثبيت المكون ، يمكننا ، في طريقة componentDidMount() ، تحميل البيانات اللازمة للمكون لعرضه بشكل صحيح على الصفحة. سنتحدث أيضًا عن تحميل البيانات التي تحتاجها المكونات ، ولكن في الوقت الحالي يمكنك تذكر أن هذه هي حالة الاستخدام الأكثر شيوعًا componentDidMount() .

يسمى أسلوب دورة حياة المكون التالي الذي نناقشه componentWillReceiveProps() . يمكن مقارنة هذه الطريقة بما يحدث عندما يتلقى شخص ما هدية من شخص ما. لذلك ، يمكن للمكون تلقي الخصائص من مكون الأصل. في كل مرة يأخذ فيها مكون الخصائص ، تسمى هذه الطريقة. في الوقت نفسه ، يتم استدعاء هذه الطريقة في كل مرة يقوم فيها المكون الأصل بتمرير الخصائص إلى المكون الفرعي ، وليس فقط عندما يحدث هذا لأول مرة. على سبيل المثال ، إذا قرر المكون الأصل تغيير الخصائص التي تم تمريرها إلى المكون الفرعي ، فعندئذٍ ، في أسلوب componentWillReceiveProps() ، على سبيل المثال ، يمكننا التحقق مما إذا كانت الخصائص الجديدة تختلف عن تلك التي تم نقلها بالفعل إلى المكون. الحقيقة هي أنه إذا كانت الخصائص الجديدة لا تختلف عن الخصائص القديمة ، فإن هذا يعني أن استلامها لا يغير شيئًا ، مما يعني أنه بعد اكتشاف ذلك ، لا يمكننا فعل شيء أكثر من ذلك. إذا كانت الخصائص الجديدة مختلفة عن الخصائص القديمة ، فيمكننا تنفيذ إجراءات معينة. عادة ، يتم الإعلان عن هذه الطريقة في نص فئة المكون كما يلي:

 componentWillReceiveProps(nextProps) { } 

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

 componentWillReceiveProps(nextProps) {   if (nextProps.whatever !== this.props.whatever) {       //   -    } } 

عادة ما تستخدم هذه الطريقة بهذه الطريقة.

ومع ذلك ، كما ذكرنا سابقًا ، بعد إصدار React 16.3 ، تم إهمال بعض أساليب دورة حياة المكون ، وتعد componentWillReceiveProps() واحدة من هذه الطرق.

حتى الرد 17 ، لا يزال من الممكن استخدام هذه الطرق القديمة ، رغم أنه من الأفضل عدم استخدامها. إذا لم تتمكن من الاستغناء عن الطريقة المعنية ، فستحتاج إلى UNSAFE_componentWillReceiveProps() . باتباع React 17 ، لن يعني اسم طريقة componentWillReceiveProps() أي شيء خاص.

من المفيد معرفة هذه الطريقة لتكون قادرًا على فهم الكود القديم ، لكن لن يتم استخدامه في تطوير تطبيقات React الحديثة.

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

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

 shouldComponentUpdate(nextProps, nextState) {   //  true        //  false    } 

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

طريقة أخرى لدورة حياة المكون التي سنتحدث عنها تسمى " componentWillUnmount() . تحدد هذه الطريقة نهاية "عمر" المكون - لحظة إزالته من شجرة DOM ويختفي من الشاشة.

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

فيما يلي الرمز الكامل لمكون App لدينا ، حيث تتم إضافة أساليب دورة الحياة:

 import React, {Component} from "react" class App extends Component {   constructor() {       super()       this.state = {}   }     componentDidMount() {       //  ,        }     componentWillReceiveProps(nextProps) {       if (nextProps.whatever !== this.props.whatever) {           //   -        }   }     shouldComponentUpdate(nextProps, nextState) {       //  true            //  false      }     componentWillUnmount() {       //            // ( -   )   }     render() {       return (           <div>               Code goes here           </div>       )   } } export default App 

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

الدرس 35. أساليب دورة حياة المكون ، الجزء 2

→ الأصل

كما ذُكر بالفعل في الدرس السابق ، عندما صدر رد الفعل 16.3 ، تم الإبلاغ عن أن أساليب دورة حياة المكونات الثلاثة عفا عليها الزمن. هذه الطرق هي componentWillMount() و componentWillReceiveProps() و componentWillUpdate() . كما تم الإبلاغ عن طريقتين جديدتين. هذا هو الأسلوب getSnapshotBeforeUpdate() الثابت وطريقة getSnapshotBeforeUpdate() . لا يمكن القول أن هذه الأساليب ستلعب دورًا مهمًا في الفصول المستقبلية لهذه الدورة ، ولكن على الرغم من ذلك ، سنتعرف عليها هنا.

سنختبر في نفس المشروع الذي استخدمناه في المرة الأخيرة.

إليك ما يبدو عليه شكل إعلان getDerivedStateFromProps() :

 static getDerivedStateFromProps(props, state) { } 

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

الآن دعنا نتحدث عن طريقة getSnapshotBeforeUpdate() . إليك ما يبدو عليه إعلانه في هيئة الفصل:

 getSnapshotBeforeUpdate() { } 

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

ملخص

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

أعزائي القراء! إذا كنت تقوم بتطوير تطبيقات React بشكل احترافي ، فيرجى إخبارنا بكيفية استخدام أساليب دورة حياة المكون.