Support for mailers about sorbet-rails HOT 6 CLOSED

I put together an PR for mailer rbi generation 😅 💦
#151

from sorbet-rails.

@jaredbeck, yeah, it's kind of silly that Rails ActionMailer is doing this. It is not clear how we can generate a good header for mailer though.

For example, in your case:

class UserMailer < ApplicationMailer
  def new_user_password(user)   <= sorbet-rails has no way to know the type of the argument
    # ...
  end
end

At best, we can generate the existence of the method, but we don't have information about the type of the parameters. It isn't ideal, and might get into the way of people writing actual sig for the method.

I've been advised people to write a sig for the method manually in an rbi file

# -- user_mailer.rbi
# typed: strong
class UserMailer
  sig {
    params(user: User).
    returns(ActionMailer::MessageDelivery)
  }
  def self.new_user_password(user:)
  end
end

Let me know what you think, or if you have any suggestion!

from sorbet-rails.

^ I think I can document this in tip & trick section, unless we have a good solution to generate sigs correctly.

If you think it's useful to generate the sig without typed param, it's doable though
eg:

class UserMailer
  sig {
    params(user: T.untyped).
    returns(ActionMailer::MessageDelivery)
  }
  def self.new_user_password(user:)
  end
end

from sorbet-rails.

Hi Harry, thanks for the quick response.

For example, in your case:

def new_user_password(user)  # sorbet-rails has no way to know the type of the argument

Sorry, I neglected to include the sig in my example. If we amend my example to include a signature:

sig { params(user: ::User) }
def new_user_password(user)

Does that help? Would we be able to generate an RBI with the class-method equivalent?

When the mailer action truly lacks a signature

At best, we can generate the existence of the method, but we don't have information about the type of the parameters.

If we don't generate untyped class methods, then other files that invoke said method will be limited to the typed: false sigil, right?

It [generating untyped class methods] isn't ideal, and might get into the way of people writing actual sig for the method.

Later, when write an actual sig for the instance method, we can then regenerate our RBI with rake rails_rbi:all, thus fixing the conflict, correct?

Our Options

Is this a reasonable summary of our options?

• Do nothing - sorbet-rails will never support mailer class-methods. People will be required to write mailer RBIs by hand.
• Generate class methods in RBI, but only if param types are known - Seems like a reasonable limitation, if documented
• Always generate class methods, even if param types are not known - Extra effort, but helpful, assuming the eventual conflict can be fixed as described above
• Retire from coding and take up farming

from sorbet-rails.

I’ve always thought potato farming looked nice

from sorbet-rails.

from sorbet-rails.