أعتقد أننا بحاجة إلى طريقة عامة للقيام بذلك، وهي طريقة مستقلة عن مكونات السمات - كما لدينا الآن.
لدي مكون سمة آخر يستخدم هذه التقنية:
لذلك هذا اثنان على الأقل من جانبي، وقد يكون هناك المزيد.
3 إعجابات
أتفق. لقد قمت ببناء مجموعة من مكونات الكتل، كل منها مستقل بذاته، بدلاً من تجميعها في حزمة واحدة: Blocks · GitLab.
في الوقت الحالي، يمكنني وضع هذه الكتل على صفحة رئيسية مخصصة باستخدام مكون كتل الصفحة الرئيسية الخاص بي، تمامًا كما يمكنني استخدامها مع كتل الشريط الجانبي الأيمن، أو على الأشرطة.
لقد قمت مؤخرًا بعمل تجربة على سمة Central حيث احتجت إلى تخطيط شريط جانبي مخصص. يمكنني بسهولة بناء إطار عمل للكتل لشريط جانبي مخصص ووضع مكونات الكتل عليه: https://central.kostka.studio (بالإضافة إلى وضع مكون Powered-by-discourse على الشريط الجانبي، فقط عن طريق الإشارة إليه بالاسم)
تعد مكونات الكتل المستقلة حقًا الأداة الأكثر فائدة لدي حاليًا لبناء تخصيصات العملاء بطريقة مرنة وقابلة للصيانة. سيكون من الرائع أن يكون هناك مسار عام لدعم ذلك.
3 إعجابات
أود أن أرفع هذا الموضوع لأنني أحاول معرفة أفضل طريقة للتعامل مع مكوناتي. حاليًا أرى خيارين لهما عيوب كبيرة: يمكنني إنشاء سجل لكل مكون سمة يعرض الكتل، ولكنه يهزم الغرض المعياري بالكامل. أو إضافة واحد عالميًا من خلال مكون إضافي، ولكن بعد ذلك تصبح مكوناتي معتمدة على تثبيت هذا المكون الإضافي.
لذلك يبدو أن وجود واجهة برمجة تطبيقات تسجيل كتل عالمية في النواة سيساعد حقًا. شيء يمكن لمكونات السمات استخدامه لاستدعاء عرض الكتل وتسجيل كتل جديدة أيضًا.
أحب العمل مع نهج الكتل لأنه يسمح لي بتقسيم الاهتمامات بين تخطيط التطبيق ومحتوى المكون. يتعامل مكون الكتلة فقط مع عرض محتواه، ثم يتم عرضه بواسطة مكون آخر في التطبيق. يمكنني إسقاط كل منطق المسار والمخرج من مكون الكتلة، ويمكنني بسهولة إعادة استخدام نفس الكتلة عدة مرات في تخطيط وحتى في جميع أنحاء التطبيق.
أجد أنه يجعل كل شيء أكثر رشاقة وقابلية لإعادة الاستخدام وهو نهج أنيق بشكل عام. سيكون وجود دعم قوي لهذا النمط في Discourse رائعًا.
4 إعجابات
ديفيد، هل سيكون من الممكن وجود واجهة برمجة تطبيقات تقديرية لتسجيل المكونات “عبر السمات/الإضافات” لاستخدامها في إضافة/مكون آخر؟
هذا من شأنه أن يتجنب تسجيل كل شيء ولكنه لا يزال يوفر المرونة لجعل ذلك ممكنًا بشكل صريح.
إعجابَين (2)
لست متأكدًا بشأن واجهة برمجة تطبيقات عامة لهذا. هناك الكثير من الطرق لاستخدام المكونات، ولكل منها توقعات مختلفة حول الوسائط وتوقيت التحميل.
بالنسبة لحالة الاستخدام الخاصة بك، هل سيعمل سجل خاص بالموضوع/الإضافة؟ مثل النموذج أعلاه للكتل الشريط الجانبي الأيمن؟
إذا لم يكن كذلك، فإن تقديم بعض الأمثلة الملموسة قد يساعدنا في تحديد نوع واجهة برمجة التطبيقات المطلوبة بالضبط. تم ترحيل جميع السمات والإضافات التي تحتفظ بها CDCK إلى gjs، وهذه ليست مشكلة واجهناها (باستثناء الحالات المحددة مثل كتل الشريط الجانبي الأيمن).
إعجاب واحد (1)
نعم، في الواقع، إعادة قراءة ما كتبته بعناية أكبر في مسودة طلب السحب (Draft PR) تقودني إلى الاعتقاد بأن هذا حل جيد بما فيه الكفاية، وتحديداً:
“يقدم هذا الالتزام قائمة مخصصة لمكونات Right Sidebar Blocks، ويسمح للمواضيع/الإضافات الأخرى بتسجيل مكونات إضافية.”
أعتقد أن هذا هو المفتاح - أن تكون قادرًا على التسجيل عن بُعد على أنه متوافق مع موضوع آخر والسماح للموضوع “الرئيسي” بدمج العناصر المسجلة عن بُعد هو بالضبط ما أبحث عنه، لذلك أعتقد أنك أوضحت بالفعل أن هذا ممكن.
إعجاب واحد (1)
رائع!
في الحالات البسيطة جدًا، قد تتمكن حتى من الاكتفاء بإضافة PluginOutlet في السمة “الرئيسية”، ويمكن للسمات الأخرى بعد ذلك استخدام renderInOutlet (أو وضع ملف في connectors/...).
إعجابَين (2)
صحيح أيضاً. ومع ذلك، أنا حقاً معجب بنمط التسجيل الخاص بك، إنه جميل جداً. سيكون من الجيد الاحتفاظ بالتوافق مع RSB في الواقع (يستخدم Bars بالفعل نفس نظام المعلمات) حتى يصبح النظام بأكمله قابلاً للتشغيل البيني (على الرغم من أن وجود مُهيئين اثنين قد يمثل تحدياً - أو قد لا تكون هناك حاجة إلى مُهيئ إضافي إذا كان بإمكاني إيقاف تشغيل طبقة تخطيط RSB حتى يمكن تحميل RSB بالكامل وإعادة استخدامه 
)