كان هناك نقاش من شخص ما منذ فترة حول التطوير في ثيم مقابل مكون إضافي. بدأ جزء Rails من https://www.pfaffmanager.com/ في الاستقرار بشكل كبير، وما أود فعله هو نقل تطوير جزء Rails إلى مكون ثيم. هذا يعمل بشكل جيد إلى حد ما، والتغييرات في القوالب والمُهيئات في مكون الثيم تتجاوز المكون الإضافي كما هو متوقع. ولكن، التغييرات في javascripts/discourse/components/server-item.js.es6 في الثيم لا تتجاوز نفس الملفات في المكون الإضافي.
أفترض أنه يمكنني إزالة محتويات Ember بالكامل من المكون الإضافي وجعلها موجودة فقط في الثيم، ولكن هذا يبدو وكأنه عمل يوم كامل لنقل كل تلك الأجزاء واختبارها ودفعها إلى الخادم. هل يمكن أن أكون أغفل شيئًا بسيطًا؟ هل يجب أن أتحمل الأمر وأزيل بالكامل الأشياء التي أودها في مكون الثيم من المكون الإضافي؟ هل يجب أن أحتفظ بكل شيء في المكون الإضافي؟
إن وجود نفس الكود في كل من مكون السمة والإضافة يبدو غريبًا بعض الشيء بالنسبة لي - في رأيي، سيكون من الأفضل الاختيار بين مكون السمة/الإضافة، ثم الالتزام به بالكامل. تجاوز الملفات بأكملها ليس شيئًا نقوم به بأنفسنا، وليس شيئًا نوصي به. لتجاوز سلوك النواة/الإضافة، يجب أن يستخدم مكون السمة الخاص بك طرقًا مثل api.modifyClass.
أشك في أن السبب الجذري هنا هو أن وحدات ES6 الخاصة بالإضافة لها بادئات مختلفة عن وحدات النواة/السمة. عند تشغيل هذا على موقعك، أرى أن الوحدات لها البادئة plugin. أشك في أنه إذا قمت بتمكين مكون السمة، فسنرى إدخالًا آخر، ولكن ببادئة مختلفة.
أتفق بشكل عام، ومع ذلك، هناك بعض الحالات الاستثنائية:
عندما تفوق كمية التغييرات في جافاسكريبت بكثير التغييرات في الواجهة الخلفية، وفي هذه الحالة تكون مكونات الثيم طريقة رائعة لنشر واختبار الكود بسرعة.
عندما يمكن تقديم معظم الوظائف في مكون الثيم الأساسي، ولكن إضافة مكون إضافي تكميلي يمكن أن يضيف ميزات إضافية غير ممكنة في جافاسكريبت وحدها. أستخدم هذه التقنية في معاينات قوائم المواضيع، حيث يقوم المكون بمعظم ما يمكن للمكون الإضافي القيام به، ولكن إذا أضفت المكون الإضافي أيضًا، تحصل على بعض الأشياء الرائعة الإضافية.
ومع ذلك، فإن تجميع كل شيء في مكون إضافي منطقي لأنه يقلل من الارتباك بشأن التكوين والتثبيت ويحافظ دائمًا على كل شيء متزامنًا.
ولكن حتى في سيناريو المكون الإضافي + السمة الخاص بك، لن أقوم بتكرار كود Ember في كل من المكون الإضافي والسمة. لذلك سأحتاج إلى سحب معظم القوالب والمبادرات والمكونات على الأقل من المكون الإضافي وجعلها موجودة فقط في مكون السمة.
نظرًا لأنني الوحيد الذي سيتم الخلط بينه بشأن التكوين، فهذه ليست مشكلة كبيرة. أنا حقًا أحب فكرة أن أكون قادرًا على اختبار بعض الأشياء الجديدة في الواجهة الأمامية على الموقع المباشر عن طريق التبديل إلى الإصدار التجريبي من السمة.
القضية الأخرى التي أراها هي إجراء اختبارات qunit. (سأتظاهر بأنني أستطيع معرفة كيفية إضافة أي منها، وهي قضية أخرى تمامًا؛ أعتقد أن مشكلتي هي أنني لا أعرف كيفية تهيئة الاختبارات بالبيانات لعرض الأشياء…). أعتقد أنه إذا كان لدي اختبارات qunit في المكون الإضافي الخاص بي، فسيتم تشغيلها عندما أقوم بالدفع إلى github (لأنني متأكد من أنني رأيت فشل الاختبارات المعطلة الخاصة بي).
من الناحية الفنية، يجب أن يكون ذلك ممكنًا، لكن لا أعتقد أن لدينا أي سير عمل جاهز لـ GitHub actions للسمات بعد. يتم حاليًا إجراء عملية إعادة تنظيم لاختبار السمات (لانتقال ember-cli)، ولكن بعد ذلك، ربما سنتمكن من إضافة بعض قوالب سير العمل لاختبار السمات إلى GitHub - discourse/.github
السيناريو: أريد تجاوز قالب تم نشره في مكون إضافي. لكنني أريد تجاوز ذلك بطريقة يتم التحكم فيها بواسطة التعليمات البرمجية.
لذلك حاولت شحن القالب الجديد في مكون سمة. نفس الملف موجود في مكون إضافي (لكنه مختلف).
يبدو أن هذا يعمل في تثبيت السحابة التطويرية الخاصة بي ولكنه لا يعمل في تثبيت إنتاجي قياسي.
إذن، هل من العدل القول بأنه لا يمكنك التنبؤ بما إذا كان هذا سينجح أم لا مع القوالب؟ أي أن خط أنابيب الأصول بحيث لا يمكنك التنبؤ بأي “قالب” سيتم اعتماده نظرًا لعدم وجود أسبقية محددة مسبقًا أو يمكن التنبؤ بها؟
لقد كنت أعمل بافتراض غريب بأنه كان هناك تسلسل هرمي، شيء مثل:
أساسي
مكون إضافي
مكون سمة
تغييرات الموقع المحلية
وإذا وضعت “ملفًا” بنفس المسار والاسم في مستوى لاحق من هذا التسلسل الهرمي، فسيؤدي ذلك إلى تجاوز أي تعريف “سابق”.
لكن افتراضي ربما ليس آمنًا؟
هل الحل “المعبأ” الوحيد (باستثناء تغييرات الموقع المحلية) هو استنساخ المكون الإضافي وإجراء التغييرات مباشرة بداخله؟
سيكون ذلك مؤسفًا من بعض النواحي لأنه سيزيد من جهد الصيانة للتخصيصات حيث سيتعين عليك دمج التغييرات في المستودع الرئيسي للمكون الإضافي بشكل دوري …
أفضل طريقة هي تحديث المكون الإضافي الحالي وإعطائه منفذ مكون إضافي و/أو واجهة برمجة تطبيقات مخصصة يمكن لمكون السمة استخدامه.
كان تعليقي أعلاه يتعلق تحديدًا بتجاوز ملفات JavaScript بالكامل (أي وحدات ES6). هذا غير ممكن. يقوم خط أنابيب الأصول تلقائيًا بوضع بادئة لوحدات المكونات الإضافية/السمات باسم/معرف المكون الإضافي/السمة، لذلك من المستحيل إنشاء تعارض مع النواة.
بالنسبة للقوالب، نعلم أن الأشخاص (بما في ذلك نحن، في بعض المواقف) يتجاوزونها، لذلك سنحتفظ على الأرجح بهذا النظام يعمل. ولكن يرجى تذكر أنه اختراق. إذا تغير سلوك المكون/المتحكم الأصلي، فمن المحتمل أن يتسبب القالب الذي تتجاوزه في تعطل الموقع.
بشكل عام، أعتقد أن التسلسل الهرمي الذي ذكرته (النواة، المكون الإضافي، السمة) يجب أن يكون صحيحًا - لذلك إذا كنت ترى شيئًا مختلفًا، فيرجى مشاركة تفاصيل مسارات الملفات في المكون الإضافي والسمة.
