DEV Community: Charlie Gardai

Ruby : to callee or not callee

Charlie Gardai — Tue, 26 Sep 2023 15:07:44 +0000

Ever met those instructions :

__FILE__
__method__
__callee__

I think we all met at least the first one while playing with Ruby within our early experimentations ... and maybe used the second one for debugging processes - if so I propose you to try a debugger like pry, byebug, pry-byebug you'll get lots of the information right away (if you are using Ruby >3.1 you even get an integrated one).
But do you know what does the last one ?

The difference with method

First of all, let's identify what __method__ is doing :

def world
  p "hello #{__method__}"
end

world

Executing this file will produce:

$ > hello world

But why ?

Simply put : __method__ is returning as a symbol the name of the method the instruction is in.
Here the method is world, so it puts the interpolation of the string and the method symbol which gives : hello world.

So what is the difference with __callee__ ?
Well __callee__ is returning the actual name of the called method dynamically as a symbol.

Let's example ourselves

class Foo
  def root_method
    p "you did #{__method__}"
  end

  def root_callee
    p "you did #{__calle__}"
  end
end

Foo.new.tap do |this|
  this.root_method
  this.root_callee
end

File execution :

$ > you did root_method
  > you did root_callee

Here nothing big differentiate both behaviours : both return their method name.

Let's then put the __callee__ specificities to the test :

class Foo
  alias_method :aliased_method, :root_method
  alias_method :aliased_callee, :root_callee
end

Foo.new.tap do |this|
  this.aliased_method
  this.aliased_callee
end

File execution :

$ > you did root_method
  > you did aliased_callee

So what happened ?

The aliased method that uses __method__ interpolates the root method name.
The aliased method that uses __callee__ interpolates with the aliased method name.

__callee__ instead of __method__ is looking up for the actual method name, not the one it originated from !

Ok ... but how can I use this ?

That's a good question !

Let's imagine a situation where we send automatic mailing to update an asynchronous task for our users .

We will always send the same data structure, and the only thing that will change is the corpus of the mail.
We could go the naive way and produce a Mailer with every specific methods we need for every possible situations. But that's tedious and imply a lot of repetition - which we don't want !

So how can we use __callee__ here to simplify our day to day life ?

A one Mailer to rule them all

So we need a Mailer that will always send emails with 3 parameters : email, user_name, a job_id, to notify an asynchronous event to the users.
The only things that will change depending on the event is :

the subject of the mail
the corpus of the mail

So first we need something that will be able to structure the needed data as we need it :

class AsynchronUpdateMailer < ActionMailer::Base
  private

  def default_mail_action(email:, user_name:, jid:)
    @email = email
    @name = user_name
    @jid = jid

    mail(
      to: ["#{@name} <#{@email}>"],
      subject: "#{__callee__.to_s.gsub('_', ' ')}: #{jid}",
      &:html
    )
  end
end

We now have an AsynchronUpdateMailer that is able to receive parameters to structure a default email and uses __callee__ and the job id to structure the subject. That's Good !
But we can't do anything with it yet.
We turn the method private because this should never get called : no need to send a default mail, what we need is a simple first structure to be able to quickly extend its behaviour with the less possible code

So let's extend it a bit to turn it a little bit more usefull :

class AsynchronUpdateMailer < ActionMailer::Base
  VALID_ACTIONS = %i[
    foo_success
    foo_failure
    bar_success
  ]

  VALID_ACTIONS.each do |valid_alias|
    alias_method valid_alias, :default_mail_action
  end

  private
  [...]
end

What did we do here ?

We defined a constant that identify which actions this mailer is able to produce.
when this Mailer is loaded by Rails, it will programmatically define an alias for every "valid action" that aliases default_mail_action, and each of those aliases will be public

Ok ... that's good and all. But what about the corpus ? What is the interest of this proposition if everyone of the sent emails does the same ?
Well, the answer is simple : we're going to use the amazing powers of Rails views system to resolve our situation !

Rails views to the rescue

Every time a ActionMailer::Base uses the mail method it will rely on the called method name and the application file structure to obtain the view that matches :

the Mailer name to find the folder within the app/views folder
the given action name to find the corresponding .haml file

So let's add our files where they need to be !
Within the app/views folder we create a folder that is te machine name of our Mailer : app/views/asynchronous_update_mailer. We then create a .haml for every action we need - corresponding to the aliases we defined :

foo_success.haml
foo_failure.haml
bar_success.haml

Each one of them is a common haml file and icing on the cake : we event get access to the state of the Mailer within this haml file.
So we can do things like :

%html
  %body
    %section
      %p
        = "Hello #{@user_name}!"
      %p
        = "You can use the number given within the subject of this mail to contact the support if need be !"
      ...

So ? Can you feel the maintenability and scalability of this setup tickling your brain ?
Obviously you can always go one step further, but here we potentially saved a lot of time and maintenance using the power of Rails !

Conclusion

__callee__ is one of those tool Ruby proposes that we don't always need ... but can still be of great use in the right context.
It always comes down to what we have and what we do with it. I'm sure you already made great use of it and can share with us in the comment some of your experiences with its usage !

That's it for today !

Thank you for reading this article, and I hope it got you something interesting out of it. At least I had a blast typing it.

I'm sure you already made great use of the __callee__ method, so don't hesitate to give your insights and personal examples in the comments : they will be greatly appreciated.

Enjoy your skills and have a great day !

Rails "around_action" : a less used callback

Charlie Gardai — Fri, 22 Sep 2023 12:31:21 +0000

The other day I was re-exploring Rails documentation to give me a good refresh on what I already knew and what I forgot or what I slept on. There are so much little things that can get out of your vision when you are under production constraints, that having a little step back from time to time can offer you marvels to the mind and skill.

Lost in re-reading from the basics to the details, I fall back onto one of the core aspect of Rails : its callbacks. It's when I realized that there's a lot of them that I don't meet really often within the code bases I get the grasp on.
One especially feels the shy one : around_action, one of the AbstractController::Callbacks.

Some terminology before we start

Interpretation is an amazing spell the brain has ... but it comes with its defects. Let's ensure we speak the same language :

An action is a controller method that gets called through a route of the application. create, show, edit, update, index, destroy are the common RESTful conventions.
What I will call a behavior is anything that produces any kind of reading or interact with the application. It will most commonly be methods of any form.

Refreshing the basics

You certainly know about before, after actions - certainly the most commonly used callback types. Let's just have a small refresher to get us :

class NutmegsController < ApplicationController
  before_action :set_nutmeg, except: %i[create index]
  before_action :grate, except: %i[create index destroy]
  after_action :dispatch_gatherer, only: :create
end

before_action produces behaviors right before the action, in the order you pass them to the controller.
So when it can both set_nutmeg and grate it will first set_nutmeg then grate it.

after_action produces behaviors right after the action if it is successful.
It's an adequate time to send the gatherer used to get the nutmeg to the central as an example.

Those are rather explicit about the moment they are executing the behaviors.

So what does around_action ?

Yeah ... that's a good question.

If "before" and "after" are crystal clear about the process timeline, "around" can get a bit too exposed to appreciation.

In short : around_action is expecting to receive behaviors that will do something during the action. It will yield the action process for the behavior. (a little yield refresher if need be)
The previous sentence is essential to understand what we can actually do with around_action.

Let's continue with our nutmegs exploitation :

class NutmegsController < ApplicationController
  before_action :set_nutmeg, except: %i[create index]
  before_action :grate, except: %i[create index destroy]

  around_action :dry_air, except: %i[create destroy]

  after_action :dispatch_gatherer, only: :create

  private

  def dry_air
    raise UndryableRoomException unless get_air.dry

    yield
  end
end

Here we want to make sure that the air is dry while we show or most of the time we interact with the nutmegs. It will first try to dry the air on any non filtered actions - no need for it while we gather or destroy them - if it can't it will stop the action and alert the controller, elseway it will resume the action as expected.

Rails gives a good example

The Rails documentation is always a good start for anything and has a lot of very good examples about its usage. And it doesn't fall short on this one :

class ChangesController < ApplicationController
  around_action :wrap_in_transaction, only: :show

  private
    def wrap_in_transaction
      ActiveRecord::Base.transaction do
        begin
          yield
        ensure
          raise ActiveRecord::Rollback
        end
      end
    end
end

Here what it does is something that could be a great usage of this callback : wrapping the action within a transaction to ensure any interaction with the database that will occur during its process. If all succeeds : it will resume the action as expected, if anything fails : we make sure that any change is rollback.

This can become real handy if we need to ensure multiple interactions within this one action.
Take this case with a grain of salt though : it can underlie a potential code smell (cf : Single responsibility principle in SOLID). But sometimes it's the adequate solution.

Going modular

To give you more insight about the mater and a more adequate way to scale your code :
A potential way to reuse the bit of code Rails provide us and clear up the code in the same code : use a Concern :

# app/controllers/concerns/transactionable.rb

module Transactionable
  extend ActiveSupport::Concern

  private

  def wrap_in_transaction
    ActiveRecord::Base.transaction do
      begin
        yield
      ensure
        raise ActiveRecord::Rollback
      end
    end
  end
end

It will give us the possibility to include the behavior within any controller we need - and potentially extend Transactionable later :

# app/controllers/some_controller.rb

class SomeController < ApplicationController
  include Transactionable

  around_action :wrap_in_transaction, only: %i[create update]
end

Conclusion

around_action may be a less used callback, but as for lots of things within Rails : it can sometimes resolve some of your niche problems with precision.

And don't forget to dive back within the Rails documentation without intent from time to time when you feel so ... it's a great pleasure to re-enact your knowledge on some specific use cases.

That's it for today !

Hope this little refresher gave you some food for thought. At least it was a pleasure typing it.

Don't hesitate to give your insights and personal examples in the comments : they will be appreciated.

Enjoy your skills and have great day !

DEV Community: Charlie Gardai

Ruby : to __callee__ or not __callee__

The difference with method

Let's example ourselves

Ok ... but how can I use this ?

A one Mailer to rule them all

Rails views to the rescue

Conclusion

That's it for today !

Rails "around_action" : a less used callback

Some terminology before we start

Refreshing the basics

So what does around_action ?

Rails gives a good example

Going modular

Conclusion

That's it for today !

Ruby : to callee or not callee