Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pre render mjml #52

Open
lopesrb opened this issue May 20, 2019 · 9 comments
Open

pre render mjml #52

lopesrb opened this issue May 20, 2019 · 9 comments

Comments

@lopesrb
Copy link

lopesrb commented May 20, 2019

Hey guys,
this might be a stupid question and if so feel free to close this.

I was wondering if there was a way to pre-render the mjml to html so we are not always rendering mjml to erb and erb to html. This way we would pre render mjml to erb and then when we wanted to send the email we would render the erb to html.

Some kind of caching mechanism

@sighmon
Copy link
Owner

sighmon commented May 25, 2019

@lopesrb what kind of use case are you thinking?

@tobsch
Copy link

tobsch commented Jun 5, 2019

I also thought about that. If you send high amounts of emails Mjml quickly became the bottleneck here.
Is erb rendering happening AFTER or BEFORE Mjml?
If it is happening after Mjml it might be more realistic...

@lopesrb
Copy link
Author

lopesrb commented Jun 5, 2019

@sighmon I just want to reduce email sending times on my project.
If I am not mistaken we are rendering mjml everytime we send an email and probably we just need to do it one time after every modification, right?

@sighmon
Copy link
Owner

sighmon commented Jun 7, 2019

@tobsch @lopesrb I've never had the need to do mass sending from my server, I've always used other services that handle the unsubscribes and deduplicating from multiple subscribe sources.

Is erb rendering happening AFTER or BEFORE Mjml?

It's been a while since the last refactor of the codebase, so I honestly can't remember the order. I won't get to this for a little while, but please feel free to put together a pull request if you have the time.

@nratter
Copy link

nratter commented Oct 19, 2020

Performance with mjml-rails when sending a lot of emails at once has been a problem in our application. I agree it would be better to run mjml to build .html.erb files upon deployment so Rails can use that as opposed to running mjml upon sending.

What you guys think?

Maybe I can just fork what you guys have done here to modify for my specific use case.

@sighmon
Copy link
Owner

sighmon commented Oct 21, 2020

@nratter I'm keen to see what changes you make to mjml-rails as opposed to baking it into your Rails app, so post back here to keep us updated. :-)

@doits
Copy link

doits commented Dec 1, 2020

(For reference what I wrote in #76)

I don't think precompilation is possible though since MJML must work on the complete body – it cannot compile partials for example, because output depends on stuff around it like head components. So it must know the complete content beforehand, which in fact means it must be compiled once for every e-mail sent. I'm no MJML expert though (only a user of it), so maybe I am wrong.

See mjmlio/mjml#794 for more info about it.

@nflorentin
Copy link

nflorentin commented Dec 2, 2020

I thought of a trick if pre rendering mjml is a must for you, making a rake task or some script which:

  • take the code of the mjml email template
  • replace manually the <%= yield %> of the mjml layout with the content of the mjml email template
  • write the complete rendered email into a tmp file
  • run mjml compilation on the tmp file and write the html.erb file into a new file

The last file will be seen by the app like a normal html.erb template.

The problem with that approach is you won't be able to have render erb partials in your email template, unless you don't mind them to not be compiled with mjml (so they would be necessarily mj-raw if I understood it well).

Another possibility if you really need to be able to render partials is to use <mj-include> tags.

@drush
Copy link

drush commented Dec 14, 2022

You can include ERB blocks in MJML files and they won't be modified. It is definitely possible to pre-compile all of your emails into ERB.html files as part of the asset pipeline. This removes MJML from runtime and just leaves ERB and string interpolation as your critical path.

With this approach you could either choose to continuing using email content partials (with yield), or just remove layouts from your emails altogether and make each one a standalone single file (likely a small performance gain at high volume).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants