يبدو أن كلا المكونين يعيدان ترتيب div .contents في الرأس.
الهيكل بتخطيط كامل العرض:
الهيكل مع header-search:
لذلك لا يمكنني استخدامهما معًا. ولكن لست متأكدًا من أفضل مكان لإصلاح هذا؟
3 إعجابات
لقد واجهت هذه المشكلة بالضبط مع هذين المكونين الأسبوع الماضي… إنها صعبة بعض الشيء لأنني كنت أنوي أن يكون المكون كامل العرض تجربة مؤقتة، ولكن ليس لدينا شيء في خارطة الطريق لدمجه افتراضيًا، لذا فهو باقٍ لفترة أطول مما توقعت.
المكون كامل العرض ليس مثاليًا لأنه يتطلب تغيير قالب الرأس (الطريقة الوحيدة التي تمكنت بها من التغلب على بعض مشكلات التخطيط).
للوهلة الأولى… لا أعتقد أن تجاوز القالب في مكون البحث في الرأس ضروري، لذا يمكنني النظر في نقله إلى مزخرف ودجات (widget decorator)، مما سيتجنب المشكلة.
4 إعجابات
ما جربته كحل مؤقت هو عدم تغيير عنصر واجهة المستخدم header-contents في المكون كامل العرض. لذلك، لا يتم تجميع تبديل الشريط الجانبي والعنوان تحت __toggle-and-logo. ثم قم بترتيب كليهما في منطقة تبديل الشبكة. لم أواجه مشاكل في التخطيط مع هذا حتى الآن. لكن ربما فاتني شيء ما؟
أعتقد أنه شائع جدًا. لدي ثلاثة مشاريع تخصيص حالية، وكلها اختارت العرض الكامل. هذا أيضًا سبب نشري لهذا، أفضل عدم تعديل المكونات الرسمية لتحقيق ما يبدو أنه خيار شائع.
إعجابَين (2)
إذا كنت أتذكر بشكل صحيح، فإن الغلاف الإضافي يجعل من السهل محاذاة العنوان مع محتوى الموضوع لأنني أستطيع تعيين عرض .header-contents__toggle-and-logo المدمج إلى var(--d-sidebar-width)، وهو بنفس عرض الشريط الجانبي بغض النظر عن المحتوى.
بدون الغلاف الإضافي، يكون التصميم قابلاً للتطبيق… ولكن مع عمودين شبكيين لا يمكنني الاعتماد على عرض واحد لكليهما.
أحتاج إلى افتراض أن تبديل الشريط الجانبي سيكون دائمًا بعرض ثابت، ثم حساب أقصى عرض للشعار بناءً على ذلك. هذا يعمل، ولكني أتذكر أنه كان أكثر هشاشة… لم أنظر في هذا منذ فترة، ولكن ربما يستحق محاولة أخرى 
بالعودة إلى هذا… يمكنني أن أرى لماذا تم ذلك بتجاوز. بدون ذلك، عليك تزيين ودجات العنوان أو الرأس، لذلك ينتهي بك الأمر بإضافة محتوى داخل .title أو .panel، مما يجعل المحاذاة المركزية لشريط البحث أكثر صعوبة… ويتطلب بعض CSS الذي يجعل التصميم أكثر هشاشة ويجعل التوافق مع مكونات الرأس الأخرى أصعب. من الناحية المثالية، يجب أن يكون محتوى شريط البحث خارج هذه الأقسام، ولكن لا يوجد شيء يمكن ربطه للقيام بذلك.
يمكننا الآن إضافة منفذ إضافي للودجات، لذلك يمكن أن يساعد ذلك…
سيسمح هذا بإضافة محتوى قبل قسم .panel، بدلاً من داخله باستخدام decorateWidget. في هذه الحالة، يمكن إزالة تجاوز القالب من مكون header-search، ويمكن إضافة موصل جديد إلى:
javascripts/discourse/connectors/before-header-panel
والذي يمكن أن يحتوي على
<MountWidget @widget="search-banner" />
إضافة منفذ إضافي إلى ودجت حتى نتمكن من إضافة ودجت إلى منفذ إضافي يبدو معقدًا بعض الشيء… @david/@cvx هل تعرفون ما إذا كان هذا سيكون سيئًا للأداء أو يسبب أي مشاكل أخرى؟
إعجاب واحد (1)
بالمناسبة، إليك ما جربته كحل للمكون كامل العرض: https://github.com/discourse/discourse-full-width-component/compare/main...nolosb:discourse-full-width-component:header-contents
وهذا يعني:
- استخدام تخطيط القالب الافتراضي بدون عنصر
divإضافي حول التبديل وشعار العنوان - مطابقة العناصر مع مناطق الشبكة
ومع ذلك، أرى أن شعار العنوان يعود إلى الشعار الصغير عند عرض عناوين المواضيع في الرأس. يحدث هذا أيضًا هنا في meta في التخطيط كامل العرض. أنا لا أفهم حقًا وسائط القالب التي يجب استخدامها هنا لإظهار الشعار الكامل دائمًا.
حسنًا، فهمت، لقد وضعت كليهما في نفس منطقة الشبكة وطبقت هامشًا على الشعار… يبدو هذا حلاً وسطًا معقولاً!
لهذا السبب تم إعادة فتح home-logo هنا:
إذا لم يتم عرض الشريط الجانبي، فإنه يستخدم منطق الشعار الافتراضي للتبديل بين الكبير/الصغير… إذا تم عرض الشريط الجانبي، فإنه يعيد دائمًا الشعار الكبير.
إعجاب واحد (1)
قد يكون أبطأ قليلاً، لكنني لست قلقًا جدًا في هذه الحالة لأنه لا يوجد سوى مثيل واحد لمنفذ الإضافة في الصفحة (على عكس، على سبيل المثال، منفذ إضافة عنصر قائمة الموضوع الذي سيتم عرضه أكثر من 25 مرة).
تبدو إضافة منفذ هناك رائعة بالنسبة لي 
إعجاب واحد (1)
حسناً، لقد قمت بتحديث كلا المكونين لتجنب تجاوزات القوالب —
لذا يجب أن يعملا معًا الآن 
شكراً على الاقتراحات @manuel!
3 إعجابات