مقدمة إلى React كنا في عداد المفقودين

React هي مكتبة JavaScript الأكثر شهرة في العالم. لكن هذه المكتبة ليست جيدة لأنها مشهورة ولكن لأنها مشهورة لأنها جيدة. تبدأ معظم البرامج التعليمية التمهيدية الموجودة في React بأمثلة عن كيفية استخدام المكتبة. لكن هذه الأدلة لا تذكر أي شيء عن سبب كون React هو الاختيار الصحيح.



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

لماذا تتفاعل؟

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



عندما ظهرت مكتبة React ، غيرت بشكل جذري طريقة عمل مكتبات وأطر عمل JavaScript. بينما روجت مشاريع أخرى مماثلة لأفكار MVC و MVVM وما شابه ، اتخذت React نهجًا مختلفًا. وبالتحديد ، تم هنا عزل عرض المكون المرئي للتطبيق عن عرض النموذج. بفضل React ، ظهرت بنية جديدة تمامًا في النظام البيئي للواجهة الأمامية لـ JavaScript - Flux.



لماذا فعل فريق React هذا؟ لماذا هذا النهج أفضل من تلك التي سبقته ، مثل هندسة MVC وكود السباغيتي المكتوب في jQuery؟ إذا كنت من النوع المهتمين في هذه الأسئلة، يمكنك مشاهدة هذا 2013 الحديث عن تطوير التطبيقات جافا سكريبت في الفيسبوك.



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



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



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



نقص الحتمية = الحوسبة المتوازية + الحالة المتغيرة.



^{Martin Oderski}



كانت المهمة الرئيسية لفريق تطوير ^React هي حل هذه المشكلة. تعاملوا معها من خلال نهجين مبتكرين رئيسيين:

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

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



^{توم أوتشينو ، JSConfUS 2013}



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





بنية التدفق



عندما يُسأل عن سبب وجوب الانتباه إلى React ، أجد إجابة بسيطة: "النقطة المهمة هي أننا بحاجة إلى عرض حتمي لوجهات النظر ، وتجعل React هذه المهمة أسهل كثيرًا."



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



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

JSX

JSX هو امتداد JavaScript يسمح لك بإنشاء مكونات واجهة مستخدم بشكل إعلاني. يحتوي JSX على الميزات البارزة التالية:

• تطبيق ترميز تعريفي بسيط.
• يوجد رمز الترميز في نفس مكان رمز المكون.
• ( — ). , , ( — HTML, CSS, JavaScript).
• DOM.
• , React-. , React , ( , , React Native, , Netflix Gibbon, Canvas/WebGL-, react-html-email).

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



في الوقت الحاضر ، إذا نظرت إلى أدوات الواجهة الأمامية المختلفة ، فستجد أنه *ngForلا يمكنك الاستغناء عن بناء جملة خاص ، مثل التوجيه من Angular. ولكن نظرًا لأنه يمكن تسمية JSX بمجموعة شاملة من JavaScript ، فإن إنشاء ترميز JSX يمكن أن يستفيد من إمكانات JS الحالية.



على سبيل المثال ، يمكنك التكرار على مجموعة من العناصر باستخدام الطريقة Array.prototype.map. يمكنك استخدام العوامل المنطقية وتنظيم العرض الشرطي باستخدام عامل التشغيل الثلاثي. يمكنك استخدام وظائف خالصة ، يمكنك إنشاء سلاسل باستخدام القوالب الحرفية . بشكل عام ، جميع ميزات JavaScript متاحة لأولئك الذين يصفون الواجهات باستخدام JSX. أعتقد أن هذه ميزة كبيرة لـ React على الأطر والمكتبات الأخرى.



إليك نموذج لرمز JSX:

const ItemList = ({ items }) => (
  <ul>
    {items.map((item) => (
      <li key={item.id}>
        <div>{item.name}</div>
      </li>
    ))}
  </ul>
);

ومع ذلك ، عند العمل مع JSX ، يجب أن تأخذ في الاعتبار بعض الميزات التي قد تبدو في البداية غير عادية.

• , , HTML. , class className. camelCase.
• , , , JSX- key. . id, key.

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



فيما يلي ميزات تصميم React المفضلة لدي:

• CSS-, . , . — , .
• CSS- — CSS- . JavaScript-. CSS-, . Next.js, , .
• و نصب JSX حزمة ، والذي يسمح لك لاعلان أساليب الحق في حياتك تتفاعل كود مكون. هذا مشابه لاستخدام علامة <style>في HTML. نطاق هذه الأنماط يمكن أن يسمى "hyperlocal". النقطة المهمة هي أن الأنماط تؤثر فقط على العناصر التي يتم تطبيقها عليها وأطفالها. عند استخدام Next.js ، يمكن استخدام الحزمة style-jsx دون الحاجة إلى الاتصال وتهيئة شيء ما بنفسك.

الأحداث الاصطناعية

يزودنا React بغلاف عبر المتصفحات SyntheticEventsيمثل أحداثًا تركيبية ومصممًا لتوحيد العمل مع أحداث DOM. الأحداث الاصطناعية مفيدة للغاية لعدة أسباب:

1. , . .
2. . , , , JavaScript HTML, . . , , React- .
3. . . , , . , , , . . , . , JavaScript, .

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

دورة حياة المكون

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



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



في React ، بدءًا من الإصدار 0.14 ، كان هناك بناء جملة لوصف مكون قائم على الفئة يسمح لك بمعالجة أحداث دورة حياة المكون. هناك ثلاث مراحل حرجة في دورة حياة مكونات React: Mount و Update و Unmount.





دورة حياة المكون



يمكن تقسيم مرحلة التحديث إلى ثلاثة أجزاء: التقديم (العرض) ، الالتزام المسبق (التحضير لإجراء تغييرات على شجرة DOM) ، الالتزام (إجراء التغييرات على شجرة DOM).





هيكل مرحلة التحديث



دعونا نتناول هذه المراحل من دورة حياة المكون بمزيد من التفصيل:

• Render — . render() , . , JSX.
• Precommit — DOM, getSnapShotBeforeUpdate. , , .
• الالتزام - خلال هذه المرحلة من دورة حياة المكون ، تُحدِّث React DOM والمراجع . هنا يمكنك استخدام طريقة componentDidUpdateأو خطاف useEffect. هذا هو المكان الذي يمكنك فيه تنفيذ التأثيرات وجدولة التحديثات واستخدام DOM والمهام المماثلة الأخرى.

أعد دان أبراموف مخططًا ممتازًا يوضح كيفية عمل آليات دورة حياة المكونات.





دورة حياة مكونات React



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



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



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

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

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

رد الفعل هوكس

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



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



ربط useEffectيسمح لك بوضع الآثار الجانبية في قائمة انتظار للتنفيذ لاحقًا. سيتم استدعاؤهم في الوقت المناسب في دورة حياة المكون. يمكن أن يأتي هذا الوقت فورًا بعد تثبيت المكون (على سبيل المثال ، عند استدعاء طريقة دورة حياة componentDidMount ) ، أثناء مرحلة Commit (طريقة componentDidUpdate ) ، مباشرةً قبل إلغاء تثبيت المكون ( componentWillUnmount ).



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



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



إليك ما تقدمه لنا خطافات React:

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

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

مكونات الحاوية ومكونات العرض

في محاولة لتحسين نمطية المكونات وإمكانية إعادة استخدامها ، أركز على تطوير نوعين من المكونات:

• مكونات الحاوية هي مكونات متصلة بمصادر البيانات ويمكن أن يكون لها آثار جانبية.
• حبوب العرض التقديمي ، في معظمها ، حبوب نقية تُرجع دائمًا نفس JSX ، نظرًا لنفس الدعائم والسياق.

يجب عدم الخلط بين المكونات النقية والصنف الأساسي React.PureComponent ، والذي سمي بهذا الاسم لأنه غير آمن للاستخدام لإنشاء مكونات غير نقية.

▍ مكونات العرض

ضع في اعتبارك ميزات مكونات العرض:

• لا يتفاعلون مع موارد الشبكة.
• لا يقومون بحفظ البيانات localStorageأو التحميل من هناك.
• أنها لا تقدم بعض البيانات غير المتوقعة.
• لا تشير مباشرة إلى وقت النظام الحالي (على سبيل المثال ، من خلال استدعاء طريقة Date.now()).
• أنها لا تتفاعل مباشرة مع متجر الدولة التطبيق.
• - , , , .

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



أفضل عدو الخير.



^فولتير

▍ مكونات الحاوية

مكونات الحاوية هي تلك المكونات المسؤولة عن إدارة الحالة أو تنفيذ عمليات الإدخال / الإخراج أو أي مهمة أخرى قد تكون أحد الآثار الجانبية. لا يتعين عليهم تقديم أي ترميز بمفردهم. بدلاً من ذلك ، يقومون بتفويض مهمة العرض إلى مكونات العرض ، ويعملون هم أنفسهم كغلاف لمثل هذه المكونات. عادة، وهو مكون الحاويات في يردون + مسترجع تطبيق المكالمات ببساطة mapStateToProps()و mapDispatchToProps()ثم يمر البيانات المناسبة لمكونات العرض. يمكن أيضًا استخدام الحاويات في بعض المهام العامة ، والتي سنناقشها أدناه.

مكونات عالية المستوى

المكون ذو الترتيب الأعلى (HOC) هو مكون يأخذ مكونات أخرى ويعيد مكونًا جديدًا يقوم بتنفيذ وظائف جديدة بناءً على المكونات الأصلية.



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



على عكس React hooks وتقديم الدعائم، المكونات ذات الترتيب الأعلى تصلح للتكوين باستخدام النهج القياسي لتكوين الوظيفة. يتيح لك هذا وصف نتائج تكوين القدرات المعدة للاستخدام في أماكن مختلفة من التطبيق بشكل إعلاني. في الوقت نفسه ، يجب ألا تدرك المكونات الجاهزة وجود بعض الاحتمالات. في ما يلي مثال على HOC من EricElliottJS.com :

import { compose } from 'lodash/fp';
import withFeatures from './with-features';
import withEnv from './with-env';
import withLoader from './with-loader';
import withCoupon from './with-coupon';
import withLayout from './with-layout';
import withAuth from './with-auth';
import { withRouter } from 'next/router';
import withMagicLink from '../features/ethereum-authentication/with-magic-link';

export default compose(
  withEnv,
  withAuth,
  withLoader,
  withLayout({ showFooter: true }),
  withFeatures,
  withRouter,
  withCoupon,
  withMagicLink,
);

يظهر هنا مزيج من العديد من الميزات المشتركة عبر جميع الصفحات على الموقع. وهي withEnvتقرأ الإعدادات من متغيرات البيئة ، withAuthوتنفذ آلية مصادقة GitHub withLoader، , withLayout({ showFooter: true })وتعرض الرسوم المتحركة أثناء تحميل بيانات المستخدم ، وتعرض تخطيطًا قياسيًا مع تذييل ، وتعرض withFeatureالإعدادات ، withRouterوتحميل جهاز التوجيه withCoupon، وتكون مسؤولة عن العمل مع القسائم ، withMagicLingوتدعم مصادقة المستخدم بدون كلمة مرور باستخدام سحر .



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



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

import LessonPage from '../features/lesson-pages/lesson-page.js';
import pageHOC from '../hocs/page-hoc.js';
export default pageHOC(LessonPage);

هذه المكونات ذات الترتيب الأعلى لها بديل ، ولكن هذا بناء مشكوك فيه يسمى "هرم العذاب" ومن الأفضل عدم استخدامه. هكذا تبدو:

import FeatureProvider from '../providers/feature-provider';
import EnvProvider from '../providers/env-provider';
import LoaderProvider from '../providers/loader-provider';
import CouponProvider from '../providers/coupon-provider';
import LayoutProvider from '../providers/layout-provider';
import AuthProvider from '../providers/auth-provider';
import RouterProvider from '../providers/RouterProvider';
import MagicLinkProvider from '../providers/magic-link-provider';
import PageComponent from './page-container';

const WrappedComponent = (...props) => (
  <EnvProvider { ...props }>
    <AuthProvider>
      <LoaderProvider>
        <LayoutProvider showFooter={ true }>
          <FeatureProvider>
            <RouterProvider>
              <CouponProvider>
                <MagicLinkProvider>
                  <YourPageComponent />
                </MagicLinkProvider>
              </CouponProvider>
            </RouterProvider>
          </FeatureProvider>
        </LayoutProvider>
      </LoaderProvider>
    </AuthProvider>
  </EnvProvider>
);

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



يعد استخدام التركيب لحل المشكلات العامة أحد أفضل الطرق لتقليل تعقيد كود التطبيق الخاص بك. التأليف مهم للغاية لدرجة أنني كتبت كتابًا عنه .

النتيجة

• لماذا تتفاعل؟ يعطينا React عرضًا حتميًا للتمثيلات المرئية للمكونات ، والتي تستند إلى ربط البيانات أحادي الاتجاه والحالة الثابتة للمكونات.
• يتيح لنا JSX وصف الواجهات بسهولة في كود JavaScript.
• - .
• . , . , DOM DOM.
• React , . , , .
• - . - .
• , . ( , ).

?

في مقالة React هذه ، غطينا الكثير من مفاهيم البرمجة الوظيفية. إذا كنت تسعى لفهم عميق لمبادئ تتفاعل تطوير التطبيقات، وسوف يكون من المفيد بالنسبة لك لفرشاة على معرفتك حول وظائف نقية ، حول ثبات ، حول التمشيط والتطبيق الجزئي من الوظائف، حول تكوين وظيفة. يمكنك العثور على المواد ذات الصلة على EricElliottJS.com .



أوصي باستخدام React مع Redux و Redux-Saga و RITEway . يوصى باستخدام Redux مع Autodux و Immer... يمكنك محاولة استخدام Redux-DSM لتنظيم تدفقات عمل الحالة المعقدة .



عندما تحصل على الأساسيات وتكون جاهزًا لإنشاء تطبيقات React حقيقية ، ألق نظرة على Next.js و Vercel . ستساعد هذه الأدوات في أتمتة تكوين نظام إنشاء المشروع وخط أنابيب CI / CD ، بمساعدتهم يمكنك إعداد المشروع لنشر محسن على الخادم. لديهم نفس تأثير فريق DevOps بأكمله ، لكن استخدامهم مجاني تمامًا.



ما هي الأدوات المساعدة التي تستخدمها عند تطوير تطبيقات React؟