FWD: Urgent Opportunity to Claim Your React + MDX Newsletter Inheritance

Hello, my name is Cesar Alberca. I'm a freelancer, front-end architect from Spain, and I want to show you how to send spam through email with React. Yes, you heard it right. I'm going to show you how to create your own newsletter using MDX, which is a format I love for authoring content using React email components, and Resend to send all the newsletters and emails to your audience.

So yeah, the last thing is to show you how. Hello again, welcome to my talk. The name is quite long and it looks like spam because yeah, that's the idea. Showing you how to create a newsletter with emails. I thought it would be fun to have a spammy kind of title.

Let me introduce myself. My name is Cesar Alberca. I'm an AI front-end architect. I do freelancing. I also published a book about comedy and programming because, let's be honest, JavaScript is quite comical. I'm also an international speaker and a digital nomad. I like travelling around. I can find here... Oh, sorry. That's too bad. One second, it will not take long. Oh, I see. I have a few emails. Let me check it because I'm an inbox zero type of person, so I don't want to see six emails pending here. You have been selected to inherit... Oh, okay. I mean, it should be okay. We can send our API key and I think this shouldn't be a lot of money, right? No, of course I'm kidding. Don't send VTC or APKs to anyone, please. Through email, at least. I wanted to show you in an interactive way how to create a newsletter and make it fun.

So we'll be in the newsletter inside the talk. First, let's think about what really is a newsletter. We need to start with content. We need some format, right? We need to mark down HTML, text, or even use a visual editor. There's plenty online. We need to render this content into an email safe HTML. We'll talk about this later. We'll be using React email and we need a way to deliver those emails to the people. So we'll be using Resend.

First, I want to tell you about MDX. MDX is a format which mixes Markdown and JSX. It's a super cool format. You might have known about Markdown. It basically allows you to add some kind of symbols. For example, a hashtag, I call it, it lets you add titles, for example. Or you can add bold or italics. But with MDX, you also have the capability of adding JSX.

With JSX, now you suddenly can import React or Vue components inside this format. Why I think MDX is a great tool is because you might already know Markdown. It's familiar syntax. It integrates amazingly well with AI. For example, for my blog content, I ask AI to generate components that support the posts. One thing that I would recommend is that if that gives you goals and create content online, please don't use AI for that or for the content itself. You can use it for making sure it doesn't have grammatical errors or maybe to research, of course, if you validate after the research. But for content, it's so human. It's amazing to read something that someone has poured their time and effort into it. So that's why, for example, for my newsletter, I don't use AI to generate the content. I might use AI to translate, to research, to generate custom components. So now suddenly the newsletter becomes more interactive. It's more lively.

So it's a very interesting format, and you also get the preview on the web. With the MDX format, you can serve that content through email, as I will show you later, and also serve it on your website. That will serve as an archive and is great for SEO.

So the tech stack, we will use MDX to write the newsletters, components, we will use React email, rendering, we will use as well React email to convert it. Delivery, we will use Resend. And for the preview, Next.js.

So let's talk about the architecture. Basically, what I do is I have a folder in my projects that is called content and then I add the Slug. The Slug is the URL and also it serves as my identifier. There inside the Slug, I can have translatable content. I can have enMDX, which is for English, or ESMDX for Spanish.

I can have enMDX, which is for English, or ESMDX for Spanish. My newsletter, for example, I send it in English, but then if people want to check the Spanish version, they can go on the website. Now I read with Node.js the files and evaluate this MDX format translated into a loader that turns this MDX into React. I have a set of templates that allow me to reuse the same visual aspect for emails or for newsletters. I have a render method that takes these components and turns them into HTML. And then recent, I use it to send emails.

I don't have an email server. And the previous structure looks like this. I have a crc folder with the Slug newsletter. And in this case, I made it in this way because the code you'll receive it later. If you subscribe, of course, you can subscribe to the newsletter here. And then in this project, in this GitHub project, you can copy and paste and add a few environmental variables to have your newsletter up and running. But yeah, basically, that's the way I approached it. So it's easily shareable, but normally you'll want to maybe organize it in another different way.

So, for example, we have the API, we have the components, we have the content, the emails, the MDX, and this is very interesting because I have components to render MDX on email and on web because they are different targets and we use polymorphism for that. And then the templates, I can have, for example, two, but we can have multiple ones. And then, of course, I have some types written down to be able to use TypeScript to make sure that I don't make mistakes.

So when I want to create a new issue, I go over newsletters last content, I add the Slug, then the file, I start writing the newsletter, and then I create an email to link it to that enMDX file so that then I will be able to send it through reSend. And these are some of the environmental variables that I need. reSend API key, where am I sending this email from, the segment, because reSend you can segment your audience. So in a single audience, you can have different segments and topics because people inside the segment could subscribe to different topics, so different interests.

Let's talk about rendering. Emails are literally stuck in 2003. It's just terrible. So Gmail uses their own custom engine and has partial CSS support. It has a lot of limitations. Outlook on the desktop version, at least, yes, uses the Microsoft Engine to render the HTML. It's just crazy. Apple Mail is actually decent. Yahoo is quite cool. Outlook.com is different than Desktop Outlook. So when you send an email, you are not sure how is it going to be rendered unless you actually test it in that device, in that engine.

And yeah, that's super difficult. So the way you can handle that is with Kana email. This website is amazing. It allows you to check if Flex works. Oh, no, it doesn't. Huh, so how do we do layouts in emails? Well, I will tell you later. So what works in email? Inline styles, yes, we need to use those. Tables for layout. We cannot use CSS read, CSS Flexbox, forget about it. We need to use tables. Basic CSS, EMGs with absolute URLs. You cannot use relative because when you send an email to someone, then that image needs to be served from a server, right? So it needs to be an absolute URL.

Fun fact, that's how they track you. They add single pixel images inside the emails that they send you, and then when there's a request to that image on the server, then they know that you've opened the email. Anyway, I don't do that. I don't think you should either.

So yeah, if you are planning on using D with Flexbox or grid, no. Position, absolute or fixed, it doesn't work. Box shadow, for some reason, doesn't work either. CSS variables, of course not. Media queries, yeah. Everything needs to be inline. You cannot have external style sheets and then add class names to the emails. No, it needs to be inline. JavaScript, of course not.

Well, actually, kind of. There's this project by AMP email that allows you to add some interactivity in emails. It only works in Gmail, so not a lot of support, but quite interesting. How React email helps is this library that I use. It's quite nice because it allows me to write code like this. Yes, with components, with buttons, text, and then what it does, it renders tables all the way down. It's just terrible. Yeah, I don't want to code like this. I prefer this approach. Also, it allows me to use Tailwind, which is lovely.

How do we preview and test the emails? Well, there's a preview server included, which you can run with npx email dev, and it allows you to have a live preview, hold reload. Well, that doesn't really work all the time because it breaks with MDX files, so I just restart the server when I make a lot of changes in my MDX files. They added lintern compatibility and responsive views, which is amazing. However, the only way to test emails is to actually send it to your email client of choice. This preview server allows just to do that, so you can send it here. If it looks good in your browser, it probably does. Looks terrible.

So, let's talk about how I actually schedule my emails. What I use now is a GitHub Action that has a cron that runs daily at 7 a.m. It gets triggered, it fetches in the repository if there's a file with a specific format in the name that matches today's date, and if so, it creates a post in an API that is internal, and then that gets scheduled in Resend. I thought it would be fun to use GitHub Actions to schedule the newsletter, and so far so good. I really like the process.

The SendNewsletter action looks roughly like this. You have the full code in the GitHub repository. It's kind of simple. There's some error handling that I added too, but mostly it's this idea. And then the Broadcast API, which GitHub Actions connects to, looks like this, more or less. I basically import the newsletter slug, so that's the file, and then I extract the title, and then I render the component with the render function from React email. Then, what I do is I call Resend and then create a broadcast with the segment, the topic, and the different variables and parameters that I need. And then I schedule it for three o'clock ETC. You can send it in that moment. Here you can do what you prefer.

Here you can do what you prefer. So, why use GitHub Actions? Well, I wanted really a fine-grained control over sending the newsletter. I think it's a very flexible system and it's actually AI-aware. At the end of the day, it's just files, right? So, when I run an AI agent, I can tell it to modify things in the way that I want. So, I have a quite flexible system. It took me a while to get here, so by sharing it with you, I hope I make it easy for you.

Now, let's talk about different things that you need to take into consideration when creating a newsletter. First of all, you want to avoid the spam folder. So, there's different things that you need to set up. You need to set something called SPF, and DKIN, and then DMARC. It's just these weird names that just mainly what they do is just verify that who you are is really who you are. So, you just need to add several DNS records to your domain. Reason handles some of it. So, yeah, check the documentation to see what you actually need.

Then you have an HTML size limit. So, Gmail and other email clients, they clip emails larger than 102 kilobytes. So, you'll see your beautiful newsletter looking like this with message clip, and then the users need to click here in view entire message to open the complete email. The way to stay under 102 kilobytes. Well, minimize inline styles, hopefully by using Tailwind. This is not a problem. You should not use base64 to encode images. So, always use hosted URLs. Keep content focused, and, yeah, remove necessary web space in production builds. React email handles this for you. Also, if you are adding a lot of code and you have syntax coloring for your code, that actually can make you go over the limit. So, be mindful with that. And then, yes, you need people to be able to unsubscribe from your newsletter. Yes, I checked. There's no other way. So, there's these two acts.

It's called spam and then GDPR and regulations that say that you must have an unsubscribe link in every email that is not transactional, meaning that that means that in legal emails, for example, or policy updates or stuff like that, you should not have an unsubscribe link there because the users, if they have an account with you, then they need to receive those emails legally. The unsubscribe button must work within 10 business days. So, don't add any waits or timeouts there. And then, you must include your physical mailing address in your emails. Yes, you should do that. If you don't want to add your personal physical mailing address, then what you can do is, there are services that allow you to have a mailing address with them and you pay them a monthly fee.

One thing I love about Reason is that since you segment your audience and you have topics, people, when they unsubscribe, they can unsubscribe for specific topics. Let's say that you run a Black Friday promotion and some people have bought that promotion, then they might not want to receive more Black Friday promotions. So, if the phone is unsubscribing to your whole newsletter, then they can unsubscribe just for the topic. So, with Reason, you can add special text, so then it adds the unsubscribe link. And then, you can have a one-click unsubscribe in the headers, which will show here a button that says unsubscribe. Very handy. And yeah, testing that was definitely the thing that I spent most time on, right? Checking on Gmail, on Gmail web, Gmail iOS, which is different from Gmail Android. So yeah, that's just very, very time-consuming.

Dark mode is impossible, so don't even try. Different clients handle it differently. So, you should have a very simple white email and then if people have that mode, it's actually the client who inverts the colors to have a dark mode for people who want that. Verify your links work, test unsubscribe flow, check on mobile devices, and yeah, here you have a neat checklist. And now, well, thank you so much for sticking until the end of this talk. So, a quick recap. We used MDX to write content with markdown and use React components when needed. React email, it allows us to code in React with components and then React email is in charge of translating those components into tables. And then recent, we use their API to send the emails. Continuous integration we use to schedule the emails. And then we also talked about different things that you need to consider when creating a newsletter. And now is the last time you have to subscribe to this newsletter that is going to have a very short life. It's going to send an email and that's it. So, you can subscribe here and you'll receive the code, the slides, and everything you need right in your inbox. And now it's time for the live demo. So, the way I did it was, of course, through here.

So, here let's see. Yes, I think I want to send this. Okay, wish me luck. I hope it works and send. Okay, hopefully you'll shortly receive in your email, if you subscribed, all this information. But don't worry if you didn't subscribe and still want to see what people actually received. You can go here to the newsletter and then you can check what people received with all the slides and demo code and links.

So, yeah, you won't miss out. Here are also some of the resources. That was it for me. So, here you can find all my socials or my links. And, of course, I have a newsletter where I talk weekly about front-end AI architecture. And, yeah, I show you how you can use best practices with these AI agents nowadays. How you can create higher quality code so you have fewer errors and regain the trust in what you put in production works tomorrow and 10 years from now. And that was it.

Thank you. Thank you. Thank you very much. Please, if you build a newsletter, send me an email. Thank you very much. Bye.