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

هناك العديد من المكتبات الجيدة في نظام React البيئي والتي يمكن استخدامها لإدارة جوانب معينة من التطبيق. سوف نتطرق إلى بعضها في بعض التفاصيل. بالإضافة إلى ذلك ، سيتم تقديم بعض التوصيات العملية هنا. إذا كان المشروع يجب أن يكون جيدًا ، فسيكون من المفيد اتباع هذه التوصيات منذ بداية العمل عليه. في هذا الجزء من الترجمة ، سنتحدث عن التخطيط والإجراءات ومصادر البيانات وواجهة برمجة التطبيقات. الخطوة الأولى في تطوير تطبيقات React واسعة النطاق ، والتي سننظر فيها ، هي التخطيط.
الجزء 1:
المبادئ التوجيهية العملية لتطوير تطبيقات رد الفعل على نطاق واسع. التخطيط والإجراءات ومصادر البيانات وواجهة برمجة التطبيقاتالجزء 2:
المبادئ التوجيهية العملية لتطوير تطبيقات رد الفعل على نطاق واسع. الجزء 2: إدارة الدولة ، التوجيهتخطيط
في معظم الأحيان ، تخطي المطورين هذه المرحلة من العمل على التطبيق. ويرجع ذلك إلى حقيقة أنه أثناء عملية التخطيط لا يتم عمل أي كود للكتابة. لكن لا يمكن التقليل من أهمية هذه الخطوة. سوف تتعلم قريبا لماذا هذا هو الحال.
hy لماذا تخطط عند تطوير التطبيقات؟
تطوير البرمجيات يتطلب تنسيق العديد من العمليات. في الوقت نفسه ، كل شيء قادر على الخروج بسهولة عن السيطرة. العوائق والشكوك التي تواجه عملية التطوير قد تعرض توقيت المشروع للخطر.
المساعدة في الوفاء بالمواعيد النهائية هي المكان الذي يمكن أن تساعدك فيه مرحلة تخطيط المشروع. في هذه المرحلة ، "ضع على الرفوف" جميع الميزات التي يجب أن يتمتع بها التطبيق. من الأسهل بكثير التنبؤ بالوقت الذي سيستغرقه إنشاء وحدات فردية صغيرة ، تقع القائمة على عاتق المبرمجين ، بدلاً من محاولة ، في الاعتبار ، تقدير توقيت تطوير المشروع بأكمله.
إذا شارك العديد من المبرمجين في مشروع كبير (كما يحدث عادة) ، فإن وجود خطة مطورة مسبقًا ، وثيقة معينة ، سوف يسهل بشكل كبير تفاعلهم مع بعضهم البعض. في الواقع ، يمكن تعيين العديد من المهام التي صيغت في هذا المستند للمطورين الفرديين. سيساعد وجوده أعضاء الفريق على إدراك ما يفعله زملاؤهم.
وأخيراً ، بفضل هذه الوثيقة ، يمكنك أن ترى بوضوح تام كيف يتقدم العمل في المشروع. غالبًا ما ينتقل المبرمجون من العمل على جزء من التطبيق إلى آخر ، ويعودون إلى ما فعلوه من قبل ، في وقت متأخر أكثر مما يريدون.
النظر في عملية تخطيط التطبيق.
الخطوة 1: الصفحات والمكونات
من الضروري تحديد مظهر ووظيفة كل صفحة من صفحات التطبيق. أحد أفضل الأساليب هنا هو رسم كل صفحة. يمكنك القيام بذلك إما باستخدام
أداة نموذج بالحجم الطبيعي أو يدويًا على الورق. سوف يعطيك هذا فهمًا جيدًا للمعلومات التي يجب أن تكون موجودة في كل صفحة. إليك الشكل الذي قد يبدو عليه تخطيط الصفحة.
تخطيط الصفحة (مأخوذ من هنا )في المخطط أعلاه ، يمكنك بسهولة تحديد الكيانات الحاوية الأصل وأطفالهم. في وقت لاحق ، ستصبح الحاويات الأصل صفحات التطبيق ، وستقع العناصر الأصغر في مجلد
components
في المشروع. بعد الانتهاء من تخطيطات الرسم - اكتب على كل منها أسماء الصفحات والمكونات.
الخطوة 2: الإجراءات والأحداث
بعد أن تقرر مكونات التطبيق ، فكر في الإجراءات التي سيتم تنفيذها في كل منها. في وقت لاحق ، من هذه المكونات ، سيتم إرسال هذه الإجراءات.
النظر في متجر على الإنترنت على الصفحة الرئيسية التي تعرض قائمة من المنتجات الموصى بها. سيتم تقديم كل عنصر من عناصر هذه القائمة في المشروع كمكون منفصل. اسمح لهذا المكون أن يكون
ListItem
.
مثال على الصفحة الرئيسية للمتجر عبر الإنترنت (مأخوذة من هنا )في هذا التطبيق ، يسمى الإجراء الذي يتخذه المكون في قسم
Product
بـ
getItems
. قد تتضمن بعض الأنشطة الأخرى التي قد يتم تضمينها في هذه الصفحة
getUserDetails
و
getSearchResults
وما إلى ذلك.
الخطوة 3: البيانات والنماذج
يحتوي كل مكون تطبيق على بعض البيانات المرتبطة به. إذا تم استخدام نفس البيانات بواسطة العديد من مكونات التطبيق ، فستكون جزءًا من شجرة حالة مركزية. تتم إدارة شجرة الحالة باستخدام
Redux .
يتم استخدام هذه البيانات من قبل العديد من المكونات. نتيجة لذلك ، عندما يتم تغيير البيانات بواسطة مكون واحد ، تنعكس في مكونات أخرى.
إنشاء قائمة من البيانات المماثلة للتطبيق الخاص بك. سوف يصبح مخططا نموذجيا. استنادا إلى هذه القائمة ، سيكون من الممكن إنشاء مخفضات.
products: { productId: {productId, productName, category, image, price}, productId: {productId, productName, category, image, price}, productId: {productId, productName, category, image, price}, }
دعونا نعود إلى المثال أعلاه مع متجر على الإنترنت. يستخدم قسم المنتجات والمنتجات الجديدة الموصى بها نفس نوع البيانات المستخدم لتمثيل المنتجات الفردية (شيء مثل
product
). سيكون هذا النوع بمثابة الأساس لإنشاء أحد مخفضات التطبيق.
بعد توثيق خطة العمل ، حان الوقت للنظر في بعض التفاصيل الضرورية لإعداد طبقة التطبيق المسؤولة عن العمل مع البيانات.
الإجراءات ، مصادر البيانات ، واجهات برمجة التطبيقات
مع نمو تطبيقك ، يحدث غالبًا أن هناك عددًا كبيرًا من الطرق المرتبطة بمستودع Redux. يحدث أن تتفاقم بنية الدليل ، متخلفة عن الاحتياجات الحقيقية للتطبيق. يصبح الحفاظ على كل هذا أمرًا صعبًا ، حيث تصبح إضافة ميزات جديدة إلى التطبيق أكثر تعقيدًا.
دعنا نتحدث عن كيفية ضبط بعض الأشياء من أجل الحفاظ على رمز مستودع Redux نظيفًا على المدى الطويل. يمكن تجنب العديد من المشكلات إذا تم ، منذ البداية ، إنشاء وحدات مناسبة لإعادة الاستخدام. من المفيد القيام بذلك ، على الرغم من أنه قد يبدو في البداية كأنه فائض ، مما يعقد المشروع بشكل غير ضروري.
▍ تصميم API وتطبيقات العميل
أثناء الإعداد الأولي للتخزين ، يؤثر تنسيق البيانات الذي يأتي من واجهة برمجة التطبيقات بشكل كبير على بنية التخزين. غالبًا ، يجب تحويل البيانات قبل نقلها إلى مخفضات.
في الآونة الأخيرة ،
قيل الكثير حول ما هو مطلوب وما لا يلزم القيام به عند تصميم واجهة برمجة التطبيقات. عوامل مثل إطار الخلفية وحجم التطبيق يكون لها تأثير إضافي على كيفية تصميم واجهات برمجة التطبيقات.
يوصى بتخزين الوظائف المساعدة في مجلد منفصل ، كما هو الحال في تطوير تطبيقات الخادم. قد تكون هذه ، على سبيل المثال ، وظائف لتنسيق البيانات وتعيينها. تأكد من أن هذه الوظائف ليس لها آثار جانبية (انظر
هذه المقالة عن الوظائف الخالصة).
export function formatTweet (tweet, author, authedUser, parentTweet) { const { id, likes, replies, text, timestamp } = tweet const { name, avatarURL } = author return { name, id, timestamp, text, avatar: avatarURL, likes: likes.length, replies: replies.length, hasLiked: likes.includes(authedUser), parent: !parentTweet ? null : { author: parentTweet.author, id: parentTweet.id, }
في مثال التعليمات البرمجية هذا ، تضيف وظيفة
formatTweet
مفتاحًا جديدًا (
formatTweet
) إلى كائن tweet في تطبيق الواجهة الأمامية. تقوم هذه الوظيفة بإرجاع البيانات بناءً على المعلمات التي تم تمريرها إليها ، دون التأثير على البيانات الموجودة خارجها.
هنا يمكنك الذهاب أبعد من ذلك عن طريق تعيين البيانات إلى كائن تم وصفه مسبقًا والذي يتوافق هيكله مع احتياجات تطبيق الواجهة الأمامية. ومع ذلك ، يمكنك التحقق من صحة بعض المفاتيح.
الآن دعنا نتحدث عن تلك الأجزاء من التطبيقات المسؤولة عن إجراء مكالمات إلى
API .
▍ تنظيم العمل مع مصادر البيانات
ما سنتحدث عنه في هذا القسم سوف تستخدمه Redux مباشرة لتعديل حالة التطبيق. بناءً على حجم التطبيق (بالإضافة إلى ذلك ، في الوقت الذي يتوفر فيه المبرمج) ، يمكنك التعامل مع تصميم مستودع البيانات باستخدام أحد النهجين التاليين:
- دون استخدام وكيل (ساعي).
- باستخدام وكيل.
a تصميم مستودع بدون استخدام وكيل
باستخدام هذا الأسلوب ، أثناء تكوين وحدة التخزين ، يتم إنشاء آليات تنفيذ طلبات
GET
و
POST
و
PUT
لكل نموذج على حدة.
تتفاعل المكونات مع API دون استخدام وكيليوضح المخطط السابق أن كل مكون يرسل إجراءات تستدعي الأساليب من مخازن البيانات المختلفة. إليك كيف
updateBlog
طريقة
updateBlog
من ملف
BlogApi
، من خلال هذا النهج:
function updateBlog(blog){ let blog_object = new BlogModel(blog) axios.put('/blog', { ...blog_object }) .then(function (response) { console.log(response); }) .catch(function (error) { console.log(error); }); }
هذا النهج يوفر الوقت ... وفي البداية يسمح لك أيضًا بإجراء تغييرات على الكود دون القلق بشأن الآثار الجانبية. ولكن بسبب هذا ، سيكون للمشروع كمية كبيرة من التعليمات البرمجية الزائدة. بالإضافة إلى ذلك ، فإن تنفيذ العمليات على مجموعات من الكائنات سيتطلب الكثير من الوقت.
a تصميم مستودع باستخدام وكيل
مع هذا النهج ، على المدى الطويل ، يكون المشروع أسهل في الصيانة ، ومن السهل إجراء تغييرات. لا تصبح قاعدة الشفرة ملوثة بمرور الوقت ، حيث أن المطور لا يدخر مشكلة تنفيذ الاستعلامات المتوازية باستخدام axios.
تتفاعل المكونات مع API باستخدام وكيلومع ذلك ، مع هذا النهج ، يلزم قدر معين من الوقت للإعداد الأولي للنظام. إنها أقل مرونة. هذا أمر جيد وسيء ، لأنه لا يسمح للمطور بعمل شيء غير عادي.
export default function courier(query, payload) { let path = `${SITE_URL}`; path += `/${query.model}`; if (query.id) path += `/${query.id}`; if (query.url) path += `/${query.url}`; if (query.var) path += `?${QueryString.stringify(query.var)}`; return axios({ url: path, ...payload }) .then(response => response) .catch(error => ({ error })); }
يظهر رمز طريقة
courier
الأساسية
courier
. يمكن لجميع معالجات واجهة برمجة التطبيقات أن تسميها ، لتمريرها البيانات التالية:
- طلب كائن يحتوي على معلومات متعلقة بعنوان URL. على سبيل المثال ، اسم النموذج وسلسلة الاستعلام وما إلى ذلك.
- الحمولة التي تحتوي على رؤوس الطلبات ونصها.
▍ مكالمات API والإجراءات الداخلية للتطبيق
عند العمل مع Redux ، يتم إيلاء اهتمام خاص لاستخدام الإجراءات المحددة مسبقًا. هذا يجعل تغييرات البيانات التي تحدث في التطبيق يمكن التنبؤ بها.
قد يبدو تعريف مجموعة كاملة من الثوابت في تطبيق كبير مهمة مستحيلة. ومع ذلك ، فإن تنفيذ هذه المهمة مبسط إلى حد كبير بفضل مرحلة التخطيط التي استعرضناها سابقًا.
export const BOOK_ACTIONS = { GET:'GET_BOOK', LIST:'GET_BOOKS', POST:'POST_BOOK', UPDATE:'UPDATE_BOOK', DELETE:'DELETE_BOOK', } export function createBook(book) { return { type: BOOK_ACTIONS.POST, book } export function handleCreateBook (book) { return (dispatch) => { return createBookAPI(book) .then(() => { dispatch(createBook(book)) }) .catch((e) => { console.warn('error in creating book', e); alert('Error Creating book') }) } export default { handleCreateBook, }
يعرض مقتطف الشفرة أعلاه طريقة بسيطة لاستخدام أساليب مصدر بيانات
createBookApi
مع إجراءات Redux. يمكن بسهولة تمرير طريقة
createBook
إلى طريقة
dispatch
Redux.
بالإضافة إلى ذلك ، لاحظ أنه يتم تخزين هذا الرمز في المجلد الذي يتم تخزين ملفات إجراءات المشروع فيه. وبالمثل ، يمكنك إنشاء ملفات JavaScript تعلن عن الإجراءات ومعالجات نماذج التطبيقات الأخرى.
النتائج
تحدثنا اليوم عن دور مرحلة التخطيط في تطوير المشاريع الكبيرة. ناقشنا هنا أيضًا ميزات تنظيم التطبيق مع مصادر البيانات. سيركز الجزء التالي في هذه المقالة على إدارة حالة التطبيق وتطوير واجهة مستخدم قابلة للتطوير.
أعزائي القراء! من أين تبدأ تطوير تطبيقات React؟
