sofn-xyz / mailing Goto Github PK

At the same time as scaffolding the emails directory, it would be nice if it added a __tests__/emails directory with a default set of tests. wdyt?

At the moment mailing only integrates well in a ts project. I removed the JS support in #30 because it wasn't working. Requiring jsx templates was blowing up on es6 imports.

Plan:

• bring back js generators and init prompt from #30
• figure out how to make es6 import working

I think this could happen after creating the email directory and before booting the preview server.

"Enter your email to subscribe to updates about mailing:"

It could then POST to an api route on packages/web for storage somewhere...

The preview server seems to just hang when the server is running in a different terminal. This may be what's happening in #60.

Instead we should say that the port is already taken and exit with code 1.

Small thing, but we should have the best email templates. Right now they show as white all the time 🤷. Pretty sure inverting all the colors would be good (and perhaps just not setting a color for background).

not sure if webfonts are possible, but fallback should be a sans-serif font.

When running mailing for the first time, the interactive tool asks the following question:

? Where should we put your emails? › ./emails/

This doesn't make it clear that the only allowed values here are ./emails and ./src/emails. This should either be documented or refactored to truly allow custom values. Answering this question with ./src/mailing will not work with the preview and there's currently no way to fix this.

Explanation

• Add video to README

Manual test

• test next.js app
• test Redwood js app
• test remix app

@monicakogler found an issue with live reloading components. Templates live reload fine, but components do not do so reliably without restarting the preview server.

I think this is because the component gets uncached by the watcher and the preview file gets uncached by the previews controller, but the template does not get removed from the cache so it contains the cached component still.

One solution could be uncaching all of the files in the emails directory when loading up the preview.

Currently the preview server just renders mjml components to strings. It would be nice to have hotkeys, modals, etc so we want react with the server-rendered mjml in an iframe.

Would it be possible to use next.js for the preview server? The task is to investigate how to support normal client-side react in the preview server.

https://github.com/psugihara/mailing/blob/main/packages/cli/src/commands/preview.ts

Hi,

Is there a way to get the created and tested HTML email templates via api so that we can send the email from other applications.

Thanks in advance
Alan

An automated test that did this would be very cool:

• create a new next app
• run mailing to add emails directory in default location
• ensure dev server boots
• send an email from an api route
• do the same in a typescript nextjs app

command could also be mailing export (might be better since this is not required for production)

Hello again!

I've been using react-markdown and running into issues with ESM-only-module support. For the time being I've switched to marked to get around these issues with CommonJS, but was wondering if the preview server is capable (or will be capable) of handling ESM libs?

Cheers

It would be nice if the project could support absolute import paths. For example, the generated files (https://github.com/sofn-xyz/mailing/blob/main/packages/cli/src/generator_templates/ts/emails/TextEmail.tsx#L2) would show import Head from "components/Head" instead of import Head from "./components/Head". Based on what I can tell, this behaviour is controlled on these lines https://github.com/sofn-xyz/mailing/blob/main/packages/cli/src/commands/preview.ts#L43-L65. Ideally I could supply/override the config with my own tsconfig.json file.

It would be nice to be able to generate a new template + preview file.

Could be something like this:

mailing generate MyEmailTemplate (w rails style alias mailing g)

creates files

• emails/MyEmailTemplate.jsx
• emails/previews/MyEmailTemplate.jsx

npx mailing export-previews [dirPath]

should export previews as html to a directory at dirPath

dirPath defaults to ./mailing_export

motivated by convo in #75 (comment)

Especially in js apps (because of babel?) the initial index load of previews.json is very slow (like 4 seconds for the default templates.

ideas to speed this up:

1. warm-up on boot: kick off the module loading asynchronously in the preview.ts handler function
2. speedier module loading: try using swc or a different loader rather than babel
3. rust rewrite (jk)

cc @alexfarrill

Is there an issue with starting the service which I am experiencing right now.

Anything I am missing?

Thanks in advance

@alexfarrill you mentioned this the other day. I think it's a good idea, wanted to capture.

I have a project with a .env file in the root and I use import "dotenv/config"; to load the .env to process.env. I didn't realize it at first but this is not working with email/index.ts as the env values I'd expect to be defined (present in my .env) are not set on process.env.

Spotted a small regression with the change to make error messages display. It's doing a hard reload rather than refetching the html. This makes it feel a bit slower because it has to do 2 fetches and more rendering. Instead, let's re-trigger the fetch and just reload the iframe content.

🤗

While digging into #89 it was confusing to not be able to log anything from email/index.ts.

Sometimes there are mjml compilation errors returned from the render function as well as valid HTML. Currently we display the preview if there's any html but abort sending the email if there are any errors. So you may think you have a good email and it'll only fail when you try to send. Instead, it would be better to display the errors on the preview page so that you know to fix them.

adds prev/next hotkeys for quickly cycling through templates. useful when, for example, doing QA on a design system update, variations on a preview function, etc.

Hey there! I've been exploring mailing for the past two days and everything was going great until decided to test some production scenarios. Put simply, everything works as long as preview server is running: templates are compiled, and emails are successfully sent via sendgrid.

However, as soon as I stop the preview server to test actual functionality, I start running into issues, primarily emails are not sent at all. I get the following error in my terminal

The code I use in my next.js API route is

import { sendMail } from '~/emails';

...

      const t = await sendMail({
        subject: `Ready for 123?`,
        to: entry.email,
        component: React.createElement(RSVPEmail, {
          entry,
        }),
      });
      console.log(t);

emails/index.ts is

import nodemailer from 'nodemailer';
import { buildSendMail } from 'mailing-core';
import dotenv from 'dotenv';

dotenv.config({ path: '.env.local' });

const transport = nodemailer.createTransport({
  host: 'smtp.sendgrid.net',
  port: 587,
  auth: {
    user: 'apikey',
    pass: process.env.SENDGRID_API_KEY,
  },
});

export const sendMail = buildSendMail({
  transport,
  defaultFrom: '[email protected]',
});

The README is missing on npm because it's in the root of the monorepo and not included with the package. We could either copy it in with the copy:files script or maybe a symlink would work.

https://www.npmjs.com/package/mailing

yarn e2e runs these locally. They are run before release and ensure compatibility in different operating environments (next, redwood, remix, standalone).

Context

A few users have asked for a method of running mailing as a standalone process with an HTTP API. They'd like to use it from backends that don't have access to react or can't consume nodejs packages. The new API would have one endpoint that renders a template to HTML with input props.

Thanks to @sebasalvarado, @alan-francis, and @jdotjdot for describing the use-cases in #54.

Design

Currently the mailing preview server is intended only for development. That is, it's built without any consideration for handling many requests and running for a long time unattended. Are there memory leaks? How many TPS can it serve? Are there spots we can switch to async IO? Let's find out.

This design adds a "production mode" for the mailing server as well as the required API (which could also be useful for development mode features like editing props from the browser).

CLI change

With NODE_ENV=production set, mailing should start the server in production mode, running efficiently and indefinitely.

HTTP API change

GET /renders/TemplateName.json?props=JSON_PROPS

return values

200

{
  html?: string,
  errors?: object[] // prop type or template compilation errors
}

404

template not found

Tasks:

• cli change outlined above
• add API route above
• jest tests for API route
• manually test deploying this to fly.io
• add instructions to README for setting up and deploying a standalone mailing server

This can be a global switch, we only need a dark mode now.

I think it's mostly just changing backgrounds and font colors.

black #11111
white #E4EBFA

Hey! Loving this project, this is exactly what I was after for a long time (wix-incubator/mjml-react#37). I am playing around with the boilerplate and I discovered a few issues I will report in this project. The first one is whether it's possible to run this project without importing React? I copy-pasted my tsconfig from another project that supports this, but running mailing preview after removing all React imports throws this error

error TS2686: 'React' refers to a UMD global, but the current file is a module. Consider adding an import instead.

Similarly to other tools such as CRA, it would be nice if mailing generated a complete project boilerplate including package.json and README describing which scripts are available and what they do. The project currently makes some assumptions about how the user runs and serves the templates (e.g. no build command for raw HTML), this should be documented too.

There are 2 natural mailing packages.

mailing/core -- this is the mailing stuff that we must include to render emails in prod
mailing/cli -- this is the preview server and generators, includes typescript deps and stuff that will only be used when developing emails

Not sure the best way of splitting (but we should keep them in this repo). Maybe npm or yarn workspaces.

• split them up
• update install instructions in the readme

This page...

It took me a while to figure out how to make the embedded next.js app work. This post was helpful, but didn't talk about how to boot the app in the library.

Could be a helpful thing to write a post on and also explain the architecture of the preview server for people working on mailing or trying to build similar tools.

• Add to the README: React and React-dom
• Is there a nicer way to support it?

We should seed your emails directory with nice conventions.

In a real project we'd use a file with shared color and style variables, so it might be useful if we did that with our demo templates as well.

I think one of these structures could work:

• emails/theme.ts with all the theme variables
  or
• emails/theme/colors.ts, emails/theme/spacing.ts, etc (idk if there are more)

This way small global switches are easy and mega re-designs are possible.

h/t @elliothursh for the suggestion!