Как изменить порядок загрузки файлов Javascript в Meteor?

когда вы делаете проект с Meteor framework, он упаковывает все файлы вместе, но, похоже, нет способа явно сказать: "я хочу, чтобы этот файл был загружен до этого".

допустим, например, у меня есть 2 файла javascript:foo.js и bar.js.

файл bar.js фактически содержит код, зависящий от одного внутри foo.js но Meteor загружается bar.js до foo.js, нарушая проект.

  • на узел.js я бы просто использовать require('./bar') внутри foo.js
  • на обозреватель, я бы поставил <script> тег, указывающий на foo.js и еще, после того, указывая на bar.js, чтобы загрузить файлы в правильном порядке.

как мы можем сделать это в Метеор?

46
dependencies javascript meteor require

4 ответов

согласно документации Meteor, файлы в настоящее время загружаются в следующем порядке:

  1. файлы в [project_root] / lib загружаются первыми
  2. файлы сортируются по глубине каталога. Сначала загружаются более глубокие файлы.
  3. файлы сортируются в алфавитном порядке.
  4. main.* файлы загружаются последними.

источник: http://docs.meteor.com/#structuringyourapp

62

Не решение для всех сценариев, но я думаю, что в идеале все, что зависит от другого кода, будет помещено в Метеор.функция запуска, чтобы убедиться, что все уже загружено.

2

вы всегда можете нам загрузчик JS, как yepnope.js и добавьте его к клиенту.файл js. Это работает для меня.

-2

у меня есть набор функций утилиты, которые я структурировал под общим пространством имен (JS global).

то есть

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

а затем в подпапках:

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

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

также у меня есть куча кода, который использует utils и его подобъектов.

очевидно, что эта структура не работает как подпапки метеорной нагрузки.

чтобы заставить его работать, как ожидалось, мне пришлось создать / подпапку/подпапку/подпапку / подпапку с бессмысленными именами, а затем засунуть корневой объект в большинство глубоких подпапок и объектов ветвей в подпапках не так глубоко.

это чрезвычайно нелогично для моего вкуса и подвержено ошибкам (предположим, у вас есть компонент, который еще глубже в структуре папок).

чтобы решить эту проблему, я использовал библиотеку 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 где все уже инициализирован. В противном случае, если вы хотите мелкозернистый контроль над порядком инициализации на очень ранней стадии, это может быть решением.

-2