Sendgrid-nodejs: Сигнатура функции обратного вызова не соответствует соглашениям узла

Созданный на 15 июн. 2016  ·  25Комментарии  ·  Источник: sendgrid/sendgrid-nodejs

Вероятно, вы приняли решение делать что-то определенным образом, но похоже, что в версии 3.0.4 этой библиотеки обратный вызов, переданный в sg.API , не соответствует стандартному соглашению о подписи функции обратного вызова узла function (error, data) . Вместо этого ответ API всегда возвращается как первый объект.

Это затрудняет определение того, что что-то пошло не так, поскольку теперь мы отвечаем за расшифровку необработанного ответа 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
      ));
    });
  });
}

Как видите, это довольно многословно и требует большого количества шаблонов, чтобы просто отправить электронное письмо и проверить, сработало ли оно или нет.

Предлагаемый API будет примерно таким:

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

Как видите, это довольно многословно и требует большого количества шаблонов, чтобы просто отправить электронное письмо и проверить, сработало ли оно или нет.

Предлагаемый API будет примерно таким:

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 Я просмотрел ваш исходный код, но он выглядит немного запутанным. Если я внесу правки, мой линтер кода внесет в него множество автоматических изменений (например, добавит недостающие точки с запятой, используйте согласованный стиль кавычек для строк, используйте согласованные интервалы между элементами языка и т. Д.)

Вы согласны с этим? Иначе не думаю, что смогу работать с кодом, потому что мне больно смотреть на него :)

PS почему линтеры не используете :)

@adambuczynski ,

Мы используем этот линтер: 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 была бы самой простой и гибкой.

Согласовано.

Мне нравится этот вариант: «Проверить, поддерживаются ли обещания, выдавать ошибку, если это не так, но если люди попытаются их использовать», но также позволяет пользователям указать желаемую реализацию.

@thinkingserious идеально. У меня есть что-то готовое для обзора, вы хотите, чтобы я подтолкнул это к тому же PR или создал для него отдельный PR?

@adambuczynski, вы можете сохранить такой же пиар, спасибо!

См. № 261

@beldenge, не https://github.com/sendgrid/sendgrid-nodejs/pull/261, чтобы команда Sendgrid могла переместить его и рассмотреть для слияния? Спасибо!

@adambuczynski Я добавлю +1 сейчас :)

Была ли эта страница полезной?
0 / 5 - 0 рейтинги