الفرق بين المراجعتين لصفحة: «React/faq structure»
Kinan-mawed (نقاش | مساهمات) أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:بنية ملفات المشروع}}</noinclude>' |
Kinan-mawed (نقاش | مساهمات) لا ملخص تعديل |
||
سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE:بنية ملفات المشروع}}</noinclude> | <noinclude>{{DISPLAYTITLE:بنية ملفات المشروع}}</noinclude> | ||
== هل هناك طريقة مفضّلة لترتيب بنية ملفّات مشاريع React؟ == | |||
ليس هنالك رأي لمكتبة React حول كيفيّة وضع الملفّات ضمن المجلدات. ولكن يُقال أنّه هناك بعض المقاربات الشائعة المستخدمة التي قد تأخذها بعين الاعتبار. | |||
=== التجميع عن طريق الميزات أو الطرق (routes) === | |||
إحدى الطرق الشائعة لترتيب بنية المشاريع هي وضع ملفّات CSS، و JavaScript، والاختبارات معًا بداخل مجلّدات مُجمَّعة حس الميزة أو الطريق (route):<syntaxhighlight lang="text"> | |||
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 | |||
</syntaxhighlight>تعريف الميزة ليس عالميًّا، ولك حرية قرار اختيار التقسيمات. إن لم تستطع أن تأتي بقائمة بالمجلّدات ذات المستوى الأعلى، فبإمكانك سؤال مستخدمي منتجك حول الأجزاء الأهم التي يتكوّن منها واستخدام النموذج الذي أخبروك به كمخطط. | |||
=== التجميع عن طريق نوع الملفّات === | |||
من الطرق الأخرى الشائعة لترتيب بنية ملفّات المشروع هي تجميع الملفّات المتشابهة معًا، على سبيل المثال:<syntaxhighlight lang="text"> | |||
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 | |||
</syntaxhighlight>يفضّل بعض الأشخاص الذهاب بعيدًا أكثر من ذلك وفصل المكوّنات في مجلّدات مختلفة بناءً على دورها في التطبيق. على سبيل المثال [http://bradfrost.com/blog/post/atomic-web-design/ Atomic Design] هي منهجيّة تصميم مبنيّة على هذا المبدأ. تذكّر أنّك ستكون أكثر إنتاجيّة عندما تتعامل مع هذه المنهجيّات كأمثلة مساعدة بدلًا من قواعد صارمة يجب اتباعها. | |||
=== تجنّب الكثير من التداخل === | |||
هناك العديد من الصعوبات المرتبطة بالتداخل العميق للمجلّدات في مشاريع JavaScript، حيث يُصبِح من الأصعب كتابة استيرادات نسبيّة بينها، أو تحديث هذه الاستيرادات عند إزالة الملفّات. ما لم يكن هنالك سبب مقنع جدًّا لاستخدام بنية مجلّدات عميقة، فانظر في تحديد نفسك إلى ثلاثة أو أربعة مجلّدات متداخلة كحد أقصى ضمن المشروع الواحد. هذه مجرّد توصيات طبعًا وقد لا يكون لها علاقة بمشروعك. | |||
=== لا تفرط في التفكير بهذا الموضوع === | |||
إن كنت قد بدأت للتو بالمشروع، [[wikipedia:Analysis_paralysis|فلا تأخذ أكثر من خمسة دقائق]] لاختيار بنية الملفّات. اختر أي من الطرق المذكورة في الأعلى (أو استخدم طريقتك) وابدأ بكتابة الشيفرة! على الأغلب أنك ستعيد النظر في الموضوع على أيّة حال بعد أن تكتب بعض الشيفرة. | |||
إذا كنت تشعر بأنّك عالق تمامًا، فابدأ بالاحتفاظ بالملفّات في مجلّد واحد، وبالنهاية ستكبر الملفّات لدرجة ستحتاج إلى فصل بعض الملفّات عن البقيّة. في ذلك الوقت سيكون لديك معرفة كافية لكي تدرك أي ملفّات تحتاج إلى تحريرها غالبًا معًا. بشكلٍ عام من الجيد الاحتفاظ بالملفّات التي تتغيّر عادةً قريبة من بعضها البعض. يُدعى هذا المبدأ بالرصف "colocation". | |||
عندما تكبر المشاريع ستستخدم عادةً خليط من المقاربات المذكورة بالأعلى. لذا لن يكون من الهام كثيرًا اختيار الطريقة الصحيحة منذ البداية. | |||
==مصادر== | |||
*[https://reactjs.org/docs/faq-structure.html صفحة بنية ملفات المشروع في توثيق React الرسمي]. | |||
[[تصنيف:React]] |
مراجعة 10:08، 12 سبتمبر 2018
هل هناك طريقة مفضّلة لترتيب بنية ملفّات مشاريع 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".
عندما تكبر المشاريع ستستخدم عادةً خليط من المقاربات المذكورة بالأعلى. لذا لن يكون من الهام كثيرًا اختيار الطريقة الصحيحة منذ البداية.