Earlier today @bradgessler published Supermail for ActionMailer and I started to think that I would like to have this API for emails in #Hanami too.
So now I kind of do, although there is probably a lot of edge cases to discover.
Post
Earlier today @bradgessler published Supermail for ActionMailer and I started to think that I would like to have this API for emails in #Hanami too.
So now I kind of do, although there is probably a lot of edge cases to discover.
The trade-off is that the API does not play well with Hanami Deps system. But I think this is what I'm willing to sacrifice.
@katafrakt we could also wrap it in a more Hanami-friendly adapter class in prolly less then a dozen lines of code :)
“Emails” are still on the do-do list for Hanami! How do you think we should do them? (If at all)
@timriley I didn't have any crystallized thoughts about what email should look like. This is part of the reason I wanted to experiment with different approaches to see how they feel. This is the result I kind of liked.
1. I agree with Brad that methods (`def from = 'mail'`) feel better than DSL (`from 'mail'). This makes it crystal clear how inheritance works and how I can extract reusable parts as modules to include.
@timriley
2. I guess making it Hanami-way would mean an API similar to the current mailer, i.e. `RegMail.new.deliver(user:)`. What I don't like about this is that if I have `RegMail.new.deliver_in(3600, user:)`, it mixes args for email building with args for delivery. So separate passing email building params to initializer makes more sense (`RegMail.new(user:).deliver_in(3600)`).
Does Sebs' work using the Hanami 1.x mailer with Hanami 2 offer any help?
https://hanamimastery.com/episodes/47-send-emails-with-hanami-mailer
A space for Bonfire maintainers and contributors to communicate