الفرق بين المراجعتين ل"React/faq structure"

المراجعة الحالية بتاريخ 10:08، 7 نوفمبر 2020

هل هناك طريقة مفضّلة لترتيب بنية ملفّات مشاريع React؟

ليس هنالك رأي لمكتبة React حول كيفيّة وضع الملفّات ضمن المجلدات. ولكن يُقال أنّه هناك بعض المقاربات الشائعة المستخدمة التي قد تأخذها بعين الاعتبار.

التجميع عن طريق الميزات أو الطرق (routes)

إحدى الطرق الشائعة لترتيب بنية المشاريع هي وضع ملفّات CSS، و JavaScript، والاختبارات معًا بداخل مجلّدات مُجمَّعة حس الميزة أو الطريق (route):

common/
  Avatar.js
  Avatar.css
  APIUtils.js
  APIUtils.test.js
feed/
  index.js
  Feed.js
  Feed.css
  FeedStory.js
  FeedStory.test.js
  FeedAPI.js
profile/
  index.js
  Profile.js
  ProfileHeader.js
  ProfileHeader.css
  ProfileAPI.js

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

التجميع عن طريق نوع الملفّات

من الطرق الأخرى الشائعة لترتيب بنية ملفّات المشروع هي تجميع الملفّات المتشابهة معًا، على سبيل المثال:

api/
  APIUtils.js
  APIUtils.test.js
  ProfileAPI.js
  UserAPI.js
components/
  Avatar.js
  Avatar.css
  Feed.js
  Feed.css
  FeedStory.js
  FeedStory.test.js
  Profile.js
  ProfileHeader.js
  ProfileHeader.css

يفضّل بعض الأشخاص الذهاب بعيدًا أكثر من ذلك وفصل المكوّنات في مجلّدات مختلفة بناءً على دورها في التطبيق. على سبيل المثال Atomic Design هي منهجيّة تصميم مبنيّة على هذا المبدأ. تذكّر أنّك ستكون أكثر إنتاجيّة عندما تتعامل مع هذه المنهجيّات كأمثلة مساعدة بدلًا من قواعد صارمة يجب اتباعها.

تجنّب الكثير من التداخل

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

لا تفرط في التفكير بهذا الموضوع

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

إذا كنت تشعر بأنّك عالق تمامًا، فابدأ بالاحتفاظ بالملفّات في مجلّد واحد، وبالنهاية ستكبر الملفّات لدرجة ستحتاج إلى فصل بعض الملفّات عن البقيّة. في ذلك الوقت سيكون لديك معرفة كافية لكي تدرك أي ملفّات تحتاج إلى تحريرها غالبًا معًا. بشكلٍ عام من الجيد الاحتفاظ بالملفّات التي تتغيّر عادةً قريبة من بعضها البعض. يُدعى هذا المبدأ بالرصف "colocation".

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

انظر أيضًا

مصادر

صفحة بنية ملفات المشروع في توثيق React الرسمي.

@@ سطر 43: / سطر 43: @@
    ProfileHeader.js
    ProfileHeader.css
 </syntaxhighlight>يفضّل بعض الأشخاص الذهاب بعيدًا أكثر من ذلك وفصل المكوّنات في مجلّدات مختلفة بناءً على دورها في التطبيق. على سبيل المثال [http://bradfrost.com/blog/post/atomic-web-design/ Atomic Design] هي منهجيّة تصميم مبنيّة على هذا المبدأ. تذكّر أنّك ستكون أكثر إنتاجيّة عندما تتعامل مع هذه المنهجيّات كأمثلة مساعدة بدلًا من قواعد صارمة يجب اتباعها.
@@ سطر 63: / سطر 62: @@
 * [[React/faq state|حالة المكونات]]
 * [[React/faq styling|التنسيق واستخدام CSS مع React]]
+* [[React/faq versioning|سياسة الإصدارات المتبعة في React]]
 * [[React/faq internals|DOM الافتراضي والكائنات الداخلية]]
 ==مصادر==