Sendgrid-nodejs: コールバック関数のシグネチャがノードの規則に従っていない

作成日 2016年06月15日  ·  25コメント  ·  ソース: sendgrid/sendgrid-nodejs

これはおそらく、あなたが物事に特定の方法を行うためになされた決定であるが、それは、このライブラリの3.0.4バージョンのようだ、コールバックが渡さsg.APIの標準ノードのコールバック関数のシグネチャの規則に従っていませんfunction (error, data) 。 代わりに、API応答は常に最初のオブジェクトとして返されます。

これにより、生のAPI応答を解読し、応答ヘッダーとステータスコードを手動で分析する責任があるため、問題が発生したかどうかを判断するのが困難になります。

これは利用者の土地の責任ではなく、図書館自体の責任だと思います。 ステータスコードが変更された場合はどうなりますか? 応答形式が変更された場合はどうなりますか? エラーが発生し、返されるデータ形式が異なる場合、またはnullまたは未定義になった場合はどうなりますか?

これに対処するためにできることは、ライブラリがエラーが発生したかどうかを判断し、発生した場合は最初のパラメータにエラーオブジェクトを設定することです(応答を添付できます)。 エラーが発生しない場合は、最初のパラメーターとしてnullを返し、2番目のパラメーターとして応答オブジェクトを返します。

help wanted community enhancement

最も参考になるコメント

私の現在の解決策は、ステータスコードが成功したかどうかを確認することです。例:

function sendMail(mail) {
  return new Promise((resolve, reject) => {

    //Build request
    let request = sg.emptyRequest();
    request.method = 'POST';
    request.path = '/v3/mail/send';
    request.body = mail.toJSON();

    //Send request
    sg.API(request, response => {
      if (response && response.statusCode &&
        response.statusCode >= 200 && response.statusCode <= 299) {
        resolve(response);
      }
      reject(new SendMailError(
        'Sendgrid response error ' + response.statusCode
      ));
    });
  });
}

ご覧のとおり、これは非常に冗長であり、電子メールを送信して機能するかどうかを確認するために多くの定型文が必要です。

提案されたAPIは次のようになります。

function sendMail(mail) {
  return new Promise((resolve, reject) => {

    //Build request
    let request = sg.emptyRequest();
    request.method = 'POST';
    request.path = '/v3/mail/send';
    request.body = mail.toJSON();

    //Send request
    sg.API(request, (error, response) => {
      if (error {
        reject(new SendMailError(error);
      }
      resolve(response);
    });
  });
}

またはさらに良いことに、約束が返されます:

function sendMail(mail) {

  //Build request
  let request = sg.emptyRequest();
  request.method = 'POST';
  request.path = '/v3/mail/send';
  request.body = mail.toJSON();

  //Send request
  return sg.API(request);
}

そして、理想的には、専用のメール送信ヘルパーが返され、バックグラウンドで適切なリクエストが作成され、sendMailヘルパーとボイラープレートが完全に不要になります。

sg.sendMail(mail);

これがあなたが追求することに興味があるものであるならば、私はそれのためにいくつかのPRを作ることを検討します。

全てのコメント25件

私の現在の解決策は、ステータスコードが成功したかどうかを確認することです。例:

function sendMail(mail) {
  return new Promise((resolve, reject) => {

    //Build request
    let request = sg.emptyRequest();
    request.method = 'POST';
    request.path = '/v3/mail/send';
    request.body = mail.toJSON();

    //Send request
    sg.API(request, response => {
      if (response && response.statusCode &&
        response.statusCode >= 200 && response.statusCode <= 299) {
        resolve(response);
      }
      reject(new SendMailError(
        'Sendgrid response error ' + response.statusCode
      ));
    });
  });
}

ご覧のとおり、これは非常に冗長であり、電子メールを送信して機能するかどうかを確認するために多くの定型文が必要です。

提案されたAPIは次のようになります。

function sendMail(mail) {
  return new Promise((resolve, reject) => {

    //Build request
    let request = sg.emptyRequest();
    request.method = 'POST';
    request.path = '/v3/mail/send';
    request.body = mail.toJSON();

    //Send request
    sg.API(request, (error, response) => {
      if (error {
        reject(new SendMailError(error);
      }
      resolve(response);
    });
  });
}

またはさらに良いことに、約束が返されます:

function sendMail(mail) {

  //Build request
  let request = sg.emptyRequest();
  request.method = 'POST';
  request.path = '/v3/mail/send';
  request.body = mail.toJSON();

  //Send request
  return sg.API(request);
}

そして、理想的には、専用のメール送信ヘルパーが返され、バックグラウンドで適切なリクエストが作成され、sendMailヘルパーとボイラープレートが完全に不要になります。

sg.sendMail(mail);

これがあなたが追求することに興味があるものであるならば、私はそれのためにいくつかのPRを作ることを検討します。

ありがとう@adambuczynski

通常、エラー処理を更新する予定ですが、まだ範囲を限定していません。 その時が来たら、このフィードバックを考慮に入れます。

プルリクエストを提供する場合は、署名済みのCLAが必要です: https

提案する種類の拡張機能のヘルパー構造を設定しました: https

ご協力ありがとうございました!

はい、私はメールのヘルパーを見ました。 そのオブジェクトにメール送信ヘルパーを作成しますか?

それがいいと思います :)

@adambuczynskiが行った提案は的を

素晴らしい、検証@beldengeに感謝します!

進捗状況については、この問題に従ってください。 @adambuczynskiがプルリクエストを作成した場合は、ここに投稿します。 それ以外の場合は、次のライブラリ更新の1つのロードマップにこれを追加します。

@thinkingserious署名済みのCAを郵送しました。来週、これを調査する時間があればと思います。

@adambuczynski受け取ったので、フィードバックをありがとうございます。

こんにちはみんな、これを忘れていませんが、私は他のいくつかのプロジェクトで少し忙しかったです。 まだいくつかの段階でこれを調べることを望んでいます:)

@thinkingserious私はあなたのソースコードを見てきましたが、それは少し厄介に見えます。 編集を行うと、コードリンターはそれに多くの自動変更を加えます(たとえば、欠落しているセミコロンの追加、文字列の一貫した引用スタイルの使用、言語要素間の一貫した間隔の使用など)

あなたはそれが起こっても大丈夫ですか? それ以外の方法でコードを操作することはできないと思います。それを見ると脳が痛くなるからです:)

PSなぜリンターを使わないのですか:)

@adambuczynski

このリンターを使用します: http

どちらを使いますか? 同期して同じリンターを使用できれば、それは素晴らしいことです。

私もESLiintを使用していますが、コードにはまだ多くの不整合があるため、多くのルールを適用しているようには見えません。

これは私が使用する構成です: https ://gist.github.com/adambuczynski/1fa24bcfc5d17b8d26e4c39ffca7560e#file -eslintrc-node-yaml

煩わしさを感じることなく、一貫性とベストプラクティスのバランスが取れていると思います。

プロジェクトに.eslintrc.yamlファイルはありません。 私も使用できるように、好みのルールで追加/作成できますか?

@adambuczynski

私はあなたを使って幸せです、それはしっかりしているように見えます:)

コミットの一部として追加してください。

@thinkingseriousただし、ES6機能用に設定されています。たとえば、 var代わりにletを使用し、ES6パーサーを使用すると警告が表示されます。

それは大丈夫ですか、それとも下位互換性のためだけにES5を使用したいですか?

Node.jsバージョンをサポートする必要があります: "0.10"、 "0.12"、 "iojs"、 "4"

これらのバージョンのサポートを中断しなければ、より現代的なアプローチで問題ありません。

わかりました。変数を保持し、発生したコードスタイルの問題を修正しました。 この号とは別に、そのためのPRを作成しました。

@thinkingserious Promise APIも実装していますが、ネイティブPromiseはノード0.11.13でのみ導入されました。

いくつかの解決策、あなたが好む(または組み合わせ)を教えてください:

  • bluebird promiseを依存関係として使用する
  • promiseがサポートされているかどうかを確認し、サポートされていない場合はエラーをスローしますが、人々がそれらを使用しようとした場合
  • sendgrid.Promiseを任意の値に設定するだけで、ユーザーが使用するpromise実装を設定できるようにします。

おそらく、2と3の組み合わせが最も単純で、最も柔軟性があります。

同意しました。

私はこのオプションが好きです:「promiseがサポートされているかどうかを確認し、サポートされていない場合はエラーをスローしますが、人々がそれらを使おうとすると」、ユーザーが希望する実装を指定できるようにします。

@thinkingseriousパーフェクト。 レビューの準備ができていますが、同じPRにプッシュしますか、それとも別のPRを作成しますか?

@adambuczynski同じPRを維持できます、ありがとう!

#261を参照

@beldenge PR https://github.com/sendgrid/sendgrid-nodejs/pull/261に+1を追加して、Sendgridチームがそれを移動し、マージを検討できるようにしていただけませんか? ありがとう!

@adambuczynski今すぐ+1を追加します:)

このページは役に立ちましたか?
0 / 5 - 0 評価