Sendgrid-nodejs: Tanda tangan fungsi panggilan balik tidak mengikuti konvensi Node

Solusi saya saat ini adalah memeriksa kode status untuk keberhasilan, misalnya:

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

Seperti yang Anda lihat, ini cukup bertele-tele dan membutuhkan banyak boilerplate untuk hanya mengirim email dan memeriksa apakah itu berfungsi atau tidak.

API yang diusulkan akan menjadi seperti:

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

Atau lebih baik lagi, dengan janji dibalas:

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

Dan, idealnya, kita akan melihat kembalinya helper pengiriman email khusus yang akan membuat permintaan yang tepat untuk kita di latar belakang, menghilangkan kebutuhan akan helper sendMail dan boilerplate sama sekali:

sg.sendMail(mail);

Jika ini adalah sesuatu yang ingin Anda kejar, saya akan melihat beberapa PR untuk itu.

Terima kasih @adambuczynski ,

Umumnya, kami berencana memperbarui penanganan kesalahan, tetapi kami belum membahasnya. Kami akan mempertimbangkan umpan balik ini ketika saatnya tiba.

Jika Anda ingin memberikan permintaan tarik, kami memerlukan CLA yang ditandatangani: https://github.com/sendgrid/sendgrid-nodejs/blob/master/CONTRIBUTING.md#cla

Kami telah menyiapkan struktur pembantu untuk jenis penyempurnaan yang Anda usulkan: https://github.com/sendgrid/sendgrid-nodejs/tree/master/lib/helpers/mail. Anda dapat membantu memodifikasi yang satu itu, atau membuatnya sendiri di direktori helpers.

Terima kasih atas dukunganmu!

Ya, saya telah melihat pembantu untuk surat. Apakah Anda ingin membuat pembantu pengiriman surat pada objek itu?

Terdengar bagus untukku :)

Saran yang dibuat @adambuczynski tepat. Saya baru saja memperbarui ke API v3 dan sangat kecewa karena saya tidak dapat menggunakan fungsi pembantu sederhana lagi dan sebaliknya harus menulis banyak kode pelat ketel. Saya bahkan tidak bisa lagi membungkusnya dalam janji Bluebird tanpa menulis kode penanganan kesalahan yang jelek.

Luar biasa, terima kasih atas validasi @beldenge!

Ikuti masalah ini untuk kemajuan. Jika @adambuczynski membuat permintaan tarik, saya akan mempostingnya di sini; jika tidak, kami akan menambahkan ini ke peta jalan kami untuk salah satu pembaruan perpustakaan berikutnya.

@thinkingserious Saya baru saja mengirimi Anda CA yang telah ditandatangani, saya berharap memiliki waktu minggu depan untuk menyelidiki hal ini.

@adambuczynski kami telah menerimanya dan terima kasih atas umpan baliknya!

Hai teman-teman, belum lupa tentang ini, tetapi saya agak sibuk dengan beberapa proyek lainnya. Masih berharap untuk melihat ini pada tahap tertentu :)

@thinkingserious Saya telah melihat kode sumber Anda, tetapi tampaknya agak berantakan. Jika saya mengedit, linter kode saya akan membuat banyak perubahan otomatis padanya (misalnya menambahkan titik koma yang hilang, menggunakan gaya kutipan yang konsisten untuk string, menggunakan spasi yang konsisten antara elemen bahasa, dll.)

Apakah Anda setuju dengan hal itu? Saya tidak berpikir saya akan dapat bekerja dengan kode sebaliknya, karena sakit otak saya untuk melihatnya :)

PS mengapa Anda tidak menggunakan linters :)

@bayu_joo ,

Kami menggunakan linter ini: http://eslint.org bersama dengan panduan gaya standar.

Yang mana yang Anda gunakan? Jika kita dapat menyinkronkan dan menggunakan linter yang sama itu akan sangat bagus.

Saya menggunakan ESLiint juga, tetapi sepertinya Anda tidak menerapkan banyak aturan karena masih banyak inkonsistensi dalam kode.

Ini adalah konfigurasi yang saya gunakan: https://gist.github.com/adambuczynski/1fa24bcfc5d17b8d26e4c39ffca7560e#file -eslintrc-node-yaml

Saya pikir ini memberikan keseimbangan yang baik antara konsistensi dan praktik terbaik, namun tanpa terlalu mengganggu.

Tidak ada file config .eslintrc.yaml dalam proyek Anda. Bisakah Anda menambahkan / membuatnya dengan aturan pilihan Anda sehingga saya dapat menggunakannya juga?

@bayu_joo ,

Saya senang menggunakan milik Anda, terlihat kokoh :)

Harap tambahkan sebagai bagian dari komitmen Anda.

@thinkingserious itu diatur untuk fitur ES6, misalnya peringatan ketika Anda menggunakan var daripada let dan menggunakan parser ES6.

Tidak apa-apa, atau Anda lebih suka menggunakan ES5 hanya untuk kompatibilitas mundur?

Kami perlu mendukung versi Node.js: "0.10", "0.12", "iojs", "4"

Saya baik-baik saja dengan pendekatan yang lebih modern jika kami tidak memutuskan dukungan untuk versi tersebut.

Oke, saya telah menyimpan var dan hanya memperbaiki masalah gaya kode yang muncul. Membuat PR untuk itu secara terpisah dari masalah ini.

@thinkingserious Saya juga mengimplementasikan Promise API, tetapi promise asli hanya diperkenalkan di Node 0.11.13.

Beberapa solusi, beri tahu saya mana (atau kombinasi) yang Anda sukai:

• Gunakan bluebird promise sebagai dependensi
• Periksa apakah janji didukung atau tidak, berikan kesalahan jika tidak, tetapi jika orang mencoba menggunakannya
• Izinkan pengguna menyetel implementasi promise yang ingin mereka gunakan hanya dengan menyetel sendgrid.Promise ke nilai apa pun.

Mungkin kombinasi 2 dan 3 paling sederhana dan fleksibel.

Sepakat.

Saya menyukai opsi ini: "Periksa apakah janji didukung atau tidak, berikan kesalahan jika tidak, tetapi jika orang mencoba menggunakannya", tetapi juga mengizinkan pengguna untuk menentukan penerapan yang mereka inginkan.

@Serius sempurna. Saya memiliki sesuatu yang siap untuk ditinjau, apakah Anda ingin saya memasukkannya ke PR yang sama, atau membuat PR terpisah untuk itu?

@adambuczynski Anda dapat tetap dalam PR yang sama, terima kasih!

Lihat # 261

@beldenge, maukah Anda menambahkan +1 ke PR https://github.com/sendgrid/sendgrid-nodejs/pull/261 sehingga tim Sendgrid dapat memindahkannya dan mempertimbangkannya untuk digabungkan? Terima kasih!

@adambuczynski saya akan menambahkan +1 sekarang :)

Diperbaiki dengan https://github.com/sendgrid/sendgrid-nodejs/releases/tag/v4.0.0