Email Sending Using MeteorJS: Implementation Process and Email Templates

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.

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

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

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.

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.

</li>
<li dir="ltr">

[sendFor] – this method initiates emails sending to users

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

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.

It’s a quite simple method that calls template rendering and email sending method.

This method calls Email.send Meteor method for messages sending.

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.

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.

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.

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.

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:

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.

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

and the resulting path will be https://www.google.com.ua/user-list.