سلسلة SwiftUI 12｜العلاقة بين SwiftUI والدمج والمراقبة

عندما علمت لأول مرة عن إدارة حالة SwiftUI، كنت سأشعر بالحيرة من هذه الكلمات في مرحلة ما:

• ObservableObject
• @Published -الجمع -الملاحظة

السؤال هو عادة:

• جميعها مرتبطة بـ “تغييرات الحالة ستؤدي إلى تحديثات الواجهة”
• ولكن ليس في نفس الطابق

إذن ما يجب توضيحه حقًا هو:

• من يملك الوضع
• كيف يتم ملاحظة التغيرات
• كيفية تمرير الملاحظة إلى الواجهة

1. الجمع والملاحظة لا يجيبان حقًا على الأسئلة في نفس المستوى.

الموقف الشائع هو مقارنتها مباشرة كعلاقات بديلة. لكن الفهم الأكثر عملية هو:

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

بمعنى آخر، لدى Combine وعي أوسع بالمشكلة، والمراقبة أقرب إلى “كيفية تعقب حالة الواجهة وتحديثها”.

2. ما تحتاجه العديد من الفرق حقًا هو عدم إفساد سلسلة نشر الحالة أولاً.

المشاكل الأكثر شيوعًا في المشاريع الحقيقية هي:

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

في هذا الوقت، بغض النظر عن الاسم المستخدم للطبقة السفلية، سيتم العبث بالصفحة بسهولة.

3. الحكم العملي: المطلوب الآن هو “مراقبة الحالة من خلال الواجهة” أو “دمج تدفق الحدث ومعالجته”

إذا كان اهتمامك الرئيسي هو:

• تغييرات حالة الصفحة
• تحديث ViewModel
• يتم تحديث واجهة المستخدم بالحالة

عادة ما يكون أسلوب الملاحظة أكثر طبيعية.

إذا كنت قلقًا أكثر بشأن:

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

لا يزال وعي شركة Combine بالقضايا ذا قيمة.

4. الخلاصة: قم أولاً بتسوية حدود الدولة، ثم تحدث عن آلية المراقبة المحددة

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

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

عندما تكون الحدود واضحة، سيكون اختيار التكنولوجيا أكثر وضوحا؛ عندما تكون الحدود غير واضحة، فإن تغيير أي آلية لن يؤدي إلا إلى تغيير الاسم واستمرار الفوضى.