問題タブ [bluebird]

Bluebird によって実行される 2 つのタスクがあります。

q.jsを使用すると、次のような応答がありました。

ということで、spread()パーツ内で各タスクの状態を確認することができました。
これはBluebirdの前に使用していたコードです

ブルーバードを使用すると、次のようになります。

私のタスクによって生成された配列だけを含みます。

必要だと思いますPromise.allSettledが、ドキュメントで見つけることができません。
各タスクの状態を取得するにはどうすればよいですか?

QI を使用すると、次の新しいプロミスを定義できます。

しかし、Bluebird を使用すると、次のようになります。

私は得る：

Q と同じ結果を得るにはどうすればよいですか?

これは私のコードのスニペットです:

コールバック更新クエリを素敵できちんとした約束に変換しようとしています..しかし、それは私を襲いました。そもそも約束する必要がありますか？

これが私の古いコールバック関数です。

これは確かに機能しますが、それは約束と同じくらい良いのでしょうか? プロミスは更新/挿入クエリで機能しますか? 以下の関数はエラーなしで機能していません。これにより、プロミスがデータベース データの更新または単に選択に使用されるのか疑問に思います。または、関数が壊れているだけで、エラーが壊れていませんか?

Bluebird で Promise を使用して Node.js コールバックをラップするにはどうすればよいですか? これは私が思いついたものですが、より良い方法があるかどうかを知りたいと思っていました:

エラーのみを返す必要がある場合、これを行うためのよりクリーンな方法はありますか?

編集 Promise.promisifyAll() を使用しようとしましたが、結果が then 句に反映されていません。私の具体例を以下に示します。私は 2 つのライブラリを使用しています: a) promise を返す Sequelize、b) node スタイルのコールバックを使用する supertest (http 要求のテストに使用)。promisifyAll を使用しないコードを次に示します。Sequelize を呼び出してデータベースを初期化し、HTTP 要求を作成して注文を作成します。両方の console.log ステートメントが正しく出力されます。

次に、呼び出しをチェーンできるように、promisifyAll を使用してみます。

2 番目の console.log に到達すると、res 引数が定義されていません。

私は何を間違っていますか？

これが私が見逃している単純なものであることを願っていますが、私が望むようにデータを返すことができないようです. 関数ログインはユーザー名を受け取り、認証用のパスワードと ID をデータベースからのユーザーの XY 座標と共に返します。

XY 座標は、ログイン クエリから返される ID に依存します。ID はすべてPromise、認証のためにメイン関数に返されます。ただし、すべてのデータを 1 つのうまく編まれたオブジェクトに戻すことはできません。

これはログに記録します:

パスワードは、戻り値ではなく、コンソール ステートメントからログに記録されます。返されるのはxy座標だけです。関数が返すのと同じ Promise でクエリ結果を返すにはどうすればよいですか?

Koa.js を使用して単純な REST API を構築しようとしています。これは ES6 ジェネレーター関数を使用しますが、これはコールバックよりもはるかに快適です (C# の async-await に似ています)。yield キーワードは、thenable (promise、thunk、generator) を想定しています。Bluebird の promisifyAll メソッドを使用してコールバック ライブラリ (私の場合は要求) を約束していますが、それでもエラーが発生し続けます。ここに私のコードとエラーがあります:

エラーのスタック トレース:

私は何が欠けていますか？

続行する前に、ユーザーが特定のリソースへのアクセスを許可されているかどうかを確認する必要があるルートを持つ Web アプリケーションを想像してください。「認証済み」チェックは、データベース呼び出しに依存しています。

各ルートで、次のことが考えられます。

authorizeOwnership()各ルートで明示的に処理する必要がないように、関数で 403 (アクセス拒否) および 500 (データベース クエリ エラーなど) の応答を処理する必要があります。

データベースにクエリを実行して所有権を確認できる機能があります。

これは次に使用されauthorizeOwnershipます。

このシナリオでは、意図的に一部のコード パスでreject()orを呼び出しません。その場合、エラーを処理する必要があるため (またはcheck inを使用して) resolve()、「外部」ルート ロジック ( を呼び出しているコードauthorizeOwnership()) がより複雑になります。.catch()null.then()

ただし、次の 2 つの点で少し緊張します。

• によって返された promiseauthorizeOwnership()がエラー シナリオで解決されなくても問題ありませんか? 遅延やメモリリークの原因になりますか?

• confirmOwnership()「一致するリソースが見つかりません」と言ってnullで解決し、それをエラーとして扱うのは論理的に正しいauthorizeOwnership()ですか? 私の最初の試行では、一致するリソースがない場合に promise を拒否しましconfirmOwnership()たが、これ (403 のケース) と実際のエラー (500 のケース) を区別するのが難しいため、事態はより複雑になりました。

私は Koa を使用して Web アプリを構築することを検討していますが、「非同期を簡単にする」さまざまなサポート技術/アプローチの中から選択し、適用する方法、時期、理由についてはよくわかりません (以下に記載されています）。

全体として、この主題に関する Web 上のさまざまなガイダンスは、特に進化するベスト プラクティス、または少なくともより優れたもの、およびどのようなシナリオであるかに関して、いまだに曖昧なままです。ウェブ上には、すべてを文脈に当てはめているものはほとんど、あるいはまったくないように思われます。

この大きなお尻の広がりのある投稿への反応がそれを修正できることを願っています. また、以下の質問は、誰かがこの問題に対処するための完全なブログ投稿などを書くきっかけになるかもしれません. 私の感覚では、その恩恵を受けるのは私だけではありません。

そのため、明るいコミュニティが、以下にリストされているテクノロジーに関する次の質問に答えて明確にするのに役立ちます (太字で示されています)。

-- a) どのように、またどのような状況で (該当する場合)、それらは相互に補完、補足、代替、および/または重複する解決策となりますか?

-- b) 速度性能、エラー処理の容易さ、およびデバッグの容易さに関して、それらのトレードオフは何ですか?

-- c) いつ、どこで、なぜ「あれ」よりも「これ」のテクノロジー、テクノロジーの組み合わせ、および/またはアプローチを使用する方がよいのでしょうか?

-- d) もしあれば、どの技術またはアプローチが「薄暗い星」である可能性がありますか.

（回答の一部である意見がうまく説明できることを願っています。）

==============================

テクノロジー:

*コア*

私の理解：

Koa は、ECMAScript-6 機能 (特にジェネレーターの機能の 1 つ) を利用するように調整された Node アプリをビルドするための最小限の基盤です。

* コ *

私の理解：

-- Co は、ECMAScript-6 ジェネレーター (Node .011 ハーモニーのネイティブ) を実行するためのユーティリティのライブラリであり、ジェネレーターを実行および管理するためのボイラープレート コードを作成する必要性をある程度 (?) 緩和することを目的としています。

-- Co は本質的に Koa(?) の一部です。

具体的な質問:

-- Koa での Co の使用方法と、非 Koa コンテキストでの使用方法の違い。言い換えれば、Koa は完全に Co の正面を向いているのでしょうか?

-- より優れたジェネレーター ライブラリがある場合、Co を Koa のジェネレーター ライブラリのようなものに置き換えることはできますか? いずれかがあります？

* "Q" や Bluebird などの Promise ライブラリ *

私の理解：

-- それらはある意味では、Promises/A+ 仕様を実装するための「ポリフィル」です (Node がその仕様をネイティブに実行するまで)。
-- Bluebird の promisfyAll ユーティリティなど、プロミスの使用を促進するための非仕様の便利なユーティリティがさらにいくつかあります。

具体的な質問:

-- 私の理解では、ECMAScript-6 仕様は Promises/A+ 仕様を大幅に反映している/反映する予定ですが、それでも Node 0.11v の調和は Promises をネイティブに実装していません。（これでいいの？）しかしそうなったらQやBluebirdなどの技術はなくなるのでしょうか？

-- 「Q」と Bluebird がジェネレーターをサポートしているという趣旨の記事を読んだことがあります。これは何を意味するのでしょうか？たとえば、それらが Co と同じ有用性をある程度提供したということは、部分的には意味するのでしょうか。

*サンクと約束*

私はそれらが何であるかを公正に把握していると思いますが、誰かがそれぞれが何であるかについて簡潔で明確な「エレベーターピッチ」の定義を提供できることを願っています。 Koa コンテキストではなく、Koa コンテキストで。

具体的な質問:

-- Bluebird の promisfy のようなものを使用することと、Thunkify (github com/visionmedia/node-thunkify) を使用することの長所と短所は?

==============================

この投稿とその質問にさらにコンテキストを与えるために、次の Web ページに示されている Koa の手法について議論し、対比することができれば (特に長所と短所に基づいて) 興味深いかもしれません。

-- a) www.marcusoft . net/2014/03/koaintro.html (サンクまたはプロミスはどこにあるのか、または何かが表示されないのですか?)

-- b) 強いループ。com/strongblog/node-js-express-introduction-koa-js-zone (繰り返しになりますが、サンクやプロミスはどこにありますか?)

-- c) github . com/koajs/koa/blob/master/docs/guide.md (「次の」引数は何と同等で、何が設定され、どこに設定されていますか?)

-- d) blog.peterdecroos . com/blog/2014/01/22/javascript-generators-first-impressions (Koa のコンテキストではありませんが、Promise ライブラリ (Bluebird) を使用した Co の使用を提示しているため、ここで提示されている手法/パターンが役立つと想定しています)それ自体を Koa で使用する(?) 場合、どのようにうまくいきますか?

皆さんありがとう！