Sendgrid-nodejs: A assinatura da função de retorno de chamada não segue as convenções do nó

Minha solução atual é verificar o código de status para sucesso, por exemplo:

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

Como você pode ver, isso é bastante prolixo e requer muitos padrões para simplesmente enviar um e-mail e verificar se funcionou ou não.

A API proposta seria 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);
    });
  });
}

Ou melhor ainda, com promessas devolvidas:

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 o retorno de um auxiliar de envio de correio dedicado, que criaria a solicitação adequada para nós em segundo plano, eliminando a necessidade de um auxiliar sendMail e clichê por completo:

sg.sendMail(mail);

Se isso é algo que você está interessado em fazer, irei fazer algumas relações públicas para isso.

Obrigado @adambuczynski ,

Geralmente, estamos planejando atualizar o tratamento de erros, mas ainda não definimos o escopo. Levaremos esse feedback em consideração quando chegar a hora.

Se você deseja fornecer uma solicitação pull, precisamos de um CLA assinado: https://github.com/sendgrid/sendgrid-nodejs/blob/master/CONTRIBUTING.md#cla

Configuramos uma estrutura auxiliar para o tipo de aprimoramento que você propõe: https://github.com/sendgrid/sendgrid-nodejs/tree/master/lib/helpers/mail. Você pode ajudar a modificá-lo ou criar o seu próprio no diretório de ajudantes.

Obrigado por seu apoio!

Sim, vi o ajudante de correio. Você deseja criar um auxiliar de envio de email nesse objeto?

Isso parece bom para mim :)

As sugestões que @adambuczynski fez estão

Incrível, obrigado pela validação @beldenge!

Siga este problema para o progresso. Se @adambuczynski criar uma solicitação pull, irei postá-la aqui; caso contrário, adicionaremos isso ao nosso roteiro para uma das próximas atualizações da biblioteca.

@thinkingserious Acabei de enviar a você o CA assinado, espero ter algum tempo na próxima semana para examinar isso.

@adambuczynski, nós o recebemos e obrigado pelo feedback!

Olá pessoal, não esqueci disso, mas ando meio ocupado com vários outros projetos. Ainda espero analisar isso em algum momento :)

@thinkingserious Eu dei uma olhada em seu código-fonte, mas parece um pouco confuso. Se eu fizer edições, meu linter de código fará muitas alterações automatizadas (por exemplo, adicionar ponto-e-vírgula ausente, usar um estilo de aspas consistente para strings, usar espaçamentos consistentes entre elementos de linguagem, etc.

Você está bem com isso acontecendo? Eu não acho que serei capaz de trabalhar com o código de outra forma, pois meu cérebro dói olhar para ele :)

PS porque você não usa linters :)

@adambuczynski ,

Usamos este linter: http://eslint.org junto com o guia de estilo padrão.

Qual destes você usa? Se pudéssemos sincronizar e usar o mesmo linter, seria maravilhoso.

Eu uso o ESLiint também, mas não parece que você aplica muitas regras, pois ainda existem muitas inconsistências no código.

Esta é a configuração que eu uso: https://gist.github.com/adambuczynski/1fa24bcfc5d17b8d26e4c39ffca7560e#file -eslintrc-node-yaml

Acho que fornece um bom equilíbrio entre consistência e práticas recomendadas, mas sem ser muito chato.

Não há .eslintrc.yaml arquivo de configuração em seu projeto. Você poderia adicionar / criar um com suas regras preferidas para que eu possa usá-lo também?

@adambuczynski ,

Estou feliz em usar o seu, parece sólido :)

Adicione-o como parte do seu commit.

@thinkingserious, ele está configurado para recursos ES6, por exemplo, advertindo quando você usa var vez de let e usando o analisador ES6.

Tudo bem ou você prefere usar o ES5 apenas para compatibilidade com versões anteriores?

Precisamos oferecer suporte às versões Node.js: "0,10", "0,12", "iojs", "4"

Estou bem com a abordagem mais moderna se não quebrarmos o suporte para essas versões.

Ok, mantive os var's e acabei de corrigir os problemas de estilo de código que surgiram. Criei um PR para isso separadamente desta edição.

@thinkingserious Também estou implementando uma API Promise, mas as promessas nativas foram introduzidas apenas no Nó 0.11.13.

Várias soluções, diga-me qual (ou combinação) você prefere:

• Use bluebird promessas como uma dependência
• Verifique se as promessas são suportadas ou não, lance um erro se não forem, mas se as pessoas tentarem usá-las
• Permita que os usuários definam a implementação da promessa que desejam usar simplesmente definindo sendgrid.Promise para qualquer valor.

Provavelmente, uma combinação de 2 e 3 seria a mais simples e flexível.

Acordado.

Eu gosto desta opção: "Verifique se as promessas são suportadas ou não, lance um erro se não forem, mas se as pessoas tentarem usá-las", mas também permitindo que os usuários especifiquem a implementação que desejam.

@thinkingserious perfeito. Tenho algo pronto para revisão. Quer que o envie para o mesmo PR ou crie um PR separado para ele?

@adambuczynski você pode manter no mesmo PR, obrigado!

Veja # 261

@beldenge , você se importaria de adicionar um +1 ao PR https://github.com/sendgrid/sendgrid-nodejs/pull/261 para que a equipe Sendgrid possa movê-lo e considerá-lo para fusão? Obrigado!

@adambuczynski vou adicionar o +1 agora :)

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