الخنازير الثلاثة: كيفية تنظيم تطبيق React-Redux

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

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

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

ذا سترو هاوس: Standard Layout

في المشروع الأول ، كان الفريق بأكمله جديدًا على Redux. ولكي نكون صادقين ، كان Redux جديدًا على العالم (ركوب الموجة!). لقد لعبناها بأمان وذهبنا بتصميم قياسي ، كما هو موضح في مقاطع فيديو Egghead المدهشة (المجانية) من Dan Abramov.

/ SRC
  / مكونات
  / الحاويات
  /أفعال
  / مخفضات
  / الملاحم

هذا هو التصميم الواضح والتخطيط الذي يذهب إليه معظم الناس: قم بتجميع "النوع" نفسه من الأشياء معًا. إنها نقطة انطلاق رائعة ، ولكن عند العمل على التطبيقات الكبيرة ، يصبح من الواضح أن هذا التصميم لا يتغير. افترض أن لدينا تطبيق قائمة ToDo ونظر في المستخدم إضافة عنصر ToDo جديد. من المحتمل أن يكون لديك مكون ToDoItemList ، حاوية ToDoItemList ، إجراء ADD_TODO ، مخفض todoItems وإذا كنت بحاجة إلى إجراء مكالمات API لحفظ ToDos ، ملحمة ToDoList. هذا الكثير من الملفات المبعثرة حول قاعدة البيانات التي تعمل في النهاية على نفس المهمة. بالإضافة إلى ذلك ، هناك بعض الأشياء التي تنتمي إلى بعضها: لن تستخدم حاوية ToDoItemList مع مكون مختلف ، فهل يجب أن تعيش في أجزاء مختلفة من قاعدة البيانات؟

البيت الخشبي: مجموعة حسب الميزة

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

/ SRC
  / مكونات
    / PureComponent1
      index.js
      index.spec.js
      style.css
    / PureComponent2
      index.js
      index.spec.js
      style.css
    / PureComponent3
  /المميزات
    / feature1
      component.js
      container.js
      actions.js
      reducer.js
      saga.js
    / feature2
    / feature3

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

البيت الحجري: مجموعة حسب الوظيفة

ظهر تخطيط البيت الحجري بشكل أساسي عن طريق السماح لقاعدة الشفرات بالنمو بشكل طبيعي. من البداية ، قمنا بأدنى قدر ممكن من العمل فقط من أجل الميزة في متناول اليد ، إعادة تشكيل A LOT ، حرصنا كبيرًا على عدم التحسين في وقت مبكر جدًا ولم نقم بإضافة التجمعات والتجريدات إلا عند الحاجة. نحن الآن في 4 أشهر من المشروع وهذا هو ما توصلنا إليه:

/ SRC
  / مكونات
    / Component1
      index.js <- قد يكون مكونًا خالصًا أو مكونًا ملفوفًا في حاوية ، لا يهتم المستهلك بأي حال
      index.spec.js
    / Component2
    / Component3
  / مخفضات
    index.js
    / Reducer1
      index.js <- الإجراءات في نفس الملف مثل المخفضات
      index.spec.js
      someSideEffect.js <- نستخدم redux-loop هنا
    / Reducer2
    / Reducer3

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

لم أنتهي بأي حال من الأحوال من التطور مع البيت الحجري وأحب أن أسمع عن أفكار أخرى. إذا كان لديك نوع مختلف من المنزل (تخطيط المجلد) عن أي من المنازل المدرجة هنا ، فأعلمني :)

سعيد التكرار!