SwiftUI Series 06｜تقسيم مكونات SwiftUI وإمكانية صيانة التعليمات البرمجية

عندما يأتي موضوع “تفكيك المكونات”، أول رد فعل هو:

• هذا العرض طويل جدًا
• تقسيمها إلى عدة طرق عرض فرعية

هذه بالتأكيد البداية، ولكن إذا كان معيار التقسيم هو مجرد “عدد كبير جدًا من أسطر التعليمات البرمجية”، فمن السهل أن ينتهي الأمر بنوع آخر من الارتباك:

• هناك بالفعل المزيد من الملفات
• لكن علاقة الحالة أصعب في الفهم
• أصبحت أسماء المكونات مجردة أكثر فأكثر
• تمرير مجموعة من المعلمات بين الأب والابن

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

لذا فإن تقسيم المكونات الفعال حقًا هو:

اجعل حدود الهيكل وحدود الحالة وأعد استخدام الحدود أكثر وضوحًا في نفس الوقت.

1. التمييز أولاً: هل تقوم بتفكيك الهيكل أم إعادة استخدامه؟

ومن الشائع أن يختلط الأمران.

1. مقسم لسهولة القراءة الهيكلية

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

2. تقسيم لإعادة الاستخدام عبر الصفحات

الهدف هو استخراج المكونات القابلة لإعادة الاستخدام. يتطلب هذا النوع من الانقسام حدودًا أكثر استقرارًا وواجهات أكثر تقييدًا.

إذا لم يتم التمييز بين هذين النوعين من الأغراض، فإن النتائج الأكثر شيوعًا هي:

• من الواضح أنني أردت فقط أن أجعل الصفحة أكثر وضوحًا، ولكن انتهى بي الأمر باستخراجها قبل الأوان باعتبارها “مكونًا عامًا”
• أو أن هذا النمط تكرر مرات عديدة، إلا أنه ما زال يعتبر عرضاً فرعياً جزئياً

ولذلك، فإن الخطوة الأولى في تقسيم المكونات هي تحديد نوع المشكلة التي يتم حلها.

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

بمجرد أن تتناول الصفحة هذه الأشياء في نفس الوقت، فمن السهل التوسع بسرعة:

• هيكل التخطيط
• حالة واجهة المستخدم المحلية
• رسم خرائط حالة الأعمال
• تنسيق البيانات
• تجميع العمل التفاعلي

في هذا الوقت، ستجد أن الكود الطويل ليس هو السبب الجذري. المشكلة الحقيقية هي:

• ما المنطق الذي ينتمي إلى العرض
• ما هو المنطق الذي ينبغي أن يكون في الخارج
• ما هي الهياكل المحلية التي تستحق التعبير المستقل

القيمة الحقيقية لتقسيم المكونات هي فرض هذا الحكم الحدودي مرة أخرى.

3. عادةً ما تكون القطعة التي تستحق الإزالة أولاً هي “القطعة ذات الدلالات الأكثر اكتمالاً في الصفحة الحالية”

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

على سبيل المثال:

• منطقة رأس البيانات
• بطاقة ملخص المادة
• تعيين صف العنصر
• كتل فارغة

فوائد هذه الهياكل هي:

• هم في الأصل وحدة مستقلة في الصفحة
• الدلالات البنيوية ستكون أكثر وضوحا بعد إزالتها
• حتى لو لم تقم بإعادة استخدامها لفترة من الوقت، فلن تخسر المال

وهذا أكثر استقرارًا من محاولة ضخ “حاوية خلية عالمية فائقة” من البداية.

4. بمجرد إزالة المكونات، تصبح الواجهة مشكلة تصميم حقيقية

إحدى أعظم قيم تقسيم المكونات هي أنها تجبرك على التفكير في الواجهات.

سوف تكتشف قريبا:

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

إذا كنت لا تريد فهم هذه المشكلات بوضوح، فقد يصبح المكون بسهولة:

• الكثير من المعلمات
• دلالات تجارية غير واضحة
• الطبقة الأم تحتاج إلى معرفة كل شيء

لذا فإن تقسيم المكونات هو مهمة تصميم الواجهة.

5. رائحة كريهة شائعة جدًا: الخلط بين “تقسيم الهيكل الجزئي” و"تقسيم منطق الأعمال" معًا

على سبيل المثال، إذا تمت إزالة بطاقة قائمة، فستكون مسؤولة أيضًا عن:

• عرض التخطيط
• تنسيق البيانات
• دفن النقطة
• حكم الأعمال بعد النقر

ورغم أن هذا المكون مستقل، إلا أن مسؤولياته لا تزال مختلطة.

عادة ما يكون النهج الأكثر استقرارًا هو:

• يجب أن تركز مكونات العرض على العرض قدر الإمكان
• احتفظ بقرارات العمل في مستويات أعلى قدر الإمكان
• تكشف المكونات الفرعية الأحداث الضرورية دون ابتلاع عملية الأعمال بأكملها بشكل مباشر

وبخلاف ذلك، كلما تم تفكيك المزيد من المكونات، كلما أصبح المنطق أكثر تجزئة، لكن التعقيد لن ينخفض.

6. متى يجب ألا تتسرع في تدخين “المكونات العامة”؟

هذه هي النقطة التي يمكن فيها بسهولة الإفراط في تصميم العديد من مشاريع SwiftUI.

إذا ظهر النمط حاليًا مرة واحدة فقط على الصفحة، و:

• هيكل الأعمال ليس مستقرا بعد
• تفاصيل واجهة المستخدم لا تزال تتغير بسرعة
• لست متأكدًا من الحدود بعد

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

لأن “إعادة الاستخدام المبكرة” غالبًا ما تؤدي إلى نتيجة واحدة:

• تصبح واجهة المكونات واسعة جدًا
• لكي تكون متوافقة مع السيناريوهات المستقبلية المحتملة، تم تضمين العديد من الخيارات أولاً

والنتيجة هي أن صيانته أصعب من عدم تفكيكه.

7. حكم عملي: إذا تم إزالة هذا الهيكل الأساسي بمفرده، فهل يمكن للآخرين معرفة ما هو؟

هذه طريقة شائعة جدًا بالنسبة لي للحكم.

إذا تم إزالة بنية أساسية معينة، فمن الطبيعي أن يقول الجميع:

• هذا هو رأس ملف تعريف المستخدم
• هذا صف الإعدادات
• هذه بطاقة ملخص المقالة

ثم عادة ما تكون مناسبة للتفكيك.

فإذا أخرجته فلا يسعك إلا أن تقول:

• هذه “حاوية مركبة”
• هذا هو “عرض كتلة المحتوى”
• هذه “حافظة بطاقات متعددة المشاهد”

وهذا يعني على الأرجح أن دلالاتها ليست مستقرة بما فيه الكفاية، وربما لم يحن وقت الانقسام بعد.

8. الخلاصة: إن الهدف الحقيقي من تقسيم المكونات هو الحصول على حدود أكثر وضوحًا.

ولكي أختصر الأمر أقول:

المعيار الفعال حقًا لتقسيم مكونات SwiftUI هو أنه بعد التقسيم، تصبح حدود البنية وحدود الحالة وحدود الواجهة أكثر وضوحًا من ذي قبل.

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