3 ms·
I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like Rea
by avree 3y ago
I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like React than "Handlebars" (which Sendgrid requires https://docs.sendgrid.com/ui/sending-email/how-to-send-an-email-with-dynamic-templates https://docs.sendgrid.com/ui/sending-email/how-to-send-an-em...)
- mbesto 3y agoI've used pretty much all of them and in most cases you're sending the request via some message queue (front-end -> async to back-end -> message queue -> async returns to back-end DB), which is managed on the backend. I'm scratching my head as to why relying on the browsers threading to do seems like it offers any advantages...
- al_be_back 3y agoI think he may have wondered how would, say a Python backend using Resend Python SDK, render a React Email template and send it. Their API docs [1] for "Send Email" has an option for specifying a 'react' component to render the message but it's only available on the NodeJS SDK. Otherwise you pass HTML and/or Text. Personally, I was expecting the api to optionally accept a React Template, along with the Data, where upon the Resend api would Render it (or fail) then Send it. Passing a 'preview' param would return the rendered HTML/Text (for testing) - just a thought. [1] https://resend.com/docs/api-reference/emails/send-email https://resend.com/docs/api-reference/emails/send-email
- mbesto 3y agoExactly this. Said differently - how many devs out there are screaming "I really need to send transactional email via React", when most apps are sending it via Python, Ruby, PHP, Java, and (back-end) JS.
- nlh 3y agoPreface: I'm with you on this. But I think the targeting here is for a certain generation of companies where there is a very distinct backend/frontend split OR companies where everyone is a JavaScript dev (and the backend is Node). The backend folks send the email content and the frontend folks are responsible for building the presentation-layer stuff. The thinking here, I believe, is that those frontend guys do all their other work in React, so when they're given these transactional emails to build, they'd prefer to keep working in React. I think?
- ovao 3y agoI think you’re conflating terms (or possibly concepts) here. This isn’t about sending emails via React; this is about sending HTML emails generated from React components via a backend. The examples shown on the landing page are of Node.js, Next.js route handlers and Remix loader functions, the latter two being fancy abstractions over Lambda functions (or isolates). I agree that sending an email from React doesn’t make a lot of sense, but that’s not the target at which this is aiming.
- satvikpendem 3y agoEr, you can send the emails via whatever backend service you want. React merely acts as a templating language and when compiled down to HTML, you can then send the resultant file with Python, NodeJS, etc.
- winphone1974 3y agoBut the code populating and sending the email is rarely (ever?) Front end code
- fastball 3y agoSure, but presumably you want your emails to generally match the aesthetic of the rest of your product, which is easier if you can use the same tooling to make them as you do the frontend of your product.
- verdverm 3y agoReact doesn't do its own styling though, and since email will not run js, you are basically talking about css at this point
- f-securus 3y agoMaybe that is the secret sauce of this service. They render the email with react and automagically convert that to something that works for email?
- nlh 3y agoI think they literally just use React as a templating language, basically. You write React components and this service renders them down to email-friend HTML. Like SSR but for email.