يا ديفيد، هل هناك خطط لوقف دعم مكونات “split” وملفات “.gjs” “non”؟
ربما نعم. يبدو أن ملفات js/hbs المنفصلة ستكون مدعومة بواسطة ember في المستقبل المنظور، ولكن قد يكون من المنطقي أن نتحرك مبكرًا لتبسيط أنظمة بناء السمات/الإضافات لدينا.
إذا قررنا إيقاف دعم hbs، فسنمر بجميع دورات الإيقاف والإعلانات العادية، لذلك لن يكون الأمر مفاجئًا.
بالنسبة للسمات/الإضافات التي تستخدم تكوين التدقيق القياسي الخاص بنا، تم حظر ملفات .hbs بالفعل، ولدينا أداة آلية للانتقال إلى gjs. لقد انتهينا تقريبًا من تحديث جميع السمات/الإضافات المملوكة لـ CDCK باستخدام هذه الأدوات.
5 إعجابات
فقط للتأكيد (حتى أتمكن من تعديل مكونات js/hbs الخاصة بي)، مكونات hbs غير مدعومة في الهيكل الأساسي للسمة، ويوصى بشدة بنقلها إلى gjs؟
تظل ملفات Hbs “مدعومة” (بمعنى أنها ستعمل، ولن نغير ذلك دون دورة إيقاف)
ولكن نعم، يوصى بشدة باستخدام .gjs للتعليمات البرمجية الجديدة، والبدء في ترحيل السمات والإضافات الحالية. سيفرض أحدث تكوين للتدقيق اللغوي في الهياكل العظمية هذه التوصية ما لم تختار إلغاء الاشتراك في القاعدة عن قصد.
3 إعجابات
آه، فهمت الآن. شكرا للتوضيح!
إعجابَين (2)
أعتقد على أي حال أن مكونات Glimmer يمكن أن تكون أسرع من 3 إلى 5 مرات، لذا فهي بالتأكيد ممارسة جيدة؟
3 إعجابات
مكونات Glimmer أسرع بكثير من المكونات الكلاسيكية، نعم!
لكن تنسيق ملف .gjs لا يعني بالضرورة أنه مكون Glimmer. لا يزال لدينا المئات من المكونات الكلاسيكية في النواة، والتي تم تحويلها الآن جميعًا إلى تنسيق ملف .gjs. (الأسماء مربكة، أعرف 
)
الـ codemod الذي نقوم بتشغيله يقوم فقط بتحويل تنسيق الملف من js/hbs → .gjs. لا يغير نوع المكون - سيكون ذلك شبه مستحيل لأتمتته بشكل مثالي.
4 إعجابات
منصف، ولكن غالبًا ما يستحق بذل الجهد إذا كنت في منتصف إعادة هيكلة يدوية.
3 إعجابات
يا إلهي. فقط عندما اعتقدت أنني بدأت أفهم.
إذًا لست الوحيد! 
هل هذا يجعله مكون Glimmer؟
وإذا كان الأمر كذلك؛ حتى لو كان مجرد قالب، فإن إضافة الفئة تجعله يعمل بشكل أسرع مما لو كان ملف .gjs يحتوي فقط على <template>كلماتي المهمة</template>؟
export default class MyCoolComponent extends Component {
إعجاب واحد (1)
هذا هو:
import Component from "@glimmer/component";
(والتوافق اللاحق مع معايير Glimmer.)
إعجابَين (2)
آها! لذا ستحتاج إلى التصريح عن الفئة لاستخدام الجزء المكون المستورد.
شكرا جزيلا!
3 إعجابات
مشكلتي الرئيسية هنا هي أنه في hbs يمكنني ببساطة الإشارة إلى مكون من مكون سمة آخر حيث أنني لست بحاجة إلى هذا الاستيراد الصريح. ولكن في gjs أحتاج إلى import وأنا لا أعرف كيف أشير إلى مكون معرف في مكون سمة آخر.
جميع التطبيقات الموجودة التي نظرت إليها إما أ) لا تزال تستخدم hbs أو ب) تستخدم حقنًا قائمًا على Javascript.
إعجاب واحد (1)
في هذه الحالة، أحصل على توصية eslint هذه:
والتي تقترح أنه يجب عليك فقط إضافة الفئة عندما تحتاج إليها، وإلا فإنها ستكون أبطأ بالفعل.
إعجاب واحد (1)
بترتيب تصاعدي للأداء:
-
مكون كلاسيكي:
import Component from "@ember/component"; export default class Blah extends Component { -
مكون Glimmer:
import Component from "@glimmer/component"; export default class Blah extends Component { -
مكون Glimmer مخصص للقالب فقط:
export default <template> ... </template>
بالضبط
لا يمكن للسمات حاليًا الاستيراد من سمات أخرى. حقيقة أنه كان من الممكن أن تكون هناك تبعيات بين السمات عبر آلية حل الأسماء السحرية لم تكن مقصودة حقًا
هل يمكنك التوسع في حالة الاستخدام الخاصة بك، ربما في موضوع آخر؟ إنه ليس شيئًا واجهناه (حتى الآن) لأي من سماتنا الخاصة.
3 إعجابات
أعتقد أنك فعلت… (right-sidebar-blocks).
في الأسبوع الماضي، كانت حالة الاستخدام الرئيسية الخاصة بي هي فرض ترتيب لمكونات سمات متعددة استخدمت نفس منفذ المكون الإضافي. بينما يتم تحميل ملفات CSS بترتيب أبجدي، يتم تحميل JavaScript لمكونات السمات بترتيب رقمي، لذلك انتهى بي الأمر بإزالة مكونات السمات وإعادتها بالترتيب الذي كنت أحتاجه ومحاولة تجنب جميع مشاكل CSS التي تسببها في نفس الوقت.
ثم اكتشفت أنه يمكنني ببساطة إزالة الموصل في كل منها وإنشاء مكون سمة جديد يحتوي على هذا في موصل واحد لمنفذ المكون الإضافي هذا:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
وهو ما يعمل بشكل جيد حقًا. وبعد ذلك فكرت "أوه، أحتاج إلى أن يكون هذا gjs لتجنب الاضطرار إلى إعادة القيام بذلك في غضون بضعة أشهر. وبعد ذلك 
إعجاب واحد (1)
لديك عميل أراد القيام بذلك أثناء انتقالهم إليك. لا أتذكر التفاصيل.
لقد قمت للتو بعمل نسخة من هذا لعميل حالي تم إطلاقه للتو. أرادوا إضافة نوعين آخرين من الكتل. حاولت أن يكون لدي سمة شقيقة قامت ببعض الأشياء CSS فقط ولكن في النهاية اضطررت إلى الاستسلام وعمل نسخة. لست متأكدًا تمامًا مما إذا كان يمكن أن تكون هناك طريقة أخرى.
إعجاب واحد (1)
لكن…
إعجابَين (2)
هذا خبر رائع، إلا أنني لم أفهم ذلك في وقت أقرب. أتذكر نوعًا ما رؤية ذلك وأتذكر أيضًا مناقشة المشكلة واقترح شخص ما أنني بحاجة إلى عمل تفرع (fork)، لكنني الآن متأكد تمامًا من أنني لست بحاجة إلى ذلك.
هممم … Discourse Bars 🍻 🍸 (a sidebar framework) … يستخدم نفس النظام ولم أواجه مشاكل.
النقطة الأساسية هي أنه يمكنك استخدام المكونات (Components) من مكونات السمات (Theme Components) أو الإضافات (Plugins) الأخرى (وهو يعمل)
يستخدم كل من right-sidebar-blocks و discourse-tc-bars محلل Ember للبحث عن المكونات بالاسم. يعمل هذا حاليًا، ولا يعتبر مهملًا.
في .hbs يتم ذلك مثل {{component \"some-name\"}}، وفي (g)js يمكن القيام بذلك مثل resolveRegistration(\"component:some-name\").
ولكن إذا كنا نتحدث على المدى الطويل هنا، فيجب أن نهدف إلى تجنب البحث عن المكونات في محلل Ember. بمجرد تمكين علامة “static invokables” الخاصة بـ Embroider، سيصبح المحلل فارغًا.
هذا هو الاتجاه الذي أعتقد أننا بحاجة إلى اتخاذه لـ right-sidebar-blocks، ومشاركة المكونات المماثلة عبر السمات/الإضافات:
5 إعجابات