promise-test-helper azu/promise-test-helper という名前そのままですが、 Mocha等でPromiseのテストを書くときに見落としを減らすための補助ライブラリを書きました。 MochaのPromiseテストというのは、下記のようにpromiseオブジェクトを返すとそれをPromiseのテストと認識してやってくれる機構の事を言っています。 it("should support by mocha", function () { return getSuccessPromise().then(function (value) { assert(value); }); }); 詳しくは下記を見て下さい。 MochaがPromisesのテストをサポートしました | Web scratch Promiseのテストの難しさ Promiseのテストについてはazu
Promise Anti-patternsを翻訳させて頂きました。著者のtaoofcodeから許可を頂いて翻訳、投稿しています。 Promiseは一度理解してしまえば簡単だが、いくつか頭を抱えさせるパターンがある。ここにあるのは私が経験したいくつかのアンチパターンだ。 ネストされたPromise 君は複数のPromiseをネストする: loadSomething().then(function(something) { loadAnotherthing().then(function(another) { DoSomethingOnThem(something, another); }); }); 君がこれをする理由は、両方のPromiseの結果で何かをする必要があるからだ。then()は一つ前のPromiseの結果しかコールバックに渡せないのでここでチェインを用いることはできない。 だが
In my previous article I discussed the benefits of using dependency injection to make code more testable and modular. In this article I’ll focus on using promises within an AngularJS application. This article assume some prior knowledge of promises (a good intro on promises and AngularJS’ official documentation). Promises can be used to unnest asynchronous functions and allows one to chain multipl
Google Chrome Canary(正確にはV8)に、ついにGenerators(yield)が入った。これを上手に使うと、エラー処理を含む非同期コードを同期的に書くことができるようになり、見通しが極めて良くなるので、ここで紹介する。 ここで紹介するものはいずれNode.jsでも使用できるようになるので、Webとの互換性を気にする必要のないNode.jsでは近いうちに活用できるようになると思う。 下のコードを動かすためには、最新のGoogle Chrome Canaryで、chrome://flagsからexperimental javascriptを有効にしておく必要がある。 ES6 HarmonyのGenerator構文について functionではなくfunction*というキーワードを使うと、yieldキーワードが使えるようになる。 function* range(begin
AngularJSでは非同期処理のAPIとしてPromise API($q Service)が用意されています。 このPromise APIですがAngularJS v1.2でPromise/A+に準拠した形になりました。 Promise/A+の詳細については下記を参照してください。 Promise/A+ AngularJSのPromise APIは非同期処理としては最小限の機能しか用意されておらず、複雑な非同期処理を書く場合は何かしらのライブラリが利用したくなります。 非同期処理のライブラリとしてはJSDeferredやjQuery.Deferredなどが有名ですが、今回はRxJSを使ってみます。 Reactive Extensions for JavaScript (RxJS) RxJSもv2.2でPromise/A+に準拠したObservable.fromPromiseが追加されたの
Note Please consider using JavaScript promises instead of Q. Native promises are faster, have better tooling support and are the future. When work on Q began, promises were an academic novelty in JavaScript, unlikely to be adopted much less popular, though obviously full of…promise. Callbacks dominated the landscape. Q aimed to introduce a technology to JavaScript that had been proven and vetted i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く