أهم 5 أخطاء في تطبيقات ReactJS الخاصة بي

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

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

1. مكونات الدولة (الطبقات) هي أسوأ من السنانير

ربما يستحق الأمر البدء بميزة ReactJS الأكثر إثارة ، والتي ظهرت في الإصدار 16.8+ على عكس بعض المعتقدات ، ابتليت هذه الميزة بأخطاء من الأجيال السابقة من المطورين وحل العديد من المشكلات. إذا كنت لا تزال تستخدم مكونات الفصل بدلاً من الخطافات في عام 2019 ، فأنت ترتكب خطأً كبيرًا ولا تفهم مصلحتها. لن أشرح هذا بالتفصيل في هذا المقال ، أبدو أفضل من هذا الفيديو الرائع لـ Den Abramov ، لكنني لم أتمكن من بدء هذا المقال بخلاف ذلك

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

1. الأخطاء الأكثر شيوعًا في شفرة رد الفعل التي ترتكبها (ربما)
2. الأخطاء الأكثر شيوعًا التي تحدثها أفعال المطورين

2. استخدام وظائف مجهولة الدعائم

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

export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/*     */} ); } 

قد يبدو إصدار أكثر تطوراً من هذا الخطأ يشبه هذا (لا تقرأ إذا لم تكن معتادًا على Redux):

 import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent); 

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

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

فقط بضع كلمات ، كيفية الكتابة بشكل صحيح. إليك كيف:

 const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); } 

 import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent); //     import React, { useEffect } from 'react'; export default function MyComponent({ fetchProjectData, projectId }) { useEffect(() => { fetchProjectData(projectId); }, [fetchProjectData, projectId]); return ( <div>{/* -  */}</div> ); } //        ,       , ..     . , -   ,     . 

3. مثيلات رد فعل متعددة في التطبيق

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

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

 import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {/* event handler */}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({/*  -  */}); } 

4. كتابة المكتبات الخاصة بك ، بدلاً من المصدر المفتوح الموجود

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

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

5. الخوف من استخدام رمز شخص آخر

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

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

شكرا لك

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

اكتب عن المشكلات التي واجهتها في التعليقات. ربما لديك حلول للمشاكل الموضحة في هذه المقالة التي فاتني (أنا متأكد من ذلك). كل النجاح والمزاج الجيد!