شكرًا لـ @david، أصبح لدينا نمط نظيف جدًا لتحميل ملفات JavaScript بشكل “استباقي” (eager) في السمات.
هذا يعني أنك ببساطة تضع ملفات *.js.es6 في مجلد javascripts، وستعمل تمامًا كما تعمل في الإضافات، وهذا أمر رائع.
على سبيل المثال، هكذا يمكنك الآن إنشاء مُهيئ (initializer) مع تطابق 100% مع الإضافات:
أنشئ ملفًا باسم /javascripts/discourse/initializers/my-init.js.es6
import { withPluginApi } from "discourse/lib/plugin-api";
function initialize(api) {
// init via api here
}
export default {
name: "discourse-otp",
initialize() {
withPluginApi("0.8.28", initialize);
}
};
هذه ميزة مهمة للغاية، لأننا نستطيع الآن تقسيم السمات الكبيرة والمعقدة إلى العديد من الأجزاء، والحصول على التحقق من الأخطاء (linting)، وإبراز بناء الجملة (syntax highlighting)، وكل المزايا الجيدة الأخرى.
ومع ذلك، في بعض الحالات، قد نرغب في إرسال حمولة JS بشكل اختياري.
على سبيل المثال، لنفترض أننا نقوم بتزيين المنشورات، ولكن فقط المنشورات التي تحتوي على تنسيق ماركداون محدد جدًا. لا فائدة من تحميل مكتبة متطورة بحجم 100 كيلوبايت حتى نعرف أننا سنستخدمها.
لقد وجدت حلًا لهذه المشكلة في مكوني بناءً على هذا التغيير الرائع:
باستخدام:
import loadScript from "discourse/lib/load-script";
function generateOtp($elem) {
loadScript(settings.theme_uploads.jsotp).then(() => {
// stuff goes here
});
}
هذا يعني أنني كنت بحاجة إلى:
إضافة .js إلى “الإضافات المأذون بها للسمة” (theme authorized extensions).
إضافة استثناء لسياسة أمان المحتوى (CSP) للأصل المحدد في “مصدر سكريبت سياسة أمان المحتوى” (content security policy script src).
تسمية الأصل في ملف about.json الخاص بي.
بصفتي كاتبًا لمكونات السمات، فإن هذا يمثل احتكاكًا كبيرًا جدًا، حيث لا توجد فرصة لك في منافسة التوزيع إذا كنت تتطلب هذا المستوى من المهارة الفائقة.
أفكر في جعل هذا قابلاً للاستخدام، وهناك بديلان يمكننا اختيارهما:
يمكننا تعليم النظام على تطبيق سياسة CSP تلقائيًا على أصول .js في السمات النشطة، والسماح افتراضيًا للسمات برفع ملفات .js.
يمكننا التحول نحو شيء يشبه javascript_cache الذي تستخدمه سمات JS غير المؤجلة (non-defer).
أنا أميل أكثر إلى الخيار الأول، لأن إضافة .js إلى الإضافات المأذون بها للسمة تبدو أمرًا تافهًا، وتطبيق سياسة CSP تلقائيًا لا يجب أن يكون مستحيلًا.
The ability to reference theme uploads in JS is a great addition!
This makes a lot of sense to me because anything you can do in a .js file can already be done in files in the javascripts folder of the theme. So, I don’t see any harm in allowing themes to have .js uploads by default.
إحياء هذا الموضوع لأن الشيء الوحيد المتبقي هنا هو تعليم CSP للسماح بتحميلات js الخاصة بالقالب. تم السماح افتراضيًا لملفات js كتحميلات للقالب لفترة من الوقت الآن.
إذا لم يتم حظر تحميلات js الخاصة بالقالب بواسطة CSP، فلن تحتاج المكونات مثل Image Annotator - Allows you to annotate images in the previewer إلى تحميل تبعياتها على الصفحة الرئيسية (~170 كيلوبايت مضغوط). هذا المكون، على سبيل المثال، سيحتاج فقط إلى تحميل تلك التبعيات إذا تم فتح المنشئ. بالإضافة إلى ذلك، لا يحتاج أبدًا إلى تحميلها للمشاهدين المجهولين.
أيضًا، هذا التغيير “سيسمح” للقوالب بأن تحتوي على ملفات web worker التي يمكنها القيام ببعض العمليات الثقيلة خارج الخيط الرئيسي.
السماح في علامات الاقتباس أعلاه لأنك يمكن أن تحصل عليها كـ blobs، ولكن من الأفضل بكثير أن تكون في ملفات منفصلة بدلاً من العبث بـ javascript في سلسلة نصية.
لدي بعض الأخبار السارة هنا، إنها صعبة التنفيذ بعض الشيء ولكن في النهاية سندعم أصول JavaScript المحلية للحالات التي نريد فيها استخدام عمال الويب في مكونات السمات.
لا توجد طريقة أخرى نظيفة لتمرير هذا عبر CSP، وتقديم ملفات العامل من نفس النطاق يحل الثغرة الكبيرة هنا.
