Fancy email verify #807
Fancy email verify #807
Conversation
anthony-chaudhary
commented
Apr 9, 2022
|
Test summary
Run details
View run in Cypress Dashboard ➡️ Failures
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
||||||||||||||||||||||||||
|
Hey Anthony! Email looks neat!! A small suggestion for managing template code is to use https://flask.palletsprojects.com/en/2.1.x/templating/ That way you can keep the template in a separate html file (for easier editing). And just call render_template with whatever backend variables we need to inject into the template. |
|
Thanks Pablo! :)
That looks neat. I experimented with a different html loader for that exact
reason but it had some odd path problem (worked in console but not in app
code) so I just left it for the sake of time, and because during research I
noted the following:
Another solution, with various trade offs, is using a "by template
reference" method.
Most of these mail providers (this was built in send grid), provide the
ability to reference the template.
e.g. so it's like sendgrid.(template = 12, custom_variable_x) instead of
passing any html.
Basically inverting it, so we pass the variables we want to edit, instead
of passing the HTML to the application.
That means the editing can stay entirely in there, so for example we (e.g.
marketing) can publish an update to the HTML template without having to
publish any code etc
While I'm sure there are some downsides, my guess is long term that's
probably the stronger overall solution
In this specific case, we have mailgun implementation as our default, but
if we add sendgrid as an alternative mail provider, then we could switch to
this easily.
…On Mon, Apr 11, 2022 at 8:10 AM PJEstrada ***@***.***> wrote:
Hey Anthony! Email looks neat!!
A small suggestion for managing template code is to use
render_template_string from flask.
https://flask.palletsprojects.com/en/2.1.x/templating/
That way you can keep the template in a separate html file (for easier
editing). And just call render_template with whatever backend variables we
need to inject into the template.
—
Reply to this email directly, view it on GitHub
<#807 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEJ6DJEAWA34WMRLT4LMRATVEQ6FFANCNFSM5S6CGNSA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Yes sendgrid is really good for template management! I've used it before and works great. One thing to note with that though is that we might lose the ability for customization on more on premise installs, enterprise install. For example, on some enterprise envs maybe super admins might want to edit the template to add their company logo, different text etc. We can point them to sendgrid to do that, or we can create a small "template manager" for notifications or something similar. Those are more like v2,v3 ideas but it's good just noting both options too :) |
|
Cool :)
Right exactly, that customization dance is something that we will have to
think about more
…On Mon, Apr 11, 2022 at 4:12 PM PJEstrada ***@***.***> wrote:
Thanks Pablo! :) That looks neat. I experimented with a different html
loader for that exact reason but it had some odd path problem (worked in
console but not in app code) so I just left it for the sake of time, and
because during research I noted the following: Another solution, with
various trade offs, is using a "by template reference" method. Most of
these mail providers (this was built in send grid), provide the ability to
reference the template. e.g. so it's like sendgrid.(template = 12,
custom_variable_x) instead of passing any html. Basically inverting it, so
we pass the variables we want to edit, instead of passing the HTML to the
application. That means the editing can stay entirely in there, so for
example we (e.g. marketing) can publish an update to the HTML template
without having to publish any code etc While I'm sure there are some
downsides, my guess is long term that's probably the stronger overall
solution In this specific case, we have mailgun implementation as our
default, but if we add sendgrid as an alternative mail provider, then we
could switch to this easily.
… <#m_-2221945318860671228_>
On Mon, Apr 11, 2022 at 8:10 AM PJEstrada *@*.*> wrote: Hey Anthony!
Email looks neat!! A small suggestion for managing template code is to use
render_template_string from flask.
https://flask.palletsprojects.com/en/2.1.x/templating/
<https://flask.palletsprojects.com/en/2.1.x/templating/> That way you can
keep the template in a separate html file (for easier editing). And just
call render_template with whatever backend variables we need to inject into
the template. — Reply to this email directly, view it on GitHub <#807
(comment)
<#807 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJ6DJEAWA34WMRLT4LMRATVEQ6FFANCNFSM5S6CGNSA
<https://github.com/notifications/unsubscribe-auth/AEJ6DJEAWA34WMRLT4LMRATVEQ6FFANCNFSM5S6CGNSA>
. You are receiving this because you modified the open/close state.Message
ID: @.*>
Yes sendgrid is really good for template management! I've used it before
and works great.
One thing to note with that though is that we might lose the ability for
customization on more on premise installs, enterprise install. For example,
on some enterprise envs maybe super admins might want to edit the template
to add their company logo, different text etc. We can point them to
sendgrid to do that, or we can create a small "template manager" for
notifications or something similar.
Those are more like v2,v3 ideas but it's good just noting both options too
:)
—
Reply to this email directly, view it on GitHub
<#807 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEJ6DJEQPKOIT6NTILKQTU3VESWUXANCNFSM5S6CGNSA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
* Add fancy HTML template * add support for sending html