سلسلة SwiftUI 07｜تحويل التفكير من UIKit إلى SwiftUI

يتحول العديد من مطوري UIKit إلى SwiftUI لأول مرة. الجزء الأكثر إيلامًا ليس دائمًا ما يشعرون به:

• من الواضح أن واجهة برمجة التطبيقات (API) ليست معقدة
• ولكن لماذا يصعب الكتابة دائمًا؟

غالبًا ما يكون السبب هو أن نموذج التفكير الأساسي لم يتم تطويره بعد.

لأن UIKit يسأل بشكل افتراضي:

• ما هو العرض الذي أريد إنشاءه الآن؟
• متى سأقوم بتحديثه؟
• كيف أحافظ على توافقها مع البيانات يدويًا

SwiftUI أشبه بالسؤال:

• ما هو الوضع الحالي
• كيف يجب أن تبدو الواجهة في هذه الحالة؟
• كيف يجب أن يتم إعادة تنظيم الواجهة بشكل طبيعي عندما تتغير الحالة

وهاتان الفكرتان تشيران إلى أن موقف السيطرة قد تغير.

1. أول شيء يجب تركه هو “أنا أعتمد بشكل أساسي على برنامج التشغيل اليدوي الخاص بي لتحديثات الواجهة”

تدور العديد من التجارب في UIKit حول هذا:

• متى لإعادة التحميل
• متى يتم تعيين NeedsLayout
• ما رد الاتصال لتغيير عرض فرعي معين؟

يحتاج SwiftUI بالتأكيد إلى إدارة الحالة، ولكن ما يريد القيام به هو:

• إدارة مصادر الحالة
• إدارة حدود الدولة
• كيف يتم تعيين حالة الإدارة إلى واجهة المستخدم

بدلاً من الاستمرار في التركيز على “كيف أقوم بتحديث الواجهة يدويًا؟”

وإذا لم تتغير هذه العادة فإن الموقف الأكثر احتمالاً أن يحدث لاحقاً هو:

• يبدو أن SwiftUI مكتوب بأسلوب تعريفي
• ولكن لا يزال لدي المحرك الحتمي لـ UIKit في الاعتبار

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

2. الشيء الثاني الذي يجب وضعه هو التعامل مع العرض ككائن ثابت.

هذه هي العادة التي من المرجح أن يتبعها المطورون الذين لديهم خلفية UIKit افتراضيًا.

في UIKit، من الطبيعي التفكير في الصفحة أو الخلية على النحو التالي:

• كائن تم إنشاؤه
• سيتم تحديثه بشكل مستمر في المستقبل

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

هذا يعني أنك إذا بدأت دائمًا من “هذا العرض سيكون موجودًا دائمًا، سأستمر في تغييره”، فسيكون من السهل القيام بما يلي:

• حكم دورة الحياة
• موقع تخزين الحالة
• ربط المهام غير المتزامن

المزالق المتكررة حول هذه القضايا.

3. الشيء الثالث الذي يجب التخلي عنه هو الاعتماد المفرط على التصحيحات المحلية لإصلاح واجهة المستخدم.

المسار الشائع جدًا في تطوير UIKit هو:

• أولا طرح الرأي
• تصحيح ما هو خطأ
• إذا كان عنصر التحكم معطلاً قليلاً، فقم بتصحيحه محليًا.

هذه الطريقة ليست غير قابلة للاستخدام تمامًا في SwiftUI، ولكن إذا واصلت القيام بذلك، ستصبح الصفحة بسهولة:

• هناك الكثير من المعدلات
• التسلسل الهرمي الهيكلي غير واضح
• يؤدي إصلاح بسيط إلى تغيير تخطيط آخر

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

4. الشيء الرابع الذي يجب تغييره هو: التفكير بشكل أقل فيما يتعلق بـ “الضوابط” وأكثر فيما يتعلق بـ “تدفق الحالة”

في تفكير UIKit، تتمحور العديد من مؤسسات الصفحات حول التحكم:

-ماذا تظهر هذه التسمية؟

• ما إذا كان هذا الزر معطلاً
• متى سيتم إعادة تحميل هذا tableView؟

يشجع SwiftUI على البدء من تدفق الحالة:

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

يعد هذا التغيير أمرًا بالغ الأهمية لأنه يؤثر بشكل مباشر على:

• كيفية تصميم ViewModel
• كيفية تفكيك المكونات
• كيفية تحديد الحالة التي يجب مشاركتها والحالة التي لا ينبغي مشاركتها

5. الشيء الخامس الذي يجب تغييره هو: لا تتسرع في ترجمة كل تجارب UIKit إلى طريقة الكتابة المقابلة لـ SwiftUI

عندما تعلمت هذا المحتوى لأول مرة عن SwiftUI، كنت أطرح هذا السؤال دون وعي:

• ما هو هذا المعادل في UIKit؟
• أي رد اتصال يتوافق مع دورة الحياة هذه
• هل هذا السلوك يعادل إعادة تحميل البيانات؟

يعد هذا النوع من التعيين مفيدًا عند البدء، ولكنه قد يسبب مشكلة إذا تم الاعتماد عليه على المدى الطويل:

• ابحث دائمًا عن نظير UIKit
• لكنني لم أتقبل حقًا أن SwiftUI هي طريقة أخرى للتنظيم

عادة ما تكون نقطة التحول سهلة الاستخدام حقًا:

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

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

الشيء الأكثر فائدة هو تغيير الطريقة التي تطرح بها هذه الأسئلة أولاً:

ضع:

• متى أقوم بتحديث هذا العرض؟

التغيير إلى:

• ما هي تغييرات الحالة التي يجب أن تدفع تحديث المنطقة هذا

ضع:

• متى يجب تغيير هذه السيطرة؟

التغيير إلى:

• من يجب أن يمتلك هذه القيمة؟

ضع:

• هل تظهر هذه الصفحة مرة واحدة أم عدة مرات؟

التغيير إلى:

• ما هي الحالة أو دورة الحياة التي يجب أن ترتبط بها هذه المهمة؟

قد يبدو التغيير في طريقة السؤال هذه صغيرًا، لكنه سيسحب التفكير الافتراضي ببطء نحو SwiftUI.

7. الخلاصة: أهم شيء عند الانتقال من UIKit إلى SwiftUI هو إعادة وضع تفكير التحكم.

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

من UIKit إلى SwiftUI، ما يحتاج حقًا إلى التغيير هو من “سأقود الواجهة يدويًا” إلى “سأحدد الحالة والحدود، وأسمح بإنشاء الواجهة وفقًا للحالة.”

بمجرد أن يبدأ هذا في الحدوث، ظهرت العديد من الأشياء التي شعرت بها في الأصل مثل “لماذا يعتبر SwiftUI محرجًا للغاية؟” سوف تصبح طبيعية ببطء.