بنية تطبيق React Redux

مقدمة

هذه أول مشاركة لي عن حبري ، لذا لا تحكموا بشدة (حسنًا ، أو تحكموا ، لكن بشكل بناء ).



أود أن أشير إلى أنه في هذا النهج ، فإن الميزة الرئيسية بالنسبة لي هي أننا نحدد بوضوح وتفويض منطق الأعمال من خلال وحدات. وحدة واحدة مسؤولة عن شيء واحد وشيء محدد للغاية. أي ، مع هذا النهج ، أثناء عملية التطوير ، لا يوجد فكر: "أين من الأفضل (الأصح) بالنسبة لي أن أفعل هذا هنا؟". باستخدام هذا النهج ، يتضح على الفور أين يجب حل المهمة / المشكلة بالضبط.

هيكل الملف

هيكل المشروع + هو المعيار. سأحاول أن أخبرك بإيجاز بما يتم استخدامه مما يتكون منه التجمع نفسه

• لتحضير إجراءات غير متزامنة ، أستخدم البرمجيات الوسيطة saga - وهي شيء أكثر مرونة وقوة فيما يتعلق بالبرامج الوسيطة thunk
  
  
• لدي مكونات تصميم وحدات css. في الواقع ، المفهوم هو نفسه مفهوم المكونات المصممة ، ولكنه بطريقة ما أكثر ملاءمة بالنسبة لي
• طبقة بينية بين الحاويات والمكونات التي تتحكم في الدعائم التي يتم إلقاؤها من المتجر إلى المكون (الترشيح ، والحفظ ، والقدرة على معالجة أسماء الحقول لأي جزء من حالة التطبيق بسهولة) - إعادة التحديد

إعادة الملاحم

وثائق Redux sagas



الجوهر الرئيسي للقصص (وليس فقط) هو أننا نفصل منطق العمل للعمل مع الطلبات حسب الوحدات. كل ملحمة مسؤولة عن القطعة الخاصة بها من API. إذا كنت بحاجة إلى الحصول على بيانات المستخدم واستدعاء إجراء عند استلامهم الناجح - سأفعل ذلك في وحدة منفصلة usersSagas.js



العوامل الرئيسية (بالنسبة لي) لصالح sagas هي:

UPD (أضافت نقطة حول الوعد الجحيم)

• 1) حقيقة أن الأفعال ، بطريقة ودية ، يجب أن تكون مجرد وظائف تعطي شيئًا. إذا بدت بعض الإجراءات مختلفة (وهذه هي الطريقة التي يحدث بها استخدام thunk) ، أود أن أحضرها بطريقة ما إلى شكل واحد ، لأن هذا بطريقة ما لا يتناسب مع مفهوم واحد. أرغب في نقل منطق الطلبات والعمل مع البيانات الخاصة بالطلبات إلى وحدة منفصلة - وهذا هو الغرض من الملاحم
  
  
• 2) كقاعدة عامة ، إذا احتجنا إلى تقديم العديد من الطلبات التي تستخدم البيانات من الردود على الطلبات السابقة (هل نريد تخزين البيانات الوسيطة في المتجر ، أليس كذلك؟) ، فإن Redux-thunk يدعونا إلى اتخاذ إجراء جديد نتصل فيه بآخر طلب إجراء غير متزامن ، حيث يتم إجراء عمليتين إضافيتين (على سبيل المثال) التكرارات نفسها. إنه ينم عن الوعد وعادة ما يبدو فوضويًا ، ومن حيث المبدأ ، غير مريح للاستخدام (الكثير من الأعشاش) ، بالنسبة لي
  
  

وحدات css / المكونات المصممة

غالبًا ما أرى في المشروعات أن الأشخاص يكتبون قواعد لمكونات التصميم في بعض وحدات css الشائعة.



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

إعادة تحديد

المختارون لديهم عدة أهداف:

• , . , , ( , ). , , . - getFilteredItems,
• ,
• . - . - . friends. , . , . , , friends contacts. reselect , , . — .

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

المكونات والحاويات

في الأسلوب الكلاسيكي لـ React (بدون استخدام المكتبات لتخزين المخزن ككيان منفصل) ، هناك نوعان من المكونات - مكونات العرض ومكونات الحاويات. عادة (كما أفهمها) هذا ليس تقسيم مجلد صارم ، بل تقسيم مفاهيمي. مكونات



العرض غبية. في الواقع ، هم فقط تخطيط وعرض البيانات التي تم إلقاؤها فيها كدعامات. (يمكن العثور على مثال لمثل هذا المكون أعلاه في وحدات css)



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



مثال + -مكون الحاوية:







حاويات إعادة الإرسال هي ، في الواقع ، طبقة بين جانب redax ومكونات التفاعل. في نفوسهم ، نسمي المحددات ونرمي الإجراءات في دعائم رد الفعل للمكون.



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



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



أود أيضًا أن أعطي مثالًا أكثر تكرارًا لصالح وضع معظم المكونات في حاويات.



لدينا مجموعة من البيانات (مجموعة من المستخدمين ، على سبيل المثال) ، والتي نتلقاها من بعض API. لدينا أيضًا لفيفة لا نهائية ، والتي لن يرفضها العميل. قمنا بالتمرير لأسفل لفترة طويلة جدًا وقمنا بتحميل حوالي 10 آلاف + بيانات. والآن قمنا بتغيير بعض الخصائص لمستخدم واحد. سيتباطأ تطبيقنا كثيرًا للأسباب التالية:

1. قمنا بإرفاق الحاوية العالمية بالصفحة بأكملها بقائمة المستخدمين
2. عند تغيير حقل واحد لعنصر واحد من مصفوفة المستخدمين ، يتم إرجاع مصفوفة جديدة مع عناصر ومؤشرات جديدة في مخفض المستخدمين
3. سيتم إعادة رسم جميع المكونات الموضوعة في شجرة مكون UsersPage. تضمين كل مكون مستخدم (عنصر مصفوفة)

كيف تتجنب هذا؟



نحن نصنع الحاويات

• مجموعة مع المستخدمين
• عنصر المصفوفة (مستخدم واحد)

بعد ذلك ، في المكوِّن ، الذي يتم تغليفه في حاوية "مصفوفة مع المستخدمين" ، نعيد حاوية "عنصر المصفوفة (مستخدم واحد)" مع المفتاح (الخاصية رد الفعل المطلوب) التي تم إلقاؤها هناك ، والفهرس



في حاوية "عنصر المصفوفة (مستخدم واحد)" في mapStateToProps ، نحن الثانية كوسيطة ، نأخذ الخاصين بالمكون الذي ترجع الحاوية (من بينها الفهرس). حسب الفهرس ، نسحب مباشرة من المتجر عنصرًا واحدًا فقط من المصفوفة.



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



مجموعة الحاويات:







العنصر الحاوية:







محدد العناصر:







إذا كانت هناك أي إضافات ، فسأقرأها بسرور في التعليقات.