Sendgrid-nodejs: Die Signatur der Rückruffunktion entspricht nicht den Knotenkonventionen

Meine derzeitige Lösung besteht darin, den Statuscode auf Erfolg zu überprüfen, z.

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

Wie Sie sehen können, ist dies jedoch ziemlich ausführlich und erfordert viel Boilerplate, um einfach eine E-Mail zu senden und zu überprüfen, ob es funktioniert hat oder nicht.

Die vorgeschlagene API wäre ungefähr so:

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

Oder noch besser, mit zurückgegebenen Versprechungen:

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

Und im Idealfall würden wir die Rückkehr eines dedizierten Mail-Sende-Helfers sehen, der im Hintergrund die richtige Anfrage für uns erstellt und die Notwendigkeit eines sendMail-Helfers und eines Boilerplates insgesamt überflüssig macht:

sg.sendMail(mail);

Wenn Sie daran interessiert sind, werde ich einige PRs dafür machen.

Danke @adambuczynski ,

Im Allgemeinen planen wir, die Fehlerbehandlung zu aktualisieren, aber wir haben dies noch nicht herausgefunden. Wir werden dieses Feedback zu diesem Zeitpunkt berücksichtigen.

Wenn Sie eine Pull-Anfrage stellen möchten, benötigen wir eine signierte CLA: https://github.com/sendgrid/sendgrid-nodejs/blob/master/CONTRIBUTING.md#cla

Wir haben eine Hilfsstruktur für die von Ihnen vorgeschlagenen Verbesserungen eingerichtet: https://github.com/sendgrid/sendgrid-nodejs/tree/master/lib/helpers/mail. Sie können entweder helfen, diese zu ändern, oder Ihre eigene im Verzeichnis der Helfer erstellen.

Danke für deine Unterstützung!

Ja, ich habe den Helfer für Post gesehen. Möchten Sie einen E-Mail-Hilfsprogramm für dieses Objekt erstellen?

Das klingt gut für mich :)

Die Vorschläge von @adambuczynski sind

Super, danke für die Validierung @beldenge!

Bitte folgen Sie dieser Ausgabe, um Fortschritte zu erzielen. Wenn @adambuczynski eine Pull-Anfrage erstellt, werde ich sie hier posten. Andernfalls fügen wir dies unserer Roadmap für eines der nächsten Bibliotheksupdates hinzu.

@thinkingserious Ich habe dir gerade die unterschriebene

@adambuczynski wir haben es erhalten und danke für das Feedback!

Hallo Leute, hab das nicht vergessen, aber ich war ein bisschen beschäftigt mit mehreren anderen Projekten. Ich hoffe immer noch, dass ich mich irgendwann darum kümmern kann :)

@thinkingserious Ich habe mir Ihren Quellcode angesehen, aber er sieht ein bisschen chaotisch aus. Wenn ich Änderungen vornehme, nimmt mein Code-Linter viele automatisierte Änderungen daran vor (z. B. fehlende Semikolons hinzufügen, konsistenten Anführungszeichen für Zeichenfolgen verwenden, konsistente Abstände zwischen Sprachelementen verwenden usw. usw.)

Bist du damit einverstanden? Ich glaube nicht, dass ich sonst mit dem Code arbeiten kann, da es meinem Gehirn weh tut, ihn anzusehen :)

PS warum benutzt du keine Linters :)

@adambuczynski ,

Wir verwenden diesen Linter: http://eslint.org zusammen mit dem Standard Style Guide.

Welches benutzt du? Wenn wir den gleichen Linter synchronisieren und verwenden können, wäre das wunderbar.

Ich verwende auch ESLiint, aber es scheint nicht, dass Sie viele Regeln anwenden, da der Code immer noch so viele Inkonsistenzen enthält.

Dies ist die Konfiguration, die ich verwende: https://gist.github.com/adambuczynski/1fa24bcfc5d17b8d26e4c39ffca7560e#file -eslintrc-node-yaml

Ich denke, es bietet eine gute Balance zwischen Konsistenz und Best Practices, ohne jedoch zu nervig zu sein.

In Ihrem Projekt befindet sich keine Konfigurationsdatei .eslintrc.yaml . Könnten Sie eine mit Ihren bevorzugten Regeln hinzufügen / erstellen, damit ich sie auch verwenden kann?

@adambuczynski ,

Ich benutze gerne deins, es sieht solide aus :)

Bitte fügen Sie es als Teil Ihres Commits hinzu.

@thinkingserious Es ist jedoch für ES6-Funktionen eingerichtet, z. B. Warnung, wenn Sie var anstelle von let und den ES6-Parser verwenden.

Ist das in Ordnung oder bevorzugen Sie die Verwendung von ES5 nur aus Gründen der Abwärtskompatibilität?

Wir müssen Node.js Versionen unterstützen: "0.10", "0.12", "iojs", "4"

Ich bin mit dem moderneren Ansatz einverstanden, wenn wir die Unterstützung für diese Versionen nicht unterbrechen.

Ok, ich habe die Vars beibehalten und nur Probleme mit dem Codestil behoben, die aufgetreten sind. Habe dafür getrennt von dieser Ausgabe eine PR erstellt.

@thinkingserious Ich implementiere auch eine Promise-API, aber native Versprechen wurden nur in Node 0.11.13 eingeführt.

Mehrere Lösungen, lassen Sie mich wissen, welche (oder Kombination) Sie bevorzugen:

• Verwenden Sie bluebird Versprechen als Abhängigkeit
• Überprüfen Sie, ob Versprechen unterstützt werden oder nicht. Geben Sie einen Fehler aus, wenn dies nicht der Fall ist, aber wenn die Leute versuchen, sie zu verwenden
• Ermöglichen Sie Benutzern, die Versprechen-Implementierung festzulegen, die sie verwenden möchten, indem Sie einfach sendgrid.Promise auf einen beliebigen Wert setzen.

Wahrscheinlich wäre eine Kombination aus 2 und 3 am einfachsten und flexibelsten.

Einverstanden.

Ich mag diese Option: "Überprüfen Sie, ob Versprechen unterstützt werden oder nicht, werfen Sie einen Fehler, wenn dies nicht der Fall ist, aber wenn die Leute versuchen, sie zu verwenden", aber erlauben Sie den Benutzern auch, die gewünschte Implementierung anzugeben.

@thinkingserious perfekt. Ich habe etwas zur Überprüfung bereit. Soll ich es an dieselbe PR weiterleiten oder eine separate PR dafür erstellen?

@adambuczynski du kannst in der gleichen PR bleiben, danke!

Siehe # 261

@beldenge Würde es Ihnen etwas https://github.com/sendgrid/sendgrid-nodejs/pull/261 eine +1 hinzuzufügen, damit das Sendgrid-Team sie verschieben und für die Zusammenführung in Betracht ziehen kann? Vielen Dank!

@adambuczynski Ich werde jetzt die +1 hinzufügen :)

Behoben mit https://github.com/sendgrid/sendgrid-nodejs/releases/tag/v4.0.0