فهم سلوك التقديم في React

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

دعنا نتعمق!

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

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

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

فهمتك؟ رائعة!".

في النهاية ، عبرت ذلك الجبل أيضًا. ولكن بعد ذلك أصبت بشيء مهم وصعب مثل React نفسها: التصيير .

إذا صادفت التصيير وألغازه في React ، فأنت تعلم ما أتحدث عنه. وإذا لم تكن قد فعلت ذلك ، فليس لديك أي فكرة عما يخبئه لك!

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

لماذا فهم سلوك العرض في React مهم؟

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

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

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

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

ثمل؟ نعم ، إذا سألتني.

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

ماذا يعني التجسيد في React؟

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

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

يجب أن تكون قد سمعت أن React تحافظ على ما يسمى بـ DOM الظاهري وأنها تقارنه بشكل دوري مع DOM الفعلي وتطبق التغييرات حسب الضرورة (لهذا السبب لا يمكنك فقط طرح jQuery و React معًا - تحتاج React إلى التحكم الكامل في DOM). الآن ، لا يتكون DOM الظاهري هذا من عناصر HTML كما يفعل DOM الحقيقي ، ولكن من عناصر React. ماهو الفرق؟ سؤال جيد! لماذا لا تنشئ تطبيق React صغيرًا ونرى بأنفسنا؟

لقد أنشأت تطبيق React البسيط للغاية لهذا الغرض. الكود بأكمله عبارة عن ملف واحد يحتوي على بضعة أسطر:

 import React from "react"; import "./styles.css"; export default function App() { const element = ( <div className="App"> <h1>Hello, there!</h1> <h2>Let's take a look inside React elements</h2> </div> ); console.log(element); return element; }

لاحظ ماذا نفعل هنا؟

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

قد يبدو هذا مخيفًا ، لكن لاحظ بعض التفاصيل المثيرة للاهتمام:

• ما نبحث عنه هو كائن JavaScript عادي ، وليس عقدة DOM.
• لاحظ أن الخاصية تشير إلى أن App props className (وهي فئة CSS المحددة في الكود) وأن هذا العنصر له طفلان (وهذا يتطابق أيضًا ، العناصر الفرعية هي <h1> و <h2> ) .
• تخبرنا الخاصية _source يبدأ جسم العنصر في الكود المصدري. كما ترى ، فإنه يسمي الملف App.js كمصدر ويذكر رقم السطر 6. إذا نظرت إلى الكود مرة أخرى ، ستجد أن السطر 6 هو مباشرة بعد علامة JSX الافتتاحية ، وهذا أمر منطقي. أقواس JSX تحتوي على عنصر React ؛ إنها ليست جزءًا منه ، حيث تعمل على التحول إلى React.createElement() لاحقًا.
• تخبرنا الخاصية __proto__ أن هذا الكائن يشتق كل ما لديه. خصائص من Object جافا سكريبت الجذر ، مما يعزز مرة أخرى فكرة أنه مجرد كائنات جافا سكريبت اليومية التي ننظر إليها هنا.

الآن ، نحن نفهم أن ما يسمى بـ DOM الظاهري لا يشبه أي شيء DOM الحقيقي ولكنه عبارة عن شجرة من كائنات React (JavaScript) التي تمثل واجهة المستخدم في ذلك الوقت.

أرهق؟

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

لكننا نشتت انتباهنا!

بعد أن نجونا إلى هذا الحد ، نحن الآن في وضع يسمح لنا بالإجابة على السؤال الذي كنا بعده: ما هو العرض في React؟

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

حان وقت الالتزام!

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

التقديم والأداء في تطبيقات React

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

إعادة التقديم بسبب التغيير في المكون الرئيسي

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

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

إعادة التقديم بسبب التغيير في السياق

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

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

تحسين أداء عرض React

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

استخدم Redux أو مكتبات مماثلة لإدارة الدولة

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

استخدم memo() "لتجميد" المكونات

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

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

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

دعنا أولاً نتناول المكون الخاص بمعلومات العميل. لنقم بإنشاء ملف يسمى CustomerInfo.js يحتوي على الكود التالي:

 import React from "react"; export const CustomerInfo = () => { console.log("CustomerInfo was rendered! :O"); return ( <React.Fragment> <p>Name: Sam Punia</p> <p>Email: [email protected]</p> <p>Preferred method: Online</p> </React.Fragment> ); };

لا شيء رائع ، أليس كذلك؟

فقط بعض النصوص الإعلامية (التي كان من الممكن تمريرها عبر الدعائم) التي لا يُتوقع أن تتغير عندما يتفاعل المستخدم مع التطبيق (للمتطرفين هناك ، نعم ، بالتأكيد يمكن أن يتغير ، ولكن النقطة هي ، عند مقارنتها بالباقي من التطبيق ، فهو ثابت عمليًا). لكن لاحظ بيان console.log() . سيكون هذا دليلنا لمعرفة أن المكون قد تم تقديمه (تذكر ، "تم تقديمه" يعني أنه تم جمع المعلومات الخاصة به وحسابها / مقارنتها ، وليس أنه تم رسمها على DOM الفعلي).

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

والآن دعونا نرى كيف يستخدم المكون الرئيسي لدينا مكون معلومات العميل هذا:

 import React, { useState } from "react"; import "./styles.css"; import { CustomerInfo } from "./CustomerInfo"; export default function App() { const [totalLikes, setTotalLikes] = useState(0); return ( <div className="App"> <div className="LikesCounter"> <p>You have liked us {totalLikes} times so far.</p> <button onClick={() => setTotalLikes(totalLikes + 1)}> Click here to like again! </button> </div> <div className="CustomerInfo"> <CustomerInfo /> </div> </div> ); }

لذلك ، نرى أن مكون App لديه حالة داخلية تُدار من خلال useState() . تستمر هذه الحالة في حساب عدد المرات التي أحب فيها المستخدم الخدمة / الموقع ، ويتم ضبطها في البداية على الصفر. لا شيء يمثل تحديًا فيما يتعلق بتطبيقات React ، أليس كذلك؟ على جانب واجهة المستخدم ، تبدو الأشياء كما يلي:

يبدو الزر مغريًا جدًا بحيث لا يتم تحطيمه ، على الأقل بالنسبة لي! ولكن قبل أن أفعل ذلك ، سأفتح وحدة تحكم مطوري المتصفح وأمسحها. بعد ذلك ، سأقوم بتحطيم الزر عدة مرات ، وهذا ما أراه:

لقد ضغطت على الزر 19 مرة ، وكما هو متوقع ، فإن إجمالي عدد الإعجابات يبلغ 19. كان نظام الألوان يجعل من الصعب حقًا القراءة ، لذلك أضفت مربعًا أحمر لتسليط الضوء على الشيء الرئيسي: <CustomerInfo /> المكون تم تقديمه 20 مرة!

لماذا 20؟

مرة واحدة عندما تم عرض كل شيء في البداية ، ثم 19 مرة عند الضغط على الزر. يغير الزر totalLikes ، وهي جزء من الحالة داخل مكون <App /> ، ونتيجة لذلك ، يعاد عرض المكون الرئيسي. وكما تعلمنا في الأقسام السابقة من هذا المنشور ، يتم أيضًا إعادة عرض جميع المكونات الموجودة بداخله. هذا غير مرغوب فيه لأن المكون <CustomerInfo /> لم يتغير في العملية ومع ذلك ساهم في عملية التقديم.

كيف يمكننا منع ذلك؟

كما يوضح عنوان هذا القسم تمامًا ، استخدم وظيفة memo() لإنشاء نسخة "محفوظة" أو نسخة مخبأة من مكون <CustomerInfo /> . باستخدام المكوِّن المحفوظ ، تنظر React في الخاصيّات وتقارنها بالدعامات السابقة ، وإذا لم يكن هناك تغيير ، فإن React لا تستخرج ناتج "تصيير" جديد من هذا المكوِّن.

دعنا نضيف هذا السطر من التعليمات البرمجية إلى ملف CustomerInfo.js الخاص بنا:

 export const MemoizedCustomerInfo = React.memo(CustomerInfo);

نعم ، هذا كل ما يتعين علينا القيام به! حان الوقت الآن لاستخدام هذا في المكون الرئيسي لدينا ومعرفة ما إذا كان هناك شيء يتغير:

 import React, { useState } from "react"; import "./styles.css"; import { MemoizedCustomerInfo } from "./CustomerInfo"; export default function App() { const [totalLikes, setTotalLikes] = useState(0); return ( <div className="App"> <div className="LikesCounter"> <p>You have liked us {totalLikes} times so far.</p> <button onClick={() => setTotalLikes(totalLikes + 1)}> Click here to like again! </button> </div> <div className="CustomerInfo"> <MemoizedCustomerInfo /> </div> </div> ); }

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

إذن ، كم عدد رسائل وحدة التحكم لدينا؟

واحد فقط! هذا يعني أنه بصرف النظر عن التصيير الأولي ، لم يتم لمس المكون على الإطلاق. تخيل مكاسب الأداء على تطبيق واسع النطاق حقًا! حسنًا ، حسنًا ، الرابط إلى ملعب الشفرة الذي وعدت به موجود هنا. لنسخ المثال السابق ، ستحتاج إلى استيراد واستخدام CustomerInfo بدلاً من MemoizedCustomerInfo من CustomerInfo.js .

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

تصميم مكون "ذكي"

أضع "ذكي" في الاقتباسات للأسباب التالية: 1) الذكاء غير موضوعي وموقعي بدرجة كبيرة. 2) غالبًا ما يكون للأفعال الذكية المفترضة عواقب غير سارة. لذا ، نصيحتي لهذا القسم هي: لا تكن واثقًا جدًا مما تفعله.

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

استنتاج

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

بعد ذلك ، دعنا نفهم ما هو React Hooks؟