Open taeo opened 7 years ago
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:
/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'
/data
by filename convention: /data/failed-transation.test.json
, only use .test.(json|yml) files as dummy data sourcesI'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 👍.
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:
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.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.Thanks!
To your points.
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.
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?
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...
Good idea.
Exactly. Figured that was the plan, just making sure.
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.
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:
dist/
files to be written as whatever type (.liquid, .hbs, .php, etc...)Thoughts, questions, issues, likes...?
FYI @ericdfields