الفرق بين المراجعتين لصفحة: «React/faq structure»
جميل-بيلوني (نقاش | مساهمات) ط تحديث الصفحة، والعنوان، والتصنيفات |
جميل-بيلوني (نقاش | مساهمات) طلا ملخص تعديل |
||
سطر 63: | سطر 63: | ||
* [[React/faq state|حالة المكونات]] | * [[React/faq state|حالة المكونات]] | ||
* [[React/faq styling|التنسيق واستخدام CSS مع React]] | * [[React/faq styling|التنسيق واستخدام CSS مع React]] | ||
* [[React/faq versioning|سياسة الإصدارات المتبعة في React]] | |||
* [[React/faq internals|DOM الافتراضي والكائنات الداخلية]] | * [[React/faq internals|DOM الافتراضي والكائنات الداخلية]] | ||
==مصادر== | ==مصادر== |
مراجعة 18:00، 24 فبراير 2019
هل هناك طريقة مفضّلة لترتيب بنية ملفّات مشاريع 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".
عندما تكبر المشاريع ستستخدم عادةً خليط من المقاربات المذكورة بالأعلى. لذا لن يكون من الهام كثيرًا اختيار الطريقة الصحيحة منذ البداية.
انظر أيضًا
- المصطلحات
- استخدام AJAX مع React
- أسئلة حول Babel، و JSX، وخطوات بناء التطبيقات
- تمرير الدوال إلى المكونات
- حالة المكونات
- التنسيق واستخدام CSS مع React
- سياسة الإصدارات المتبعة في React
- DOM الافتراضي والكائنات الداخلية