grunt-email-workflow

grunt-email-workflow copied to clipboard

Not all use cases for this workflow benefit from pure .html compiled templates. Many times we are loading our templates into various third party systems with a variety of compilers and subsequent dynamic data. The objective is to have pristine templates compiled, but allow live-ish previewing and testing.

Approach:

• Allow dist/ files to be written as whatever type (.liquid, .hbs, .php, etc...)
• Incorporate better helpers / utilities to pass hbs or other curly brace syntax through assemble, uncompiled
• Allow the preview tool to render supported template types
• Enable the preview tool load and render templates with optional dummy data for testing

Thoughts, questions, issues, likes...?

FYI @ericdfields

Definitely sums up what we talked about here.

This allows us to treat g-w-e as a "dev" environment for emails, while our (non-mailgun) third party system of choice acts as "staging" where we eventually fire off "production" emails.

Thoughts:

• a folder along the lines of /data that would render into a select menu next to your email select menu in preview. choose the data source for the template you're working with'
• maybe indicate "test" data in /data by filename convention: /data/failed-transation.test.json, only use .test.(json|yml) files as dummy data sources
• pass-through flag would presumably follow and assemble partials, but leave non-partial tags alone, uncompiled.
• option to render compiled stylesheet within tags instead of juiced

I'm still not sure where in the grunt process handlebars content gets substituted for real data if it exists. I could crudely intercept and escape a lot of my tags to achieve pass-through mode.

Love this suggestion. Admittedly I usually hack the flow a bit to provide outputs for whatever 3rd party tool/code I'm using e.g. a service that needs {{ content }} and {{ unsubscribe }} or a rails app that needs .erb templates.

@taeo All your ideas make sense. Allow the preview tool to render supported template types. Maybe you have a good idea here but I imagine that getting quite complex if server.js is trying to support more than html.

@ericdfields - data formats / naming conventions are key for sure. I do like the consideration of not inlining styles, presuming that the final engine will do that.

@leemunroe - Express Server comes with a number of template engines supported out of the box, and many, many others from 3rd parties. I don't see that being too complicated to add supported engines and then conditionally process the preview based on the template extension / engine. Hypothetically of course.

Pushing this to the next level - should we make a bit of a spec, go YOLO style and just start a fork to play with, other?

@taeo Your call. Some times I find it easier to just create a fork and start hacking. But if you want to get something a bit more formal in here to nail down ideas and scope, also sounds good.

Some quick research and feasibility tests are looking 👍.

• [x] Create templates with any combination of extensions
• [x] Helper to pass mustache syntax through the compiler
• [x] Express preview handling multiple rending engines based on extension

Hey @ericdfields, @leemunroe and anyone else interested in testing this out.

I just got a branch pushed up on my fork for multiple template engines.

It supports .ejs, .liquid, .hbs templates using consolidate (room for many more template engines). The caveat is you have to name your src/emails/ as filename.<desired-extension>.hbs

It adds a raw helper:

{{{{raw}}}}
  whatever your heart desires... or non-rendered hbs code
{{{{/raw}}}}

Sample data can be created in /preview/data/ either .json or .yml by simply adding one of those flavors with the base template name > _sample.html.hbs would lookup /preview/data/_sample.json or /preview/data/_sample.yaml

There's room for improvement, but it's a fully functional proof of concept! Look forward to your feedback.

caveat php is in there, but it's broken. There's some awkwardness passing variables into the previewer.

Wow impressive work!

Some things that come to mind after playing with this:

• It's great that it can support these types. One concern I have though is it might add some confusion to noobs. Cloning this repo and running grunt for the first time usually involves a bit of a learning curve (at least for most email developers I've tested it with). If the ejs/hbs/liquid/php files are in there too (in both dist and src) it adds to that learning curve. Don't have a preferred solution but wondering if this is something that is turned off by default, or maybe they're in another examples folder, something to help them not being an additional distraction.
• Another thought that comes to mind after playing with this is how do I have just one src file that integrates with the other features/commands e.g. I would love to have one email source file that I develop and preview locally, send to Mailgun, send to Litmus, and then send off to my 3rd party service.
• Noticed the PHP issue. It's been a while since I wrote PHP so not sure how to fix off hand. Sidenote: What apps/ESPs are you guys using to send email that use PHP?

Thanks!

To your points.

1. I vote we should fire up the gh wiki on this project to help elaborate on variations and options. That will help keep the README smaller, and we can include code samples as opposed to including them in the core repo.

2. Maybe I'm not understanding correctly. Are you saying there's no way to send the dist/_sample.liquid for example via mailgun or to litmus fully rendered with the sample data? If I'm tracking... you're correct that doesn't work, but it could. dist/_sample.liquid is what you'd send off to your 3rd party service, right?

3. PHP - not sure how to fix that either at the moment, nor do I care to spend more time trying to figure it out. I don't personally use many apps, or know of any ESP's that are php-driven. Someone else in the community with a hankering for that could patch and PR...

1. Good idea.

2. Exactly. Figured that was the plan, just making sure.

3. That's what I was thinking. Figured there might be some sort of Wordpress use case but maybe ignore it until someone really wants it.

@taeo Been a while since we had some activity here. You got pretty far. Checking in to see if we have something to merge?

@leemunroe - Thanks for the follow up here. Catching up from vacation, but I can get a PR going in the not-too-distant future for this. Cheers.

Whew, time flew by. Will get back on this PR / feature shortly.