最近、私は自分の JavaScript アプリケーションの品質を向上させる努力をしています。
私が採用した 1 つのパターンは、別の「データ コンテキスト」オブジェクトを使用して、アプリケーションのデータをロードすることです (以前は、ビュー モデルで直接これを行っていました)。
次の例は、クライアントで初期化されたデータを返します。
var mockData = (function($, undefined) {
var fruit = [
"apple",
"orange",
"banana",
"pear"
];
var getFruit = function() {
return fruit;
};
return {
getFruit: getFruit
}
})(jQuery);
ほとんどの場合、サーバーからデータをロードするため、すぐに応答を返すことはできません。API でこれを処理する方法には、次の 2 つのオプションがあるようです。
- コールバックの使用
- 約束を返す。
以前は、常にコールバック アプローチを使用していました。
var getFruit = function(onFruitReady) {
onFruitReady(fruit);
};
// ...
var FruitModel = function(dataContext, $) {
return {
render: function() {
dataContext.getFruit(function(fruit) {
// do something with fruit
});
}
};
};
ただし、特に複雑な JavaScript アプリケーションを構築する場合は、コールバック地獄に陥る可能性があることがわかります。
その後、Promises デザイン パターンに出会いました。呼び出し元にコールバックを提供するよう要求する代わりに、観察できる「約束」を返します。
var getFruit = function() {
return $.Deferred().resolve(fruit).promise();
};
// ...
dataContext.getFruit().then(function(fruit) {
// do something with fruit
});
このパターンを使用する利点は明らかです。特に、wait複数の遅延オブジェクトを使用できるため、単一ページ アプリケーションの初期化データをロードするときに非常に便利です。
ただし、怒りでどちらかを使い始める前に、各パターンの長所と短所を理解したいと思っています. これが他のライブラリの方向性であるかどうかにも興味があります.jQueryの場合はそうです。
これは、テストに使用しているフィドルへのリンクです。