How to build templates server side

[rahulravindran0108]

Is there a way to do this functionality server side completely. I'm actually trying to run a cron job to generate emails to be sent to my users. This package is amazing to iterate on email templates but I'm having a hard time figuring out how to install all of this functionality in something like firebase functions.

What's the best workflow for this ?

[rahulravindran0108]

nvm I think I found out what needs to be done. The steps would be:

• use the starter repo.
• Iterate on your email template
• export out the js code
• import in your backend and just call the function with right props for substitution.

[gabrielmfern]

You can also do bundling in the email templates and use them, like what Cloudflare provides out of the box.

[zachgoll]

Here's an example of what @rahulravindran0108 listed out above in case anyone is struggling with this:

import EmailComponent from "path/to/component";
import { render } from "@react-email/render";

const html = render(EmailComponent({prop1: 'value'}))

[yashsway]

@zachgoll I'm attempting to do something very similar. Have the package where I build these templates be publish-able so my Node BE can consume it.

This can only run in Node yeah? not in the browser?

[gabrielmfern]

@yashsway Rendering can be done in the browser, if you do find it doesn't work somehow it is a bug that needs fixing and would be great if you made an issue for.

[Iamstanlee]

hey @zachgoll
I'm getting this using your approach
error - node_modules/@react-email/render/dist/index.mjs (10:17) @ render
error - react_dom_server__WEBPACK_IMPORTED_MODULE_0__.renderToStaticMarkup is not a function

Any help:)

[anfragment]

Hey folks!
I ran into the same issue, and after some research have decided to make an npm package that enables the rendering of dynamic React Email templates at runtime. You can check it out at https://github.com/anfragment/react-email-dynamic.

[gabrielmfern]

Pretty cool how you did it there. Just out of curiosity, is the template meant to be passed in as the pure JSX, or would it be the function component?

Even if this is pretty cool, I think it's overkill for the use case of everyone here, and I wouldn't recommend you use it. Just from looking at it, it could also have performance hits, compiling with SWC and all. The recommended way to do this is to have a preprocessor before running. I would recommend tsup, but that is up to you.

---

That being said, if you are interested in helping out, the way you did things in your package could help us some improve performance on the current preview server's rendering method. Here's the code for the function in question:

react-email/packages/react-email/src/actions/render-email-by-path.tsx

Lines 18 to 28 in 3e84153

	};
	export const renderEmailByPath = async (
	emailPath: string,
	): Promise<EmailRenderingResult> => {
	const result = await getEmailComponent(emailPath);
	if ('error' in result) {
	return { error: result.error };
	}

It does some very similar stuff to what you did in your package.

[anfragment]

Thank you for your reply. Yes, the tempate is meant to be pure JSX.

I definitely agree that the library is an overkill for most use cases out there. We're using it in the context of an internal notifications service at the place I currently work at. One of the requirements was the ability for anyone within the company to create, edit, and send email newsletters without the involvement of the engineering department. We chose react-email for its ergonomics, relative simplicity of JSX and the flexibility to extend it with our own components. However, we couldn't compile the templates ahead of time due to the dynamic nature of the application, therefore the need for runtime compilation. This approach unlocks a whole new way for us to use react-email, so I decided to open-source the library we made.

Regarding the preview server's performance, I'll be more than glad to help. I dug around the code a bit, but do you mind explaining what part you consider a bottleneck and what could be replaced to help with that?

[gabrielmfern]

One of the requirements was the ability for anyone within the company to create, edit, and send email newsletters without the involvement of the engineering department.

Whoa, that's amazing. The implementation is also really good tbh. Just wanted to clear it out to anyone coming across it.

Regarding the preview server's performance, I'll be more than glad to help. I dug around the code a bit, but do you mind explaining what part you consider a bottleneck and what could be replaced to help with that?

That's lovely of you, thank you so much.

I did not run any benchmarks to compare implementations, just some off-the-cuff guesses, so I might be wrong. First, what I was thinking was that maybe running swc would be more minimal than running esbuild, if done right. Secondly, that running the code using something like you did with the Function instead of using Node's vm could also be faster.

Not sure what kind of drawbacks there would be between those approaches, or if they would work completely in the use case of the preview server, but if there might be some performance gains it would be amazing

[riccardolardi]

@anfragment thanks a lot for releasing your package. I'm trying to render react-emails during runtime as I need to send them out triggered by a node-cron job. I'm using next.js but I can't seem to be able to transform the JSX into a string to pass it to your react-email-dynamic. I tried using ReactDomServer but I get an error saying React is not defined. How are you supposed to parse the JSX to a string?

[anfragment]

Hi, glad you find it useful! Do you mind sending me an email or opening an issue over at anfragment/react-email-dynamic with the code you're trying to run?

[taylor-lindores-reeves]

For some reason, when using Vercel's infra with edge config for AuthJS (next-auth) in my middleware and [...nextauth] route, the Edge function size is larger than the Pro limit of 2mb when using react-email to send the Verification Request. Maybe I am missing something, but 2mb seems very large for a single email. I am assuming it's compiling the (non-production) version of react-email which is what's causing the limit to be exceeded. Any suggestions?