كيفية هيكلة تطبيق TypeScript + React + Redux للتطبيق

دليل إلى React + Redux التطبيق بسيطة وأكثر تصريحا

المشكلة

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

حل

أود أن أقدم لكم هيكلي البسيط والعمارة الشاملة التي تعمل بشكل جيد مع أي تطبيق بحجم. لقد كنت أستخدم هذا في تطبيق إنتاجي منذ البداية وحتى الآن 20K + سطور من التعليمات البرمجية. هناك بعض التحسينات التي قد يختارها المرء لإجراء تطبيق أكبر ، لكنني أردت فقط تقديم نهجي البسيط القائم على Elm.

هيكل المجلد

إليك بنية المجلد الأساسية للتطبيق.

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

types.ts

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

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

actions.ts

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

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

reducer.ts

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

على سبيل المثال ، دعنا نقول أن لديك اثنين من المخفضات ، واحد للسيارات والآخر للمستخدمين. إذا كنت بحاجة إلى توصيل هذه البيانات ، فسوف تحتاج في النهاية إلى التعامل مع إجراء واحد في كلا المخفضين. يمكنك العثور على المزيد حول هذه المناقشة على منشور Redux الرسمي حول وجود مخفضات متعددة هنا: https://redux.js.org/recipes/structuring-reducers/using-combinereducers.

انا افضل تحديث فقط في مكان واحد. يعد الأمر أكثر إقرارًا وأسهل في التعامل مع التغييرات في وقت لاحق حيث يمكن أن تصبح إعادة التوطين في Redux كابوسًا بسرعة.

ملاحظة ، أنا أستخدم immer هنا للتعامل مع تغييرات الحالة في المخفض. يمنحك Immer ببساطة مسودة ثابتة يمكنك تحورها وإرجاع الحالة الجديدة مباشرةً. يمكنك العثور عليها هنا: https://github.com/immerjs/immer.

effects.ts

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

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

ضع كل شيء معا

الآن ، نحتاج فقط إلى توصيل متجر redux بمكونات React الخاصة بنا! لقد قمت أيضًا بتضمين مثال على كيفية استخدام ملحق redux-devtools. يمكنك العثور على الامتداد هنا: https://github.com/zalmoxisus/redux-devtools-extension.

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

شكرا للقراءة ونتمنى لك التوفيق في مشاريعك! ترك تعليق أو رسالة لي إذا كان لديك أي أسئلة.