كيف يمكنني تغيير الترتيب الذي يقوم به Meteor بتحميل ملفات Javascript؟

Question

عندما تقوم بإنشاء مشروع باستخدام إطار عمل Meteor، فإنه يجمع جميع الملفات معًا، ولكن لا يبدو أن هناك طريقة للقول صراحةً "أريد أن يتم تحميل هذا الملف قبل هذا الملف".

لنفترض، على سبيل المثال، أن لدي ملفين جافا سكريبت: foo.js و bar.js.

الملف bar.js يحتوي في الواقع على رمز يعتمد على الكود الموجود بداخله foo.js ولكن يتم تحميل النيزك bar.js قبل foo.js, ، كسر المشروع.

• في Node.js أود ببساطة استخدام require('./bar') داخل foo.js
• في ال browser, ، أود أن أضع أ <script> علامة تشير إلى foo.js وآخر، بعد، مشيرا إلى bar.js, ، لتحميل الملفات بالترتيب الصحيح.

كيف يمكننا أن نفعل ذلك في نيزك?

Answer 1

وفقًا لوثائق Meteor، يتم حاليًا تحميل الملفات بالترتيب التالي:

1. يتم تحميل الملفات الموجودة في [project_root]/lib أولاً
2. يتم فرز الملفات حسب عمق الدليل.يتم تحميل الملفات الأعمق أولاً.
3. يتم فرز الملفات حسب الترتيب الأبجدي.
4. تم تحميل ملفات main.* أخيرًا.

مصدر:http://docs.meteor.com/#structuringyourapp

Answer 2

لا يعد هذا حلاً لجميع السيناريوهات، ولكن أعتقد أنه من الأفضل أن يتم وضع أي شيء يعتمد على تعليمات برمجية أخرى في وظيفة Meteor.startup، لضمان تحميل كل شيء بالفعل.

Answer 3

يمكنك دائمًا استخدام محمل JS مثل yepnope.js وإضافته إلى ملفclient.js.هذا يعمل بالنسبة لي.

Answer 4

لدي مجموعة من الوظائف المساعدة التي قمت بتنظيمها ضمن مساحة الاسم المشتركة (js global).

أي.

// utils/utils.js
Utils = {};

ثم في المجلدات الفرعية:

// utils/validation/validation.js
Utils.Validation = {};

// utils/validation/creditCard.js
Utils.Validation.creditCard = ... // validation logic etc

لدي أيضًا مجموعة من التعليمات البرمجية التي تستخدم Utils وكائناتها الفرعية.

من الواضح أن هذه البنية لا تعمل عندما يقوم Meteor بتحميل المجلدات الفرعية أولاً.

لجعله يعمل كما هو متوقع، اضطررت إلى إنشاء /subfolder/subfolder/subfolder بأسماء لا معنى لها، ثم دفع الكائن الجذر في معظم المجلدات الفرعية العميقة، والكائنات الفرعية في المجلدات الفرعية ليست عميقة جدًا.

إنه أمر غير بديهي للغاية بالنسبة لذوقي وعرضة للخطأ (لنفترض أن لديك مكونًا أعمق في بنية المجلد).

لمعالجة هذه المشكلة، استخدمت مكتبة Q مع التأجيلات والوعود.لا يزال الحل غير نظيف لأنه يجعلك تقوم بتكرار التعليمات البرمجية والتحقق منها بشكل روتيني ولكنه يمنحك التحكم الكامل في ترتيب التحميل دون العبث ببنية الدليل (مرحبًا للأشخاص الذين يقولون إنه يمكنك تنظيم كود النيزك كما تريد).

مثال:

//utils.js
UtilsDefer = UtilsDefer || Q.defer();
UtilsDefer.resolve({
    // here some root utils stuff
});

//cards.js
// here we'll depend on Utils but don't want to care about directory structure
UtilsDefer = UtilsDefer || Q.defer(); // it will be a) already 
// resolved defer from utils.js, or b) new defer that will
// be resolved later in utils.js
UtilsDefer.then(function(Utils) {
    // do something with utils usage, or for instance add some fields here
    Utils.CreditCardDefer = Utils.CreditCardDefer || Q.defer();
    Utils.CreditCardDefer.resolve({
        // Credit card utils here
    })
});

//someOtherFile.js
// it will be pain to use sub-objects with this method though:
UtilsDefer = UtilsDefer || Q.defer();
UtilsDefer.then(function(Utils) {
    Utils.CreditCardDefer = Utils.CreditCardDefer || Q.defer();
    Utils.CreditCardDefer.then(function(CreditCard) {
        // do stuff with CreditCard _if_ you need to do it on startup stage   
    })
});

هذا هو مثال لحالة الاستخدام الضيقة إلى حد ما، حيث أنك ستكون سعيدًا في الغالب بالتعامل مع هذه العناصر العالمية داخل بعض عمليات رد الاتصال لتفاعل المستخدم أو Meteor.startup حيث تمت تهيئة كل شيء بالفعل.بخلاف ذلك، إذا كنت تريد تحكمًا دقيقًا في أمر التهيئة في مرحلة مبكرة جدًا، فقد يكون هذا حلاً.