共通の名前空間(jsグローバル)で構造化した一連のユーティリティ関数があります。
つまり
// 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を作成してから、最も深いサブフォルダーにルートオブジェクトを配置し、それほど深くないサブフォルダーにオブジェクトを分岐する必要がありました。
私の好みやエラーが発生しやすいのは非常に直感的ではありません(フォルダ構造がさらに深いコンポーネントがあるとします)。
この問題に対処するために、私はdefersとpromiseを備えたQライブラリを使用しました。ソリューションは、定期的なコードの繰り返しとチェックを行うため、まだクリーンではありませんが、ディレクトリ構造を台無しにすることなく、ロード順序を完全に制御できます(meteorコードを必要に応じて整理できると言う人にこんにちは)。
例:
//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
すべてがすでに初期化されている場所でこれらのグローバルを処理することに満足するでしょう。それ以外の場合、非常に早い段階で初期化順序をきめ細かく制御したい場合は、それが解決策になる可能性があります。