Sendgrid-nodejs: Adición de compatibilidad con plantillas dinámicas

Actualice su documentación. Acabo de pasar una hora tratando de averiguar por qué las sustituciones no funcionaban con la API v3.

Mis disculpas por la mala experiencia @ jharris-code.

Agregué su voto a este tema para ayudarlo a ganar prioridad. Creo que se actualizará pronto porque es posible que tengamos PR # 711.

Es muy tonto que la ausencia de documentación bloquee la publicación del código real.

Hola @catamphetamine ,

El código fue lanzado en v6.3.1 . Espero que te ayude, ¡gracias!

Con los mejores deseos,

Elmer

@thinkingserious Oh, genial, en realidad no se me pasó por la cabeza actualizar la versión de la biblioteca.
Lo intentaré, gracias.

Nota para los usuarios: al usar plantillas, pase dynamic_template_data lugar de substitutions .

Ahora tienes que cambiar "sustituciones:" por "datos_template_dinámicos:"

Y las plantillas utilizan manillares ya no es necesario especificar "substitutionWrappers"

Este ejemplo en sus casos de uso todavía usa sustituciones en lugar de dynamic_template_data. Por favor, actualice, definitivamente me tomó un par de horas jugar con el SDK y buscar antes de encontrar este hilo. (Además, sus documentos de API no mencionan nada sobre esto, lo que tampoco ayudó.
Además, substitutionWrappers no parece funcionar con dynamic_template_data en absoluto. Independientemente de incluir el par de valor clave substitutionWrappers: ['*|', '|*'] en mi objeto de mensaje, solo se completaron las variables de plantilla envueltas en llaves. (¿Están ahora forzando intencionalmente a todos a usar la sintaxis del manillar para las plantillas?)

Mis disculpas @ josh-yonomi,

Actualicé la documentación en función de sus comentarios.

Para nuestras nuevas plantillas, utilizan la sintaxis de manillar. Las plantillas heredadas siguen funcionando como antes.

Con los mejores deseos,

Elmer

Recibo el correo electrónico pero las sustituciones no funcionan. ¿Qué puede causar el problema?

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

EDITAR a través de @thinkingserious

¿Le importaría hacernos saber dónde está el problema? Nos encantaría comprender sus frustraciones para que podamos mejorar.

@ drav96 ,

¿Te importaría compartir cómo se ve tu plantilla?

Con los mejores deseos,

Elmer

¿Por qué eliminas los caracteres especiales en los envoltorios de sustitución?

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

solo {{foo}} return wtf cadena en correos electrónicos.

No estoy seguro @larafale , pero eso ciertamente no parece razonable. Al mirar el código fuente de este SDK, no veo dónde se modifican esas claves.

¿Le importaría crear un problema separado para este problema e incluir cómo se ve su plantilla HTML? Marcaré el nuevo problema como un error e intentaré reproducirlo y corregirlo si es necesario.

Hola,

Entonces, estoy tratando de enviar un correo electrónico de plantilla dinámica, sin embargo, no he podido usar sustituciones o dynamic_template_data .
Mi plantilla tiene etiquetas como {{fullname}} o {{date}} y estas propiedades se envían a la función send :

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

    return sgMail.send(msg)

Confirmé que el objeto substitutions tiene las propiedades correctas con los valores correctos, pero la sustitución no funciona.

¿Alguna idea de lo que estoy haciendo mal?

Gracias.

@ gianfelipe93
La estructura es correcta. Yo tuve el mismo problema.
Mi solución fue desinstalar el paquete @sendgrid de mi proyecto e instalarlo nuevamente
Avísame si te funciona
const msg= { to: email, from: sendGridMail, templateId: emailTemplate.requestDemoEmail, dynamic_template_data: { name: data.name, email: data.email, } };

@ drav96 gracias amigo, ya está funcionando

Añadiendo lo que espero sea una documentación definitiva después de perder otra hora de mi tiempo en esto. (Primero, gracias a todos los que perdieron horas de su tiempo antes que yo).

1. Si su ID de plantilla comienza con d- , entonces substitutions no funcionará, y debe usar CAMEL-CASE dynamicTemplateData (vea aquí , donde convierten las claves de snake_case en camelCase de todos modos )
2. Si su plantilla comienza con d- , entonces setSubstitutionWrappers se ignora en silencio y debe usar {{ y }} en sus plantillas

Añadiendo lo que espero sea una documentación definitiva después de perder otra hora de mi tiempo en esto. (Primero, gracias a todos los que perdieron horas de su tiempo antes que yo).

1. Si su ID de plantilla comienza con d- , entonces substitutions no funcionará, y debe usar CAMEL-CASE dynamicTemplateData (vea aquí , donde convierten las claves de snake_case en camelCase de todos modos )
2. Si su plantilla comienza con d- , entonces setSubstitutionWrappers se ignora en silencio y debe usar {{ y }} en sus plantillas

En mi caso, funciona con dynamic_template_data incluso si tiene en la identificación de la plantilla la letra d-

Sí, funciona con claves de casos de serpientes, pero parece que los desarrolladores se han comprometido internamente con el caso de camellos (consulte la línea a la que me vinculé en mi informe anterior). Por lo tanto, recomendaría todo el uso de código nuevo en caso de camello.

Hola @ kael-shipman,

Gracias por tomarse el tiempo para ayudar, ¡lo apreciamos mucho!

¿Viste esta documentación ? Si no es así, ¿le importaría describir su camino de descubrimiento que lo llevó a perder una hora? Me encantaría que eso nunca vuelva a suceder y mis disculpas por la mala experiencia.

Con los mejores deseos,

Elmer

@thinkingserious , gracias por su comprensión y voluntad para mejorar la situación. Y lo siento por haber sido tan mezquino. Había tenido un día muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu una

De todos modos, el problema no es tanto que la documentación correcta (más o menos) exista en alguna parte, es que mucha documentación antigua todavía está atrapada en las búsquedas de Google. Hice una búsqueda de "campos de plantilla de sendgrid" (justo ahora) y el primer resultado no publicitario es este , que según todas las indicaciones es la documentación oficial, pero está claramente desactualizado. No solo eso, sino que también tiene dos formatos de sustitución diferentes ( -firstName- y %firstName% ) y solo dice "lo que use puede depender de la biblioteca de SDK que use", lo que parece realmente fuera de lugar, considerando que todas las bibliotecas del SDK presumiblemente apuntarían al mismo templo único (que solo tiene un estilo de etiquetas de sustitución).

En mi experiencia con sendgrid, aunque aprecio mucho lo que se ha construido, esta confusión de documentación es en realidad la regla, no la excepción. Sé que probablemente está avanzando tanto como el resto del mundo del software, pero sería bueno tomarse un mes más o menos para normalizar toda la documentación, ponerle números de versión, etc., y tal vez hacer algo al respecto. los mejores éxitos de Google.

De todos modos, gracias de nuevo!

Además, la documentación que vinculó todavía muestra dynamic_template_data en caso de serpiente, y si eso es correcto, entonces no estoy seguro de por qué el código en sí parece convertirlo en camelCase. Como se señaló anteriormente, reconozco que el caso de la serpiente funciona, pero dado el código, no parece que la documentación deba recomendar su uso.

Hola @ kael-shipman,

¡Gracias por tomarse el tiempo para brindar comentarios detallados!

Con respecto al enlace que proporcionó, esa documentación hace referencia a nuestra API SendGrid SMTP, no a la API REST SendGrid v3 que admite este SDK. Dicho esto, no se debe esperar que lo sepas. Informaré sobre este problema a nuestro equipo de documentación para ver si hay una manera de aclararlo.

Recientemente actualizamos y relanzamos nuestra documentación de código abierto . Espero que te resulte más fácil navegar.

Arreglaré el archivo README para usar camelCase para mantener la coherencia. ¡Gracias por captar eso y hacérnoslo saber!

Gracias de nuevo y como muestra de nuestro agradecimiento por sus comentarios detallados, nos gustaría ofrecerle un poco de información . ¡Disfrutar!

Con los mejores deseos,

Elmer

Hola genial, gracias: D

El martes, 18 de septiembre de 2018 a las 6:09 p.m. Elmer Thomas [email protected]
escribió:

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

¡Gracias por tomarse el tiempo para brindar comentarios detallados!

Con respecto al enlace que proporcionó, esa documentación es de referencia
a nuestra API SMTP SendGrid, no a la API REST SendGrid v3 que este SDK
apoyos. Dicho esto, no se debe esperar que lo sepas. Traeré
este problema a la atención de nuestro equipo de documentación para ver si hay una
manera de dejarlo claro.

Recientemente actualizamos y relanzamos nuestra documentación de código abierto.
https://sendgrid.com/blog/how-to-get-the-most-from-sendgrids-new-knowledge-center/ .
Espero que te resulte más fácil navegar.

Arreglaré el archivo README para usar camelCase para mantener la coherencia. Gracias por
captar eso y traerlo a nuestra atención!

Gracias de nuevo y como muestra de nuestro agradecimiento por su detallada
retroalimentación, nos gustaría ofrecerle un botín
https://dx.sendgrid.com/swag . ¡Disfrutar!

Con los mejores deseos,

Elmer

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/sendgrid/sendgrid-nodejs/issues/703#issuecomment-422588492 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADUIglZIH2d7imy-H7dekTo5A-v2Xau8ks5ucX0agaJpZM4Vev8b
.

Puedo hacer que dynamic_template_data funcione para variables generales de correo electrónico, pero ¿qué sucede si también necesitamos agregar datos dinámicos por destinatario? Por ejemplo, números de pedido, cantidad de pedido, etc. No veo un caso de uso para esto en los documentos, pero tal vez lo esté pasando por alto.

Nota para los usuarios: al usar plantillas, pase dynamic_template_data lugar de substitutions .

@catamphetamine Desafortunadamente, he votado en contra de tu comentario porque acabo de pasar demasiado tiempo tratando de averiguar por qué el código de todos parece estar funcionando con dynamicTemplateData , pero en mi caso, las sustituciones simplemente se eliminan. Solo espero que otros tengan una mejor experiencia.

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

Resulta que para mí tuve que hacer lo siguiente (lo contrario de lo que dice la gente):

// 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 amo la herramienta. Continúe mejorando los documentos, cubriendo los casos de borde, etc. 🎉❤️

ACTUALIZAR:

Gracias a @catamphetamine downvote. Me hizo pensar que puede ser que substitutions funcionó porque yo hice setSubstitutionWrappers("{{", "}}"); . Ay, no. No sé qué pasó. Puede que esté cansado, pero dynamicTemplateData funciona . Tenga en cuenta que es camelCase _ (consulte el comentario de @ kael-shipman) _ Veo la mayoría de los ejemplos de casos de serpientes. Además, estoy usando tipos de TS para sendgrid. No hay una clave snake_case disponible en la definición.

ACTUALIZACIÓN 2:

Respecto a los tipos disponibles. Encontré dynamic_template_data en PersonalizationJSON tipo. Si usa lo siguiente:
import { send } from "@sendgrid/mail";
luego, después de verificar el primer parámetro para enviar, verá MailData que tiene la siguiente definición:

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

Luego me tropiezo con los siguientes 2 tipos:

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

Finalmente, obtengo dynamic_template_data para trabajar consistentemente así:

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

@thinkingserious Claramente, hay problemas de definición de tipos que deben solucionarse. Puedo crear un PR más tarde.

Ok, necesito investigar de nuevo. Estoy estupefacto porque ahora ni dynamicTemplateData ni substitutions funcionan para mí.

ACTUALIZAR:
Volteé algunas tablas, pero lo hice funcionar y actualicé mi comentario anterior.

Finalmente, obtengo dynamic_template_data para trabajar consistentemente así:

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

Este fue un punto importante para mí. Estaba tratando de establecer un asunto en una plantilla transaccional diferente para los correos electrónicos a vs cc. Funcionó cuando puse la propiedad dynamic_template_data dentro de la matriz de personalización como se indica arriba.

    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 solución que funcionó para mí es colocar dynamic_template_data dentro del objeto de personalización de la manera exacta que se ve a continuación:

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