سلسلة SwiftUI 02｜مقدمة لنظام تخطيط SwiftUI: VStack، وHStack، وZStack، وSpacer، والإطار

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

• VStack أستطيع
• HStack سأفعل ذلك أيضًا
• يبدو أن Spacer يفهم
• يكتب frame أيضًا كثيرًا

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

• هذا المنظر غير كامل
• تمت إضافة frame ولكن لم تتم محاذاته بعد
• Spacer بمجرد وضعه، سوف يزاحم الأشياء الأخرى.
• بعد عدة مستويات من التداخل، “لا تستطيع الصفحة تحديد ما هو الخطأ، ولكنها لا تبدو صحيحة”

يوضح هذا أننا في كثير من الأحيان لا نفهم حقًا ما يفعله تخطيط SwiftUI.

1. أهم شيء في تخطيط SwiftUI هو عملية التفاوض على الحجم

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

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

بمعنى آخر، التصميم عبارة عن مفاوضات مستمرة بين الأب والابن.

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

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

2.VStack, HStack, ZStack الفرق الحقيقي هو “من يقود منطق المواضع”

على السطح:

• VStack مرتبة رأسياً
• HStack مرتبة أفقيا
• صفوف مكدسة ZStack

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

الفهم العملي أكثر هو:

• ينظم VStack بشكل أساسي العناصر الفرعية عموديًا
• يقوم HStack بتنظيم العناصر الفرعية بشكل أفقي
• يقوم ZStack بشكل أساسي بتجميع عناصر متعددة في نفس المنطقة

النقطة الأساسية هي التفكير بوضوح:

• ما هو المحور الأساسي للصفحة الحالية؟
• ما هي الطبقة المسؤولة عن التخطيط الرئيسي -أي طبقة هي فقط المحاذاة والديكور المحلي

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

3. قيمة Spacer هي “تناول المساحة المتبقية”

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

هذا يمكن أن يؤدي إلى الكثير من سوء الاستخدام.

بتعبير أدق، ما يفعله Spacer هو:

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

على سبيل المثال، في HStack، فإنه يأكل المساحة الأفقية؛ في VStack، فإنه يأكل المساحة العمودية.

بمجرد فهم هذه الطريقة، يصبح من الأسهل الحكم على:

-هل من الضروري أن يكون هناك تباعد ثابت أو تخصيص المساحة المتبقية؟

• هل يجب استخدام padding أو Spacer هنا؟
• Spacer إذا تم وضعه في الموضع الخاطئ، فسيتم إزاحة مركز ثقل المخطط بأكمله.

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

4. من السهل إساءة فهم frame: فهو ليس بالضرورة “تعديل حجم المحتوى”، ففي كثير من الحالات يقوم فقط بتغليف طبقة من مربعات التخطيط

هذه واحدة من أسهل النقاط التي يمكن أن يتعثر فيها مبتدئو SwiftUI.

الموقف الشائع هو كتابة:

Text("Hello")
  .frame(maxWidth: .infinity)

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

وهذا ما يفسر العديد من الالتباسات الشائعة:

• يبدو أوسع، لكن النص لا يزال غير محاذٍ للمكان الذي أريده أن يكون فيه.
• فقط استخدمه مع alignment
• نفس frame له تأثيرات مختلفة على طرق عرض مختلفة

ولذلك، فإن مفتاح frame ليس “تغيير الحجم”، ولكن “ما هي حدود التخطيط التي تتم إضافتها إلى العرض”.

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

لنأخذ نمطًا مضادًا شائعًا جدًا:

• طبقة خارجية واحدة VStack
• توجد عدة طبقات داخل HStack
• أضف frame إلى كل طبقة
• امزج المزيد من Spacer
• وأخيرًا، اعتمد على padding لإصلاحه حتى تتمكن من رؤيته.

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

غالبًا ما يكون جذر المشكلة:

• ما هي الطبقة المسؤولة عن الهيكل الرئيسي
• ما هي الطبقة المسؤولة عن المحاذاة المحلية -أي طبقة هي مجرد تعديل بصري؟

لا يوجد طبقات.

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

6. طريقة أكثر عملية للتفكير في التخطيط: حدد أولاً المحور الرئيسي، ثم حدد المساحة المتبقية، ثم حدد المحاذاة المحلية

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

1. هل تهيمن هذه المنطقة أفقيًا أم رأسيًا؟
2. لمن يجب أن نترك المساحة المتبقية؟
3. ما هي الأماكن التي تتطلب مسافات ثابتة وما هي الأماكن التي تتطلب مساحة مرنة.
4. ما هي المناطق المتوافقة محليًا فقط والتي يجب ألا تؤثر بدورها على الهيكل العالمي.

يمكن أن يؤدي هذا الأمر إلى تقليل حالة “المزيد من الإصلاحات والمزيد من الفوضى” بشكل كبير. لأنه يفرض عليك تحديد البنية أولاً ثم تحديد التعديل، بدلاً من الاعتماد فقط على المُعدِّل لتجميع النتائج.

7. العديد من صفحات SwiftUI “تبدو دائمًا أسوأ قليلًا”

تحدث العديد من مشكلات الصفحة في الواقع بسبب عدم وضوح التعبير عن البنية.

تشمل المظاهر الشائعة ما يلي:

• العلاقة بين كتل المعلومات ليست مستقرة بما فيه الكفاية -طالما أن النص طويل فسوف يزاحم الأشياء الأخرى.
• نفس البطاقة لها أبعاد غريبة على شاشات مختلفة

غالبًا ما تكون مثل هذه الأسئلة:

• منطق تخصيص المساحة غير واضح
• يتم خلط محور التخطيط الرئيسي والتعديلات المحلية
• المكان الثابت غير ثابت
• تم تدوين المرونة مرة أخرى

لذلك، لتعلم التخطيط حقًا هو تعلم الحكم على كيفية تخصيص المساحة.

8. الخلاصة: ما تحتاج حقًا إلى تعلمه عند البدء في تخطيط SwiftUI هو التفاوض بشأن المساحة بدلاً من أسماء التحكم.

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

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

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