Sending emails from a Create-React-App

Jose Javier Señaris — Thu, 19 Jul 2018 20:38:33 +0000

Castillo de los Tres Reyes Magos del Morro, Havana, Cuba

A few days ago we added a new Invite people by email feature, to an app we’re developing internally at Ingenious. The app consists of a board with a collaborative text editor and some cards that complement the behavioral insight approach used in product design consulting. Tech-wise the app is built with React, bootstrapped with create-react-app, Firebase as the backend and hosted on Heroku.

We needed to invite people as Editors of the board by sending an email with the board URL. To keep things simple, we first tried EmailJS, a service that allows sending emails without focusing on any server code. EmailJS would have been an excellent choice but we needed a bit more of control on how the email was generated, for example, it is impossible to add custom fonts to the HTML version of the email.

We choose, as the path of least disruption, to set up a small Express (Node) backend to serve our React app and publish an endpoint that takes care of sending the email. I’ve found several tutorials on the topic, but most of them were outdated or incomplete, so wanted to share a walk through of our solution in case it benefits you as well.

If you like to deep dive into the code, check the demo link in the end.

The first task is to transform our client only React project into a full express app with the following steps:

Remove create-react-app-buildpack from the app and setup the default heroku/nodejs buildpack.
Move the root React app files into a subdirectory, e.g. react-ui.
Copy server/index.js, package.json, and_ .gitignore_ files in the root of the project from the buildpack example repo.
Commit and push to the Heroku origin.

To keep the React SPA up and working we need to serve all its assets using the static express middleware. Afterward, we can process any request to perform custom actions, such as sending an email, using the common get(…), post(…) express handlers. Finally, we can re-route any non API request to the SPA entry point, that way the client side routing continues to work as expected. Check the code below:

The key here is to run npm run buildin the React project which copies all the assets: JS, CSS, images, etc. to the build folder. The command also generates an index.html file which can be returned by our web server. This process can be triggered by adding a post-build script in the express package.json file:

To generate the email we can rely on the email-templates package. It allows us to obtain . html and . text versions of the content and later send the email with a 3rd party provider. We’ll show how to work with the Mailjet API but, any other vendor will do.

Finally, we modify the express route handler to obtain the email address, alongside the user-provided content used in the . ejs template and send the email.

Creating HTML emails that work well in many different email clients is a daunting task. If you ever need to build a custom email take a look into MJML, a component-based framework that generates responsive emails templates. It ships with some excellent templates and an easy to grasp documentation that gets the task done.

You can check a full demo repository here.

A tale of Higher-Order Components & Render Props

Jose Javier Señaris — Sat, 03 Feb 2018 14:57:16 +0000

In the past few months there has been an endless debate in the react community on Higher-Order Components vs. Render Props as techniques for sharing concerns and reusing common logic among components. There are tons of tutorials and courses explaining their benefits and drawbacks. Just in case you haven’t seen any of those resources, head over to the React docs which have a short and focused introduction to both terms.

Here at Ingenious we have our fair share of React Projects, of all sizes, among various teams. So far we’ve been using Higher-Order Components (HOC for short) mainly through libraries like recompose for implementing our own “Reuse this logic” component or as direct clients of popular libraries like react-redux whose main features are exposed via HOC. Just a few days ago we had the opportunity of “joining” the debate and choose one of the two approaches to implementing a new feature. The story goes like this.

We built a product where users need to leave recommendations to other users, and each recommendation can have a list of comments. Think of “Judges” that provide advice to “Participants” of a contest where anyone, be it a Judge or Participant, can give feedback multiple times on a given Recommendation.

We went all in and proposed a beautiful UI that looks similar to this:

Recommendations with nested comments

Everything went smoothly, client was happy and end of blog post.

Actually, at some point, the client requested that both Recommendations and their Comments should be editable within the first 10 minutes of being created. The final intended set of actions a user can perform with Recommendations and Comments were quite different, but the Edit workflow was pretty much the same for both entities. We wanted to make the edition similar to what users already know, which meant reusing as much as possible the UI we already had. The goal now was to add a way of selecting a recommendation or comment, fill the same input used to create it, and save the modification.

We started with Comments and built a HOC to allow editing them. Fast forwarding in time, after refactoring the common bits, we ended up with a component that allowed us to use the same logic to create/edit both Recommendations and Comments. Something like this:

By wrapping the Recommendations and Comments listings with editRecentEntity, we only need to toggle the edition mode in both entities and problem solved :-)

The Edit/Create links toggle the Edition mode for either Recommendations or Comments

A few days later another client request arrived. Now we needed to show “archived” Recommendations, which are read-only entries with more than three months old, and present a Loading indicator instead of the input form while the more recent “active” Recommendations are being retrieved from the server.

Up to this point we simply rendered a list of Recommendations followed by a Form component, all wrapped up with the editRecentEntity HOC. The Comments listing used the same pattern as well.

Hiding the forms for the archived entries has a straightforward solution, the problem then was that adding more code to show a Loading Spinner, instead of the Form, seems a bit clumsy given that it was only necessary for one type of Recommendations.

A clean solution here, was to move the responsibility of when and how to show the form, to the parent component by using the special React children prop. This idea combined with the Render Props pattern allowed to pass the necessary props to the form, so we can continue to support the creation and edition of Recommendations.

Render Props to the rescue…

Here the Render Props pattern provides an explicit API for communication between Parent and Children components. All three properties, passed to the form, depends on the logic already implemented in editRecentEntity and at the same time the “marvelous” Loading component can be used only where and how it’s needed. Go and play with the final code if that’s your thing.

The main lesson here, at least the one we learned building this feature, is that what matters most is solving the problem at hand without taking sides on hype-oriented battles of which pattern is better than the other. If the client would have stopped with the Create/Edit functionality, our code will be as worthy as the final version. Be it Higher-Order Components or Render Props, always try to choose whatever pattern, tool, library helps you solve the problem as clear as possible.

That’s all folks… Happy Coding.

PS: If you liked, or even better, disliked what you read here please drops us a line. We love to talk about technology and are always looking for awesome people that enjoy learning with and teaching us how to solve people problems.

DEV Community: Jose Javier Señaris

Sending emails from a Create-React-App

A tale of Higher-Order Components & Render Props