كيفية تنظيم المكونات الخاصة بك

يمكن أن يكون من السهل جدًا كتابة الرمز - لكن كيف تنظمه؟

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

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

الهيكل العام للمشروع

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

/تطبيق
  /الأصول
  / مكونات
  / التكوين
  /التنقل
  /شاشات
  / UTIL
  index.js

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

بلدي مكون الفلسفة

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

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

هذه هي المنهجية التي استخدمها لجميع مكوناتي.

تنظيم حسب "المجال الوظيفي"

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

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

/ مكونات
  TextInput.js
  Switch.js
  Button.js
  List.js
  ListItem.js
  Loading.js
  Calendar.js
  CalendarItem.js
  CardContainer.js
  CardBodyImage.js
  CardBodyText.js
  Header.js
  HeaderLeftButton.js
  HeaderCenterContent.js
  HeaderRightButton.js
  ...

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

هذا هو السبب في أنني أحب تقسيم المكونات إلى مستوى أعلى بعمق حسب المجال الوظيفي. لنأخذ المثال أعلاه وننظمه بمستوى أعمق.

/ مكونات
  /شكل
    TextInput.js
    Switch.js
  /قائمة
    List.js
    ListItem.js
  /التقويم
    Calendar.js
    CalendarItem.js
  /بطاقة
    CardContainer.js
    CardBodyImage.js
    CardBodyText.js
  / رأس
    Header.js
    HeaderLeftButton.js
    HeaderCenterContent.js
    HeaderRightButton.js
  Loading.js
  Button.js

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

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

شيء أخير - أحب أن أجعل منطقة وظيفية مكونة تصدر API. يتيح لي إعادة تسمية / إعادة هيكلة الأشياء حسب الرغبة. هذا يعني أنني أضيف index.js إلى كل دليل يقوم بتصدير المكونات.

استيراد TextInput من './TextInput.js' ؛
استيراد التبديل من './Switch.js' ؛

export {TextInput، Switch}؛

الفائدة الأخرى من ذلك هي انخفاض وارداتي من الشاشات / المكونات الأخرى. بدلا من الاضطرار الى القيام

استيراد TextInput من '../components/Form/TextInput' ؛
استيراد التبديل من '../components/Form/Switch' ؛

يمكنني الحصول على استيراد واحد

استيراد {TextInput، Switch} من '../components/Form' ؛

تجنب محتوى التعشيش العميق

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

وإذا كان الأمر مؤلمًا ، فلن تلتزم به في كل مكان مما يسبب التناقض. التناقض يسبب الارتباك. الارتباك يسبب skynet. لا تنشئ skynet.

إليكم مثال. لنفترض أن لدينا مجموعة ألوان قياسية في config / colors.js. للحصول على ذلك من ملف TextInput.js لدينا سيبدو

استيراد الألوان من '../../config/colors.js' ؛

أنا سعيد بهذا. ولكن إذا ذهبنا أعمق تبدأ في الحصول على المزيد والمزيد .. / .. / .. / ...

التحدي الأكبر لهذا هو مجرد النظر ورؤية عدد الأدلة التي لديك لترتفع. اثنان يمكنني فهم سهل. 3 ويجب أن أبدأ العد.

أن نكون حذرين من التعشيش العميق.

البقاء المرن

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

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

لا تقضي الكثير من الوقت في القلق بشأن تنظيم الكود "المثالي". أنا أضمن أنك ستنتهي بكراهية شيء ما إذا كنت تقضي 10 دقائق أو 10 ساعات في إعداده.

هل تريد التعمق أكثر في إنشاء مكتبة مكونات رائعة لإنشاء تطبيقك؟ تحقق من الدورة التدريبية الخاصة بي "إنشاء مكتبة مكونات مع Storybook" في مدرسة React Native School! نحن نغطي إعداد واستخدام Storybook ، وتقسيم الواجهة إلى مكونات ، وكيفية بنائها ، وأكثر!

نشرت أصلا في www.reactnativeschool.com.