سلسلة SwiftUI 01｜الحدود المطبقة لـ SwiftUI

عندما تواصلت مع SwiftUI لأول مرة، كانت الأسئلة الأكثر شيوعًا هي:

• هل يمكن أن يحل محل UIKit؟
• هل يجب على جميع المشاريع الجديدة استخدام SwiftUI؟
• هل المشروع القديم يستحق النقل؟

هذه القضايا مهمة بطبيعة الحال، ولكن إذا تركزت المناقشة على “الاستبدال” منذ البداية، فإن الحكم غالباً ما يكون متطرفاً. السؤال الأكثر عملية سيكون:

ما هو نوع تعقيد الصفحة الذي يتعامل معه SwiftUI بشكل أفضل، وما نوع المشكلات التي لا يهيمن عليها بالضرورة؟

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

1. تكمن القوة الحقيقية لـ SwiftUI في أنها تضع “كيفية تعيين تغييرات الحالة في الواجهات” في المقام الأول

الفكرة الافتراضية لـ UIKit هي أشبه بما يلي:

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

فكرة SwiftUI الافتراضية أقرب إلى:

• الوضع الموجود مسبقا
• ثم قم بوصف “الشكل الذي يجب أن تبدو عليه الواجهة في هذه الحالة”

وهذا يعني أنه بطبيعة الحال أكثر ملاءمة للصفحات التي “يأتي التعقيد الرئيسي للواجهة من تعبير الحالة”. على سبيل المثال:

• إفراغ / تحميل / تحميل / تبديل الخطأ إلى الصفحة الواضحة
• صفحة النموذج
• صفحة الإعدادات
• عرض صفحة التفاصيل
• صفحة يتم فيها ربط عناصر واجهة المستخدم المتعددة معًا بناءً على مجموعة من حالات العمل

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

2. إنها مناسبة بشكل خاص لصفحات الأعمال حيث “تكون الحالة أكثر أهمية من تفاصيل التفاعل”

الصعوبة الحقيقية في العديد من صفحات الأعمال هي:

• ما هو الوضع الحالي؟
• ما يجب عرضه في ولايات مختلفة
• ما هي المجالات التي يجب تغييرها معًا بعد إجراء تجاري معين؟

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

• مركز شخصي
• صفحة الإعدادات
• صفحة تفاصيل المادة
• صفحة نتائج البحث
• صفحة تفاصيل الطلب

نادرًا ما تتطلب مثل هذه الصفحات مستويات عالية من تنسيق التمرير أو تصميم الإيماءات، ولكنها تتضمن الكثير من:

• تبديل الحالة
• العرض المشروط
• مزيج المكونات
• تحديث جزئي

هذه الأشياء هي المكان الذي يكون فيه SwiftUI مفيدًا للغاية.

3. كما أنها مناسبة جدًا للصفحات التي تحتوي على “تكرار سريع وتغييرات متكررة في واجهة المستخدم”

هذا مهم جدًا في الفرق الحقيقية.

لا تحتوي بعض الصفحات على تغييرات متكررة في المنتج:

• مراجعة كتابة النصوص
• التغيرات الهيكلية
• تغيير ترتيب البطاقات
• تغيير حالة العرض لوحدة معينة

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

لذا، إذا كانت الحقيقة بالنسبة للفريق هي أن “الصفحات تتغير بشكل متكرر”، فغالبًا ما تكون واجهة SwiftUI جذابة للغاية.

4. لكن SwiftUI ليس مناسبًا بشكل طبيعي لجميع “الصفحات المعقدة”

وهذه أيضًا هي النقطة التي يجب توضيحها أكثر من غيرها.

من المواقف الشائعة أنه عندما تسمع “SwiftUI أكثر حداثة”، فسوف تساويها دون وعي مع “جميع الصفحات أكثر ملاءمة”. لكن في المشاريع الحقيقية، يأتي تعقيد الصفحات المعقدة من مصادر مختلفة.

إذا كانت الصعوبة الأساسية للصفحة هي:

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

إذن قد لا يكون SwiftUI أسهل بشكل طبيعي.

هو:

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

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

5. حكم أكثر عملية: هل الصعوبة الأساسية للصفحة هي “التعبير عن الحالة” أم “التحكم الأساسي”؟

هذه هي الطريقة الأكثر شيوعًا للحكم.

إذا كانت الصعوبة الأساسية للصفحة هي:

• كيفية تعيين حالات عمل متعددة للواجهة
• كيفية دمج المكونات بشكل طبيعي مع تغير الحالة
• كيفية الحفاظ على بنية الصفحة واضحة

ثم غالبًا ما يكون SwiftUI مناسبًا.

إذا كانت الصعوبة الأساسية للصفحة هي:

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

يميل UIKit إلى أن يكون أكثر استقرارًا، أو على الأقل أكثر “قابلية للتحكم”.

هذا الحكم ليس مطلقًا، لكنه عملي بدرجة كافية في المشاريع الحقيقية. يمكنه توجيه الاختيار اليومي بشكل أفضل من السؤال “هل يمكن لـ SwiftUI استبدال UIKit؟”

6. الإستراتيجية الأكثر واقعية في المشاريع القديمة هي عادة “الخلط حسب الحدود”

إذا كان المشروع يحتوي بالفعل على بنية UIKit ناضجة، فإن المشكلة الأكثر احتمالا هي “مخيلة الترحيل المثالية المفرطة”.

في المشاريع الحقيقية، عادةً ما يكون المسار الأكثر شيوعًا والأكثر استقرارًا هو:

• استخدم SwiftUI أولاً للصفحات الجديدة
• صفحات UIKit الثابتة لا يمكن تغييرها بسهولة
• خلطه عند الحاجة
• لا تسعى إلى الهجرة الكاملة دفعة واحدة

لأن تكاليف الهجرة بحد ذاتها هي تكاليف أعمال. إذا لم يحقق تبديل إطار العمل فوائد واضحة وكان فقط لغرض “توحيد المكدس”، فمن المحتمل أن يفوق المكسب الخسارة.

7. سوء فهم شائع: التعامل مع SwiftUI على أنه “نسخة مطورة من UIKit”

عندما تعلمت هذه القطعة من SwiftUI لأول مرة، كنت لا أزال أطرح هذه الأسئلة في ذهني:

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

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

ويتطلب تحديد أولويات التفكير في:

• من المسؤول عن الوضع؟
• كيفية تعيين هذه الحالة لواجهة المستخدم
• هل تحديث الواجهة جزء من تدفق الحالة؟

بمجرد استمرارك في استخدام تفكير UIKit، يمكن أن ينتهي الأمر بـ SwiftUI بسهولة إلى أن تصبح “تصريحية على ما يبدو، ولكن في الواقع المنطق أكثر إرباكًا”.

8. الخلاصة: لا يعتمد ما إذا كانت SwiftUI مناسبة أم لا على ما إذا كانت جديدة أم لا، بل يعتمد على مصدر تعقيد الصفحة.

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

يعد SwiftUI أكثر ملاءمة للصفحات التي يأتي تعقيدها الأساسي بشكل أساسي من تعبير الحالة ومجموعة الواجهة وتكرار التكرار؛ وبالنسبة لتلك الصفحات التي يأتي تعقيدها بشكل أساسي من التفاعل الأساسي والتحكم الدقيق، فقد لا تكون هي المهيمنة بشكل طبيعي.

وبالتالي فإن الحكم العملي الحقيقي هو:

• ما المعقد في هذه الصفحة؟
• هل يمكن لـ SwiftUI تحقيق هذا النوع من التعقيد؟

بمجرد الإجابة على هذا السؤال بوضوح، لا يكون الاختيار عادةً مربكًا للغاية.