Sendgrid-nodejs: La firma de la función de devolución de llamada no sigue las convenciones de nodo

Mi solución actual es verificar que el código de estado sea exitoso, por ejemplo:

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

Sin embargo, como puede ver, esto es bastante detallado y requiere mucho texto estándar para simplemente enviar un correo electrónico y verificar si funcionó o no.

La API propuesta sería algo como:

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

O mejor aún, con las promesas devueltas:

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

E, idealmente, veríamos el regreso de un ayudante de envío de correo dedicado que crearía la solicitud adecuada para nosotros en segundo plano, eliminando la necesidad de un ayudante de sendMail y un texto estándar por completo:

sg.sendMail(mail);

Si esto es algo que le interesa seguir, buscaré hacer algunas relaciones públicas para ello.

Gracias @adambuczynski ,

En general, estamos planeando actualizar el manejo de errores, pero aún no lo hemos definido. Tendremos en cuenta estos comentarios cuando llegue ese momento.

Si desea proporcionar una solicitud de extracción, necesitamos un CLA firmado: https://github.com/sendgrid/sendgrid-nodejs/blob/master/CONTRIBUTING.md#cla

Hemos configurado una estructura de ayuda para el tipo de mejoras que proponga: https://github.com/sendgrid/sendgrid-nodejs/tree/master/lib/helpers/mail. Puede ayudar a modificarlo o crear el suyo propio en el directorio de ayudantes.

¡Gracias por su apoyo!

Sí, he visto al ayudante de correo. ¿Quiere crear un ayudante de envío de correo en ese objeto?

Suena bien para mi :)

Las sugerencias que hizo @adambuczynski son

¡Genial, gracias por la validación @beldenge!

Siga este problema para progresar. Si @adambuczynski crea una solicitud de extracción, la publicaré aquí; de lo contrario, agregaremos esto a nuestra hoja de ruta para una de las próximas actualizaciones de la biblioteca.

@thinkingserious Acabo de enviarle por correo el CA firmado, espero tener algo de tiempo la próxima semana para investigar esto.

@adambuczynski lo hemos recibido y gracias por los comentarios.

Hola chicos, no me he olvidado de esto, pero he estado un poco ocupado con varios otros proyectos. Todavía espero ver esto en algún momento :)

@thinkingserious He

¿Estás de acuerdo con que eso suceda? De lo contrario, no creo que pueda trabajar con el código, ya que me duele el cerebro mirarlo :)

PD: ¿por qué no usas linters :)

@adambuczynski ,

Usamos este linter: http://eslint.org junto con la guía de estilo estándar.

Cual usas? Si podemos sincronizar y usar el mismo linter, sería maravilloso.

Yo también uso ESLiint, pero no parece que apliques muchas reglas ya que todavía hay muchas inconsistencias en el código.

Esta es la configuración que uso: https://gist.github.com/adambuczynski/1fa24bcfc5d17b8d26e4c39ffca7560e#file -eslintrc-node-yaml

Creo que proporciona un buen equilibrio entre la coherencia y las mejores prácticas, pero sin ser demasiado molesto.

No hay .eslintrc.yaml archivo de configuración

@adambuczynski ,

Estoy feliz de usar el tuyo, se ve sólido :)

Agréguelo como parte de su compromiso.

@thinkingserious, sin embargo, está configurado para las funciones de ES6, por ejemplo, una advertencia cuando usa var lugar de let y usa el analizador ES6.

¿Está bien o prefiere usar ES5 solo por compatibilidad con versiones anteriores?

Necesitamos admitir las versiones de Node.js: "0.10", "0.12", "iojs", "4"

Estoy de acuerdo con el enfoque más moderno si no rompemos el soporte para esas versiones.

Ok, conservé las var y solo solucioné los problemas de estilo de código que surgieron. Creé un PR para eso por separado de este problema.

@thinkingserious También estoy implementando una API Promise, pero las promesas nativas solo se introdujeron en el nodo 0.11.13.

Varias soluciones, avíseme cuál (o combinación) prefiere:

• Use bluebird promises como dependencia
• Verifique si las promesas son compatibles o no, arroje un error si no lo son, pero si las personas intentan usarlas
• Permita que los usuarios establezcan la implementación de la promesa que desean usar simplemente estableciendo sendgrid.Promise en cualquier valor.

Probablemente una combinación de 2 y 3 sería la más simple y flexible.

Convenido.

Me gusta esta opción: "Verifique si las promesas son compatibles o no, arroje un error si no lo son pero si la gente intenta usarlas", pero también permite a los usuarios especificar la implementación que les gustaría.

@thinkingserious perfecto. Tengo algo listo para revisar, ¿quieres que lo envíe al mismo PR o cree un PR separado para él?

@adambuczynski puedes mantener las mismas relaciones públicas, ¡gracias!

Ver # 261

@beldenge, ¿le importaría agregar un +1 al PR https://github.com/sendgrid/sendgrid-nodejs/pull/261 para que el equipo de Sendgrid pueda moverlo y considerarlo para fusionarlo? ¡Gracias!

@adambuczynski Agregaré el +1 ahora :)

Corregido con https://github.com/sendgrid/sendgrid-nodejs/releases/tag/v4.0.0