Offer the option to use parameterization for shared processing of headers and ivars

[dhh]

Consider this example that does not use parameterization:

class InvitationsMailer < ApplicationMailer
  def account_invitation(inviter, invitee)
    @account = inviter.account
    @inviter = inviter
    @invitee = invitee

    subject = "#{@inviter.name} invited you to their Basecamp (#{@account.name})"

    mail \
      subject:   subject,
      to:        invitee.email_address,
      from:      common_address(inviter),
      reply_to:  inviter.email_address_with_name
  end

  def project_invitation(project, inviter, invitee)
    @account = inviter.account
    @project = project
    @inviter = inviter
    @invitee = invitee
    @summarizer = ProjectInvitationSummarizer.new(@project.bucket)

    subject = "#{@inviter.name.familiar} added you to a project in Basecamp (#{@account.name})"

    mail \
      subject:   subject,
      to:        invitee.email_address,
      from:      common_address(inviter),
      reply_to:  inviter.email_address_with_name
  end

  def bulk_project_invitation(projects, inviter, invitee)
    @account  = inviter.account
    @projects = projects.sort_by(&:name)
    @inviter  = inviter
    @invitee  = invitee

    subject = "#{@inviter.name.familiar} added you to some new stuff in Basecamp (#{@account.name})"

    mail \
      subject:   subject,
      to:        invitee.email_address,
      from:      common_address(inviter),
      reply_to:  inviter.email_address_with_name
  end
end

InvitationsMailer.account_invitation('david@basecamp.com', 'jason@basecamp.com').deliver_later

Using parameterized mailers, this can be rewritten as:

class InvitationsMailer < ApplicationMailer
  before_action { @inviter, @invitee = params[:inviter], params[:invitee] }
  before_action { @account = params[:inviter].account }

  default to:       -> { @invitee.email_address }, 
          from:     -> { common_address(@inviter) },
          reply_to: -> { @inviter.email_address_with_name }

  def account_invitation
    mail subject: "#{@inviter.name} invited you to their Basecamp (#{@account.name})"
  end

  def project_invitation
    @project    = params[:project]
    @summarizer = ProjectInvitationSummarizer.new(@project.bucket)

    mail subject: "#{@inviter.name.familiar} added you to a project in Basecamp (#{@account.name})"
  end

  def bulk_project_invitation
    @projects = params[:projects].sort_by(&:name)

    mail subject: "#{@inviter.name.familiar} added you to some new stuff in Basecamp (#{@account.name})"
  end
end

InvitationsMailer.params(inviter: 'david@basecamp.com', invitee: 'jason@basecamp.com').account_invitation.deliver_later

That's a big improvement! It's also fully backwards compatible. So you can start to gradually transition
mailers that stand to benefit the most from parameterization one by one and leave the others behind.

[alexcameron89]

"in other" -> "in order"

[kaspth]

I'd also expand instance variable.

[kaspth]

Digging it, especially now that we can extract things into default 👍

I'm curious why the method is calledparams? Is it to bridge the terminology gap between controllers and mailers? I'm asking because I'd have thought this would be called assigns, which eludes to the view aspects of mailers.

Especially since most of the mailer actions I've written just blankly assign their parameters to an instance variable so I'm curious if we should take this a step further with:

class InvitationsMailer < ApplicationMailer
  assigns :inviter, :invitee
  assigns(:account) { @inviter.account } # Personally, meh. But throwing it out there :)
end

This would then just do @inviter = assigns[:inviter].

In case a specific action haven't passed, say, :invitee, the action would just have a blank @invitee ivar and nothing would blow up.

This way I think we could also avoid the params method while keeping backwardscompatibility:

InvitationsMailer.account_invitation(inviter: 'david@basecamp.com', invitee: 'jason@basecamp.com').deliver_later

---

Regarding Proc.new in default. It feels outside of the Rails aesthetic to me and I'm curious if we should do something to support:

default to: -> { @invitee.email_address }

Or if we're cool enough with proc :)

[kaspth]

Implementation seems fine 👍

[kaspth]

Reading your example again, we'd probably need to update:

InvitationsMailer.account_invitation(inviter: 'david@basecamp.com', invitee: 'jason@basecamp.com').deliver_later

Since those strings won't respond to account, name etc. 😁

[maclover7]

IMHO, I don't see this as a big improvement over the current usage. Introducing a ActionMailer::Base#params method which you then call the mailer method on seems kind of messy to me. I'm a big fan of explicitly passing arguments to the mailer method, over more magical params handling 😬

[dhh]

There's nothing magical about setting a context which allows controller-wide preprocessing. That's exactly how action controllers work, and this brings mailers in line with that usage. The A/B here is imo undeniable, and it's a reduced example from what I've actually seen in Basecamp code. There the advantage is even larger. As a general observation, I find any objections based on the idea of "magic" entirely without persuasion. Especially in this case where the flow basically is "instantiate object, assign variables, call method". It doesn't get more basic OO than that.

…

On Jan 27, 2017, at 21:38, Jon Moss ***@***.***> wrote: @maclover7 commented on this pull request. IMHO, I don't see this as a big improvement over the current usage. Introducing a ActionMailer::Base#params method which you then call the mailer method on seems kind of messy to me. I'm a big fan of explicitly passing arguments to the mailer method, over more magical params handling 😬 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dhh]

Params was just to match the concept from controllers in the sense that they're going to be used the same way. Especially as it relates to serialization during jobs as well. #assigns is not a bad way to go either though, but I don't think it has the same overall naming benefits. Here we can now talk of a new concept: parameterized mailers. The method follows that name. And it makes the before_action and other filters feel immediately familiar to anyone who've done the same work with action controllers. Agree on the Procs. I didn't change anything there, that's just the implementation AM already had. It only took Procs, not lambdas. If you want to have a look at that, please do! I looked at the assigns thing at the top level too. Kinda like expose. But I couldn't find enough value in my code to justify the new concept.

…

On Jan 27, 2017, at 19:06, Kasper Timm Hansen ***@***.***> wrote: Digging it, especially now that we can extract things into default 👍 I'm curious why the method is calledparams? Is it to bridge the terminology gap between controllers and mailers? I'm asking because I'd have thought this would be called assigns, which eludes to the view aspects of mailers. Especially since most of the mailer actions I've written just blankly assign their parameters to an instance variable so I'm curious if we should take this a step further with: class InvitationsMailer < ApplicationMailer assigns :inviter, :invitee assigns(:account) { @inviter.account } # Personally, meh. But throwing it out there :) end This would then just do @Inviter = assigns[:inviter]. In case a specific action haven't passed, say, :invitee, the action would just have a blank @invitee ivar and nothing would blow up. Regarding Proc.new in default. It feels outside of the Rails aesthetic to me and I'm curious if we should do something to support: default to: -> { @invitee.email_address } Or if we're cool enough with proc :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[kaspth]

Neat! I always thought you had to check the arity to get lambda support.

[kaspth]

Uses person_b twice ;)

[kaspth]

Here we can now talk of a new concept: parameterized mailers. The method follows that name. And it makes the before_action and other filters feel immediately familiar to anyone who've done the same work with action controllers.

Ha! It took me until now to fully grasp what you meant by this. params allows for better use of before_action in Mailers and perfectly mirrors Action Controller's API of the same 😄

[rafaelfranca]

This is great! I did some improvements in the implementation here 341fab8...2dadf73

[kaspth]

@rafaelfranca and now it's even better 😃🎉

[dhh]

Lovely, thanks @rafaelfranca!

[williamromero]

Excuse me if i don't understand, but it means now we can send mails with a particular name for each mail for our mailing lists? Right? Sorry if don't understand it well.