Sendgrid-nodejs: Ajouter la prise en charge des modèles dynamiques

Veuillez mettre à jour votre documentation. Je viens de passer une heure à essayer de comprendre pourquoi les substitutions ne fonctionnaient pas avec l'API v3.

Mes excuses pour la mauvaise expérience @jharris-code.

J'ai ajouté votre vote à cette question pour l'aider à gagner la priorité. Je pense qu'il sera bientôt mis à jour car nous avons le PR #711.

Il est très idiot que l'absence de documentation bloque la publication du code réel.

Salut @catamphetamine ,

Le code a été publié en v6.3.1 . J'espère que ça t'aidera, merci !

Meilleures salutations,

Elmer

@thinkingserious Oh, cool, en fait, cela ne m'a pas traversé l'esprit de mettre à jour la version de la bibliothèque.
Je vais essayer ça, merci.

Note aux utilisateurs : lorsque vous utilisez des modèles, transmettez dynamic_template_data au lieu de substitutions .

Maintenant, vous devez changer "substitutions:" en "dynamic_template_data:"

Et les modèles utilisent des guidons plus besoin de spécifier "substitutionWrappers"

Cet exemple dans vos cas d'utilisation utilise toujours des substitutions plutôt que dynamic_template_data. Mise à jour Plz, il m'a fallu quelques heures pour jouer avec le SDK et chercher avant de trouver ce fil. (De plus, vos documents API ne mentionnent rien à ce sujet, ce qui n'a pas aidé non plus.
De plus, substitutionWrappers ne semble pas du tout fonctionner avec dynamic_template_data. Indépendamment de l'inclusion de la paire clé-valeur substitutionWrappers: ['*|', '|*'] dans mon objet message, seules les variables de modèle entourées d'accolades ont été renseignées. (Est-ce que vous forcez intentionnellement tout le monde à utiliser la syntaxe du guidon pour les modèles ?)

Mes excuses @josh-yonomi,

J'ai mis à jour la documentation en fonction de vos commentaires.

Pour nos nouveaux modèles, ils utilisent la syntaxe du guidon. Les modèles hérités fonctionnent toujours comme avant.

Meilleures salutations,

Elmer

Je reçois l'email mais les substitutions ne fonctionnent pas. Qu'est-ce qui peut causer le problème ?

const msg = {
    to: email,
    from: sendGridMail,
    templateId: emailTemplate.confirmationEmail,
    dynamic_template_data: {
      firstName: firstName,
      lastName: lastName,
      link: link
    }
  };

EDIT via @thinkingserious

Cela vous dérange-t-il de nous faire savoir où est le problème? Nous aimerions comprendre vos frustrations afin de pouvoir nous améliorer.

@drav96 ,

Cela vous dérange-t-il de partager à quoi ressemble votre modèle ?

Meilleures salutations,

Elmer

pourquoi supprimez-vous les caractères spéciaux dans les substitutionWrappers ??

dynamic_template_data: {
      'foo-bar': 'wtf',
      'bar_baz': 'wtf',
      'baz.bro': 'wtf',
      'foo': 'wtf'
    }

seulement {{foo}} renvoie la chaîne wtf dans les e-mails.

Je ne suis pas sûr @larafale , mais cela ne semble certainement pas raisonnable. En regardant le code source de ce SDK, je ne vois pas où ces clés sont modifiées.

Cela vous dérange-t-il de créer un problème distinct pour ce problème et d'inclure à quoi ressemble votre modèle HTML ? Je vais marquer le nouveau problème comme un bogue et essayer de le reproduire et de le corriger si nécessaire.

Bonjour,

J'essaie donc d'envoyer un modèle d'e-mail dynamique, mais je n'ai pas pu utiliser de substitutions ou de dynamic_template_data .
Mon modèle a des balises telles que {{fullname}} ou {{date}} et ces propriétés sont envoyées à la fonction send :

const msg = {
        to,
        from,
        templateId: template.id,
        dynamic_template_data: substitutions,
    };

    return sgMail.send(msg)

J'ai confirmé que l'objet substitutions a les bonnes propriétés avec les bonnes valeurs mais la substitution ne fonctionne pas.

Une idée de ce que je fais mal?

Merci.

@gianfelipe93
La structure est correcte. J'ai eu le même problème.
Ma solution consistait à désinstaller le package @sendgrid de mon projet et à l'installer à nouveau
Dites-moi si cela marche pour vous
const msg= { to: email, from: sendGridMail, templateId: emailTemplate.requestDemoEmail, dynamic_template_data: { name: data.name, email: data.email, } };

@drav96 merci

J'ajoute ce que j'espère être une documentation définitive après avoir perdu une autre heure de mon temps là-dessus. (Tout d'abord, merci à tous ceux qui ont perdu des heures de leur temps avant moi.)

1. Si votre identifiant de modèle commence par d- , alors substitutions ne fonctionnera pas, et vous devriez utiliser CAMEL-CASE dynamicTemplateData (voir ici , où ils convertissent quand même les clés snake_case en camelCase )
2. Si votre modèle commence par d- , alors setSubstitutionWrappers est ignoré en silence, et vous devez utiliser {{ et }} dans vos modèles

J'ajoute ce que j'espère être une documentation définitive après avoir perdu une autre heure de mon temps là-dessus. (Tout d'abord, merci à tous ceux qui ont perdu des heures de leur temps avant moi.)

1. Si votre identifiant de modèle commence par d- , alors substitutions ne fonctionnera pas, et vous devriez utiliser CAMEL-CASE dynamicTemplateData (voir ici , où ils convertissent quand même les clés snake_case en camelCase )
2. Si votre modèle commence par d- , alors setSubstitutionWrappers est ignoré en silence, et vous devez utiliser {{ et }} dans vos modèles

Dans mon cas, cela fonctionne avec dynamic_template_data même s'il a dans l'identifiant du modèle la lettre d-

Oui, cela fonctionne avec les clés de boîtier de serpent, mais il semble que les développeurs se soient engagés en interne dans le boîtier de chameau (voir la ligne à laquelle j'ai lié dans mon rapport ci-dessus). Ainsi, je recommanderais à tout nouveau code d'utiliser un étui camel.

Bonjour @kael-shipman,

Merci d'avoir pris le temps de nous aider, nous l'apprécions grandement!

Avez-vous vu cette documentation ? Sinon, pourriez-vous décrire votre chemin de découverte qui a conduit à une heure perdue. J'aimerais que cela ne se reproduise plus jamais et mes excuses pour la mauvaise expérience.

Meilleures salutations,

Elmer

@thinkingserious , merci pour votre compréhension et votre volonté d'améliorer la situation. Et désolé d'avoir eu un snippet là-haut. J'avais eu une looooooooooooooong journée ;).

Quoi qu'il en soit, le problème n'est pas tant que la documentation correcte (ish) existe quelque part, c'est qu'une grande partie de la documentation ancienne est encore prise dans les recherches Google. J'ai fait une recherche sur "sendgrid template fields" (tout à l'heure) et le premier résultat non publicitaire est celui-ci , qui, selon toutes les indications, est la documentation officielle, mais est clairement obsolète. Non seulement cela, mais il a également deux formats de substitution différents ( -firstName- et %firstName% ) et dit seulement "ce que vous utilisez peut dépendre de la bibliothèque SDK que vous utilisez", ce qui semble vraiment faux, compte tenu que toutes les bibliothèques SDK pointeraient vraisemblablement vers le même temple unique (qui n'a qu'un seul style de balises de substitution).

D'après mon expérience avec sendgrid, bien que j'apprécie grandement ce qui a été construit, cette confusion de la documentation est en fait la règle, pas l'exception. Je sais que cela avance probablement autant que le reste du monde du logiciel, mais ce serait bien de prendre environ un mois pour simplement normaliser toute la documentation, y mettre des numéros de version, etc., et peut-être faire quelque chose à propos du les meilleurs résultats de Google.

En tout cas merci encore !

De plus, la documentation que vous avez liée montre toujours dynamic_template_data dans le cas du serpent, et si c'est correct, alors je ne sais pas pourquoi le code lui-même semble le convertir en camelCase. Comme indiqué ci-dessus, je reconnais que Snake Case fonctionne, mais étant donné le code, il ne semble pas que la documentation doive recommander son utilisation.

Bonjour @kael-shipman,

Merci d'avoir pris le temps de fournir des commentaires détaillés!

En ce qui concerne le lien que vous avez fourni, cette documentation fait référence à notre API SMTP SendGrid, et non à l'API REST SendGrid v3 que ce SDK prend en charge. Cela dit, il ne faut pas s'attendre à ce que vous le sachiez. Je vais porter ce problème à l'attention de notre équipe de documentation pour voir s'il existe un moyen de le clarifier.

Nous venons tout juste de mettre à jour et de relancer notre documentation open source . J'espère que vous trouverez plus facile de naviguer.

Je vais corriger le fichier README pour utiliser camelCase par souci de cohérence. Merci d'avoir capté cela et de l'avoir porté à notre attention !

Merci encore et en gage de notre appréciation pour vos commentaires détaillés, nous aimerions vous offrir du butin . Prendre plaisir!

Meilleures salutations,

Elmer

Hé cool, merci :D

Le mar. 18 sept. 2018 à 18:09 Elmer Thomas [email protected]
a écrit:

Bonjour @kael-shipman https://github.com/kael-shipman ,

Merci d'avoir pris le temps de fournir des commentaires détaillés!

En ce qui concerne le lien que vous avez fourni, cette documentation est en référence
à notre API SMTP SendGrid, et non à l'API REST SendGrid v3 que ce SDK
les soutiens. Cela dit, il ne faut pas s'attendre à ce que vous le sachiez. Je vais apporter
ce problème à l'attention de notre équipe de documentation pour voir s'il y a un
moyen d'être clair.

Nous venons de mettre à jour et de relancer notre documentation open source
https://sendgrid.com/blog/how-to-get-the-most-from-sendgrids-new-knowledge-center/ .
J'espère que vous trouverez plus facile de naviguer.

Je vais corriger le fichier README pour utiliser camelCase par souci de cohérence. Merci pour
l'attraper et le porter à notre attention !

Merci encore et en gage de notre appréciation pour votre
commentaires, nous aimerions vous offrir du swag
https://dx.sendgrid.com/swag . Prendre plaisir!

Meilleures salutations,

Elmer

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/sendgrid/sendgrid-nodejs/issues/703#issuecomment-422588492 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADUIglZIH2d7imy-H7dekTo5A-v2Xau8ks5ucX0agaJpZM4Vev8b
.

Je parviens à faire fonctionner dynamic_template_data pour les variables de courrier électronique générales, mais que se passe-t-il si nous devons également ajouter des données dynamiques par destinataire ? Par exemple, les numéros de commande, la quantité de commande, etc. Je ne vois pas de cas d'utilisation pour cela dans les documents, mais peut-être que je l'oublie.

Note aux utilisateurs : lorsque vous utilisez des modèles, transmettez dynamic_template_data au lieu de substitutions .

@catamphetamine Malheureusement, j'ai voté contre votre commentaire parce que je viens de passer trop de temps à essayer de comprendre pourquoi le code de tout le monde semble fonctionner avec dynamicTemplateData , mais dans mon cas, les substitutions sont simplement supprimées. J'espère juste que d'autres auront une meilleure expérience.

Ma version :
"@sendgrid/mail": "^6.3.1"

Il s'avère que pour moi, j'ai dû faire ce qui suit (le contraire de ce que les gens disent):

// This seems to be the default, however, to avoid unexpected API changes,
// I'd rather set this manually
setSubstitutionWrappers("{{", "}}");

{
      subject: EMAIL_SUBJECT_ONBOARDING,
      templateId: "templateId",
      personalizations: [{
        to,
        // NOT WORKING WITH THIS ❌
        // dynamicTemplateData: {
        //   senderName: EMAIL_FROM_NAME,
        //   senderAddress: "an actual adress",
        // },

        // WORKS WITH THIS ✅
        substitutions: {
            senderName: EMAIL_FROM_NAME,
            senderAddress: "an actual adress",
        },
    }],
}

@thinkingserious aime l'outil. Veuillez continuer à améliorer les documents, couvrir les cas de bord, etc. 🎉❤️

METTRE À JOUR:

Merci à @catamphetamine downvote . Cela m'a fait penser que substitutions a peut-être fonctionné parce que j'ai fait setSubstitutionWrappers("{{", "}}"); . Hélas non. Je ne sais pas ce qui s'est passé, je suis peut-être fatigué, mais dynamicTemplateData fonctionne . Notez que c'est camelCase _(voir le commentaire de @kael-shipman)_ Je vois la plupart des exemples de cas de serpent. De plus, j'utilise les types TS pour sendgrid. Il n'y a pas de clé snake_case disponible dans la définition.

MISE À JOUR 2:

Concernant les types disponibles. J'ai trouvé dynamic_template_data dans le type PersonalizationJSON . Si vous utilisez les éléments suivants :
import { send } from "@sendgrid/mail";
puis après avoir vérifié le premier paramètre d'envoi, vous verrez MailData qui a la définition suivante :

export interface MailData {
  // ...
  personalizations?: PersonalizationData[],
  // ...
}

Je tombe alors sur les 2 types suivants :

export interface PersonalizationData {
  // omitted keys...
  dynamicTemplateData?: { [key: string]: string; };
  customArgs?: { [key: string]: string };
  sendAt?: number;
}

export interface PersonalizationJSON {
  // same omitted keys...
  dynamic_template_data?: { [key: string]: string; };
  custom_args?: { [key: string]: string; };
  send_at?: number;
}

Enfin, je reçois dynamic_template_data pour travailler de manière cohérente comme ceci :

{
    templateId: "d-templateId",
    dynamic_template_data: { name: "elton yet again"}, // <-- either here
    personalizations: [{
        to,
        dynamic_template_data: { name: "Elton again" }, // <-- or here
    }],
}

@thinkingserious De

Ok, je dois enquêter à nouveau. Je suis stupéfait parce que maintenant ni dynamicTemplateData ni substitutions fonctionnent pour moi.

METTRE À JOUR:
Renversé quelques tables, mais l'a fait fonctionner et a mis à jour mon commentaire précédent.

Enfin, je reçois dynamic_template_data pour fonctionner de manière cohérente comme suit :

{
    templateId: "d-templateId",
    dynamic_template_data: { name: "elton yet again"}, // <-- either here
    personalizations: [{
        to,
        dynamic_template_data: { name: "Elton again" }, // <-- or here
    }],
}

C'était un point important pour moi. J'essayais de définir un sujet différent dans le modèle transactionnel pour les e-mails to vs cc. Cela a fonctionné lorsque j'ai mis la propriété dynamic_template_data dans le tableau de personnalisation comme ci-dessus.

    const msg = {


         personalizations: [
            {
              to: req.body.to,
              dynamic_template_data : {
                subject: "Just to adsf...",
                full_name_from: req.body.full_name_from,
                full_name_to: req.body.full_name_to,
                manager: req.body.manager,
                message: req.body.message,
                badge: req.body.badge,
                badge_image: 'https://asdf' + req.body.badge_image
             }
            },
            {
              to: req.body.manager,
              dynamic_template_data : {
                subject: req.body.full_name_from + ' received a asdf asdf',
                full_name_from: req.body.full_name_from,
                full_name_to: req.body.full_name_to,
                manager: req.body.manager,
                message: req.body.message,
                badge: req.body.badge,
                badge_image: 'https://asdf' + req.body.badge_image
             }
            }
          ]
    };

La solution qui a fonctionné pour moi consiste à placer le dynamic_template_data à l'intérieur de l'objet de personnalisation de la manière exacte vue ci-dessous :

    "personalizations": [
        {
              "dynamic_template_data": {
            "fullname": "full Name",
            "useremail": ":[email protected]",
            "userphone": "56456",
            "usermsg": "tex fdsfgasdf t"
    },
            "to": [
                {
                    "email": "[email protected]"
                }
            ],
            "cc": [
                {
                    "email": "[email protected]"
                }
            ]
        }
]