Sending emails is a common task that occurs in almost every project. For
sure, sending one or two messages will not be a problem, but what if there
are dozens of emails to be sent? Most frameworks offer plenty solutions for
solving this task. And Meteor is no exception. It provides a
simple and clear interface
designed for sending emails with meteorJS. The question is what if it’s
necessary to organize the sending of multiple emails with various templates
and footers, and according to corresponding events? Furthermore, what if
you need to integrate this system into a large working application? This
article describes one of the best ways to solve this problem and explains
how to send emails using MeteorJS.

Problems That Are Necessary to Address

While working on the development of a complex system for email sending in
MeteorJS, I’ve faced a number of challenges. The solution I came up with
allows to significantly decrease the amount of time spent on development,
simplifies and clarifies the system, and thus, its future support. Below is
the list of issues to be covered:

building flexible dynamic email templates for MeteorJS

dynamic generation of footers for each template

implementation of sending emails via the whole application

implementation of files attachment tool to send those files in
emails

Working with Email Templates

Business emails that are designed to make life easier are quite complicated
and contain a lot of information and styles. Besides, we often have to use
the same style in the email header. Styles can be similar or significantly
vary for different inquiries. For example, a user invitation letter and an
email confirmation may use the same template, while a monthly sales report
email requires an entirely different one. This relates to footers as well.
The text of the letter is not always static; for example, the very same
sales report email can be generated once a month and use different data
from the application. Let’s imagine that client needs to send a few letters
like the following one:

As I’ve mentioned above, the text of such letters can change according to
the task peculiarities and can be dynamically generated using various
system data. We can divide this email into the following components:

● [Layout] – the main email template. Usually, all emails will have
approximately the same set of header styles and other details. There is a
slight chance of their change. That’s why it’s better to set them out
separately to avoid repeating yourself and duplicating the code, even if
that’s the layout code.

● [Body of email] – the main text of the email. This content will be
different for each letter.

● [Footer] – this content may vary as well as it can be the same for
different emails.

Let’s move to the practical realization of the proposed solution. First of
all, it’s necessary to create a Layout. Let’s create a layout.html file
with the following layout

Pay attention that we’ve used {{{email}}} instead of {{email}}. This means
that parameter email can be a complete html layout. Further there are more
details about the realization of email sending.

Next, we have to create a footer. As there can be a few of them, let’s call
it footerA.html. Of course, you can name them correctly for the particular
tasks.

The footer may contain an arbitrary layout with dynamic data. In this case,
nameOfApp is the application name. Next step is to create the email itself.
Let’s call it invitationEmail.html.

Building and Sending the Templates

Before you send email templates, it’s necessary to render them. You can use SSR package to do
it. You’ll also need Assets class to read the corresponding html file.
Generally, the code will look similar to the following snippet:

However, it’s not the best solution to write such code in every part of our
application. Besides, it’s not clear what to do with our footer and layout.
That’s why the next step is building an EmailSender class. We’ll use it the
following way:

Such class looks more elegant and is more convenient to use. You can skip
the methods withFooter and withAttachments if the email doesn’t require a
footer or the attachments. Let’s move directly to the implementation of
this class.

EmailSender Class Implementation

First, let’s look at the structure of the class, and let’s discuss the
methods that we need to implement.

[sendFor] – this method initiates emails sending to users

[_sendEmail] – sends email to one user

[_renderTemplate] – is responsible for building an email template

[withFooter] – receives and stores footer data that are used for
building the template

[withAttachments] – receives Attachments (an array of pdf files)
and stores it for further sending

Now we can move to the direct implementation of each of these methods.

EmailSender Constructor

A constructor initiates data for class operation. First, we need to save
sender’s email _senderEmail. We can get it from the settings or write it
directly in the constructor if it’s not critical. Then it’s necessary to
save the path to the templates. In Meteor application such files are stored
in a folder called ‘private’. That’s why you should place your templates
and layout into the folder private/templates/emails, and your footer
template to private/templates/footers. These paths can be arbitrary, but
don’t forget to indicate them in the constructor.

EmailSender sendFor

EmailSender _sendMail

We use
Meteor.defer
to send messages in a background mode to avoid waiting till the messages
are sent. It’s optional for each application.

EmailSender _renderTemplate

This method is responsible for email template rendering. Firstly, the
message template and footer are rendered. Then the layout itself is
rendered, with the email template and footer indicated as its parameters.
Then this html file is saved to be sent with the email.

EmailSender withFooter

This method renders footer template and saves it for further sending with
the email.

At the end of the method, it’s important to call return this to be able to
create a chain of calls.

EmailSender withAttachments

This method saves attachments for further sending with the email. Below I
will explain what are those attachments and how to implement them.

So such a small class will allow you to build great flexible email
templates avoiding massive code duplication both in templates and in places
of emails sending.

Work with Attachments

Often it is necessary to send an email with an included file, e. g. a
report file. Let’s take a look at the way of creating and sending pdf files
in Meteor app. It’s possible to use the same templates that we’ve used
before to build a pdf file. To convert html to pdf, you can use html-pdf package.
First, let’s create a file called invitationDocument.thml, and save it in
private/templates/pdfs directory of our project.

To make it simpler, this document already contains the layout. If it’s
necessary to use the templates, you can do it just the same way as when you
work with emails.

The next step is creating a PdfBuilder. As a result we get a convenient
code to call building of the pdf files:

PdfBuilder Class Realization

It’s a quite simple class that initializes data for pdf document in the
constructor. It renders the document template with _renderTemplate method.
The last step is the pdf file creation with build method and its sending to
callback.

We need callback as the hardware and such package implementation requires
time to create this file.

Conclusion

We have divided an imaginary email into a few templates to avoid massive
layout duplication in every new letter; created and organized the
templates. After this, we wrote the class that helps to organize email
sending in a large system easily and arranged a possibility to attach files
to these emails. So now to send an invitation email with an attached pdf
file to our app to user it’s enough to call

Just three strings which you can place anywhere in your project!

P.S.

In emails, it’s often necessary to indicate a link to the website of the
system developed. However, the system may change its path, or there may
exist two servers: one for the development, and one for the app itself.
That’s why it’s not the best solution to indicate the path in templates.
It’s necessary to be able to generate the root URL according to the place
where the application is hosted. The method shown below allows creating the
appropriate path with parameters.

This method is a part of EmailSender and is static for a more convenient
use.

So, if it’s necessary to generate a full path to the user-list page, it’s
enough to call