Sendgrid-nodejs: توقيع وظيفة رد الاتصال لا يتبع اصطلاحات العقدة

تم إنشاؤها على ١٥ يونيو ٢٠١٦  ·  25تعليقات  ·  مصدر: sendgrid/sendgrid-nodejs

ربما يكون هذا قرارًا اتخذته للقيام بالأشياء بطريقة معينة ، ولكن يبدو أنه مع الإصدار 3.0.4 من هذه المكتبة ، فإن رد الاتصال الذي تم تمريره إلى sg.API لا يتبع اصطلاح التوقيع القياسي لوظيفة Node callback وهو function (error, data) . بدلاً من ذلك ، يتم إرجاع استجابة API دائمًا باعتبارها الكائن الأول.

هذا يجعل من الصعب تحديد ما إذا كان هناك خطأ ما ، لأننا الآن مسؤولون عن فك تشفير استجابة واجهة برمجة التطبيقات الأولية وتحليل رؤوس الاستجابة ورموز الحالة يدويًا.

لا أشعر أن هذا يجب أن يكون من مسؤولية أرض المستخدم ، ولكن مسؤولية المكتبة نفسها. ماذا لو تغيرت أكواد الحالة؟ ماذا لو تغير تنسيق الرد؟ ماذا لو حدث خطأ وأصبح تنسيق البيانات التي تم إرجاعها مختلفًا ، أو خاليًا أو غير معرف؟

أقل ما يمكن القيام به لمعالجة هذا الأمر هو أن تحدد المكتبة ما إذا حدث خطأ ، وإذا كانت الإجابة بنعم ، فقم بتعبئة المعلمة الأولى بكائن خطأ (يمكن أن تكون الاستجابة مرفقة بها). في حالة عدم حدوث خطأ ، قم بإرجاع null كمعامل أول وكائن الاستجابة كمعامل ثاني.

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
      ));
    });
  });
}

كما ترى ، فإن هذا مطول تمامًا ويتطلب الكثير من النصوص المعيارية لإرسال بريد إلكتروني ببساطة والتحقق مما إذا كان يعمل أم لا.

قد تكون واجهة برمجة التطبيقات المقترحة مثل:

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);

إذا كان هذا شيئًا أنت مهتم بمتابعته ، فسأبحث عن بعض العلاقات العامة من أجله.

ال 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
      ));
    });
  });
}

كما ترى ، فإن هذا مطول تمامًا ويتطلب الكثير من النصوص المعيارية لإرسال بريد إلكتروني ببساطة والتحقق مما إذا كان يعمل أم لا.

قد تكون واجهة برمجة التطبيقات المقترحة مثل:

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);

إذا كان هذا شيئًا أنت مهتم بمتابعته ، فسأبحث عن بعض العلاقات العامة من أجله.

شكرا adambuczynski ،

بشكل عام ، نخطط لتحديث معالجة الأخطاء ، لكننا لم نحدد ذلك بعد. سنأخذ هذه التعليقات في الاعتبار عندما يحين ذلك الوقت.

إذا كنت ترغب في تقديم طلب سحب ، فنحن بحاجة إلى CLA موقع: https://github.com/sendgrid/sendgrid-nodejs/blob/master/CONTRIBUTING.md#cla

لقد قمنا بإعداد هيكل مساعد لنوع التحسينات التي تقترحها: https://github.com/sendgrid/sendgrid-nodejs/tree/master/lib/helpers/mail. يمكنك إما المساعدة في تعديل ذلك ، أو إنشاء الخاص بك في دليل المساعدين.

شكرا لدعمك!

نعم لقد رأيت المساعد للبريد. هل تريد إنشاء مساعد إرسال بريد على هذا الكائن؟

هذا يبدو جيدا بالنسبة لي :)

الاقتراحات المقدمة من adambuczynski موجودة على الفور. لقد قمت للتو بالتحديث إلى v3 API وشعرت بخيبة أمل كبيرة لأنني لا أستطيع استخدام وظيفة مساعد بسيطة بعد الآن ، وبدلاً من ذلك يتعين علي كتابة مجموعة من كود لوحة الغلاية. لم يعد بإمكاني تغليفه بوعد Bluebird دون كتابة رمز معالجة خطأ قبيح.

رائع ، شكرًا على التحقق من صحةbeldenge!

يرجى متابعة هذا الموضوع للتقدم. إذا أنشأadambuczynski طلب سحب ،

thinkingserious لقد قمت للتو بإرسال CA موقعًا بالبريد الإلكتروني ، وآمل أن يكون لدي بعض الوقت في الأسبوع المقبل للنظر في هذا الأمر.

adambuczynski لقد تلقيناها وشكرًا على التعليقات!

مرحبًا يا رفاق ، لم أنس هذا ، لكنني كنت مشغولًا بعض الشيء بالعديد من المشاريع الأخرى. ما زلت آمل في النظر في هذا في مرحلة ما :)

thinkingserious لقد

هل أنت بخير مع حدوث ذلك؟ لا أعتقد أنني سأكون قادرًا على التعامل مع الكود بخلاف ذلك ، لأنه يؤلم عقلي عند النظر إليه :)

ملاحظة: لماذا لا تستخدم linters :)

adambuczynski ،

نستخدم هذا linter: http://eslint.org جنبًا إلى جنب مع دليل النمط القياسي.

اي واحد تستعمل؟ إذا تمكنا من المزامنة واستخدام نفس الوبر ، فسيكون ذلك رائعًا.

أنا أستخدم 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"

أنا بخير مع النهج الأكثر حداثة إذا لم نكسر الدعم لهذه الإصدارات.

حسنًا ، لقد احتفظت بملفات var وقمت فقط بإصلاح مشكلات نمط التعليمات البرمجية التي ظهرت. إنشاء علاقات عامة لذلك بشكل منفصل عن هذه المشكلة.

thinkingserious أقوم أيضًا بتنفيذ Promise API ، ولكن تم تقديم الوعود المحلية فقط في Node 0.11.13.

عدة حلول ، اسمحوا لي أن أعرف أي (أو مجموعة) تفضل:

  • استخدم الوعود bluebird لتبعية
  • تحقق مما إذا كانت الوعود مدعومة أم لا ، أخطأ إذا لم تكن كذلك ولكن إذا حاول الناس استخدامها
  • اسمح للمستخدمين بتعيين تنفيذ الوعد الذي يريدون استخدامه ببساطة عن طريق تعيين sendgrid.Promise لأي قيمة.

ربما يكون الجمع بين 2 و 3 هو الأبسط والأكثر مرونة.

متفق عليه.

يعجبني هذا الخيار: "تحقق مما إذا كانت الوعود مدعومة أم لا ، أخطأ إذا لم تكن كذلك ولكن إذا حاول الناس استخدامها" ، ولكن اسمح للمستخدمين أيضًا بتحديد التنفيذ الذي يرغبون فيه.

تضمين التغريدة لدي شيء جاهز للمراجعة ، هل تريد مني دفعه إلى نفس العلاقات العامة ، أو إنشاء علاقات عامة منفصلة له؟

adambuczynski يمكنك الاحتفاظ بنفس العلاقات العامة ، شكرًا!

انظر # 261

beldenge هل تمانع في إضافة +1 إلى العلاقات العامة https://github.com/sendgrid/sendgrid-nodejs/pull/261 حتى يتمكن فريق Sendgrid من تحريكه واعتباره للدمج؟ شكر!

adambuczynski سأضيف +1 الآن :)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات