|
Getting your Trinity Audio player ready...
|
Introduction
Are you tired of triggering emails every time to validate UI changes in an email template? Or worried about setting up a local environment to send emails during development?
This blog offers a simple solution. Learn how to preview emails for validation directly during development.
Time for a story
Ratan, a software developer, created a Ruby on Rails (ROR) blog application and released it.
The application can analyze blog content and provide metrics like page views, average time on page, predicted bounce rate, etc. However, the blog administrator is frustrated with having to periodically check the application for new blog submissions to review the metrics.
To make the administrator’s work easier, Ratan decided to develop an email notification that would be sent whenever a new blog is submitted.
Additionally, he decided to redesign the existing emails for better UI unification.
What will be the challenge?
It seems like a simple task, right? He just needs to add an appealing design and include the blog metrics that the application already generates. The other task is straightforward too, as it’s just a UI change. So, what challenge will Ratan face?
Developing or redesigning the emails may not be a big task, the real challenge lies in validating the email designs and ensuring proper content alignment during development.
How Rails application trigger email?
A Rails application uses ActionMailer to create and send emails. For each email, we need to create a mailer method. These methods contain the business logic, such as accessing Rails methods to set values for the email content, configuring the ‘from’ and ‘to’ addresses, and more. The mailer method then renders the corresponding .html.erb file to generate the email and send it to the targeted user.
In development mode, emails are sent to the localhost. To receive an email, we simply call the respective mailer method. It seems straightforward, so why is this a challenge for Ratan?
The issue is that the email we receive is static. This means that any changes made to the .html.erb file or the values in the mailer method won’t be reflected in the emails we’ve already received. Ratan needs to trigger the mailer method again to see the updated email.
This means every time Ratan wants to validate during development, he has to manually trigger the mailer method to send a new email. It becomes a tedious and repetitive process, right?
Solution
Let’s help Ratan by introducing him to “Preview Email Support by ActionMailer.” What? Can we actually preview emails in development mode?
Don’t worry, it’s not complicated. Yes, ActionMailer does support email previewing in development mode, and the setup is quite simple.
ActionMailer provides a special URL (http://localhost:3000/rails/mailers) that renders all the emails. Let’s see how to set this up…
For our mailer, “PostCountMailer,” we need to create a preview named “PostCountMailerPreview,” which should be located in “test/mailers/previews/post_count_mailer_preview.rb.” To preview the email, implement a method (e.g., “notify_count“) in the “PostCountMailerPreview” class and call the mailer method, “PostCountMailer.notify_count,” within it.
Then preview will be available in http://localhost:3000/rails/mailers
Reflecting the changes dynamically!!!
If we make any changes to the mailer method or its corresponding .html.erb file, the preview will automatically reload and render the updated version, allowing us to visually see the new styles.
It’s not just for a single email! A list of all available previews will be shown at http://localhost:3000/rails/mailers.
Path configuration
By default, previews are stored in “test/mailers/previews.” If you want to change the location, you can use the preview_path configuration. For example, to store previews in “lib/mailers,” configure it like this in config/development.rb:
config.action_mailer.preview_path = ‘lib/mailers’
Note that this feature is only available in development mode and not in production!
Conclusion
This will help Ratan preview the emails and validate styles and content during development without triggering the method multiple times.
Next, Ratan plans to add security features to the blog submission APIs by implementing rate limiting, all without relying on any external gems.
Stay tuned for the next blog, where we’ll dive into that. Until then, I’m signing off… Anush Kumar S.
Reference
[1] Action Mailer – Rails Guide
