EntityManager
$q でそよ風プロトタイプにモンキー パッチを適用しないでください。それを行うと、保証を破ることになります。ただしないでください。
Breeze はプロミスにQ.jsを使用し、Q は CommonJS に準拠しています。Q は確固たる約束の実装です。$q ... それほどでもありません。
$q が仕様に準拠していないと不平を言う必要がある場合$apply
は、特にテストで望ましくないことが多い副作用である呼び出しが正確に行われるためです。私を始めさせないでください。
そのfail
方法は、単にQシュガーであり、then
. 私たちはその読みやすさが好きで、それを使用しています。
fail
必要に応じて、 $q promise プロミスにメソッドを追加できます。ものすごく単純。のエイリアスに沿った何かthen(function(data){return data;}, failHandler)
内部でQ メソッドを使用するべきではなくfail
、代わりに Breeze コンポーネント内での promise の使用を CommonJS 仕様で特定されたメンバーのみに制限することもできます。私はその考えを内部に転送します。それは確かに Q の代替の可能性を促進するでしょう。個人的には、Breeze が Q のような優れたライブラリであっても、サードパーティのライブラリに依存していることを嫌います。
私を信じてください、私たちはこれを検討しました。クリアできないハードルが 1 つあります。ほとんどの promise 実装はがらくたです。
Breeze は、すべての条件下で、特に例外処理において適切に動作する promise ライブラリに依存しています。このドアを開けたら、人々は望む Promise ライブラリをプラグインし始めます...「then」メソッドを使用するものなら何でも。彼らの Breeze アプリは、不可解な早すぎる方法で壊れ始めました。Breeze はクソだという電話がかかってきます。
適切な例: jQuery。jQuery deferred は壊れた実装です。誰かがそれを Q の代わりに使用すると、Breeze アプリが壊れてしまいます。常にというわけではありません...これは、常に破損するよりも悪いことです。
$q
私はがらくたとは言いません。私はそれが不健全だと言います...そしてそれが常に$applyを呼び出す(または呼び出すのと同等のことをする)という理由だけではありません。
最初に言ったことをもう一度言いましょう: EntityManager
$q で Breeze プロトタイプにモンキー パッチを適用しないでください。
なぜそうしたいのか、想像がつきます。メソッドから返される promiseEntityManager
を $q promise にしたいとします。ごめん。悪いアイデア。
代わりに私の推奨事項に従ってください。Q.js への拡張機能を使用to$q
します(ドキュメントは準備中です)。これの代わりに、その後「インストール」するのは簡単です:
var QPromise1 = someQuery.using(manager).execute();
var QPromise2 = anotherQuery.using(manager).execute().then(成功、失敗);
あなたはこれを書きます:
var $qPromise1 = someQuery.using(manager).execute().to$q();
var $qPromise2 = anotherQuery.using(manager).execute().to$q(成功、失敗);
それはどれほど難しいですか?