-
-
Notifications
You must be signed in to change notification settings - Fork 67
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
Comments
@lopesrb what kind of use case are you thinking? |
I also thought about that. If you send high amounts of emails Mjml quickly became the bottleneck here. |
@sighmon I just want to reduce email sending times on my project. |
@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.
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. |
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. |
@nratter I'm keen to see what changes you make to |
(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. |
I thought of a trick if pre rendering mjml is a must for you, making a rake task or some script which:
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 |
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 |
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
The text was updated successfully, but these errors were encountered: