Forem: Manuel Ortega

Using Ruby Procs to improve readability

Manuel Ortega — Sat, 24 Apr 2021 12:12:52 +0000

We always try to avoid adding comments to our code. There may be some exceptions but ideally the code itself should clearly express what it is doing.

In this pursuit of code readability and expressiveness Procs are helpful in many scenarios. For example when we are dealing with a complex logic within a block we want to pass to a method (map, select, etc) from the Enumerable module.

Before

def self.error_messages(errors)      
  errors.map { |e| e.message.split(":")[3].strip rescue "" }.uniq.join(", ")
end

Let's focus on the block { |e| e.message.split(":")[3].strip rescue "" } we are passing to the map method. It is not extremely complex but still getting your head around it could take a while especially if it is the first time to face this code or functionally within an application.

After

def self.error_messages(errors)
  extract_readable_message = proc { |e| e.message.split(":")[3].strip rescue "" }
  errors.map(&extract_readable_message).uniq.join(", ")
end

This second version adding a Proc didn't change what the code does, but now anyone coming to these lines of code will easily understand not only what the code does but also why it does it.

What you think? Do you find this is worth it? Have you ever add a Proc as a way to improve readability?

The "What" and "Why" or How We are hiding those ugly IF's in our Service Objects

Manuel Ortega — Tue, 20 Apr 2021 10:32:24 +0000

We use Service Objects to encapsulate and organize business domain logic in our Rails applications. But how do we organize the "What" and "Why" within a single Service Object?

The "What" and "Why"? What do I mean? I hope the following code bites makes clear my point here.

Before

class Customers::CreateService < ApplicationService
  def initialize(customer_params)
    @customer_params = customer_params
  end

  def perform
    @customer = Customer.new(@assignment_params)
    if @customer.save
      sync_customer if TestApp.config[:sync_enabled]     
      create_qualified_notification if @customer.status_qualified?
      create_twilio_proxy_session if TestApp.config[:proxy_enabled]
      Result.new(@customer, true)
    else
      Result.new(@customer, false)
    end
  end

  private

  def sync_customer
    ...
  end

  def create_qualified_notification
    ...
  end

  def create_twilio_proxy_session
    ...
  end
end

As you can see in this before version of our Service Object we are mixing the "What" and "Why" within the perform public method. We are putting what the perform method does when a customer is created, for example, it creates a qualified notification, but we are also putting the "Why" here, it is, we are creating the qualified notification because the customer is being created with qualified status.

The "What" is what the Service Object does and the "Why" is the control-flow logic.

After

class Customers::CreateService < ApplicationService
  def initialize(customer_params)
    @customer_params = customer_params
  end

  def perform
    @customer = Customer.new(@assignment_params)
    if @customer.save
      sync_customer     
      create_qualified_notification
      create_twilio_proxy_session
      Result.new(@customer, true)
    else
      Result.new(@customer, false)
    end
  end

  private

  def sync_customer
    if TestApp.config[:sync_enabled]
      ...
    end
  end

  def create_qualified_notification
    if @customer.status_qualified?
      ...
    end
  end

  def create_twilio_proxy_session
    if TestApp.config[:proxy_enabled]
      ...
    end
  end
end

As you can see in the after version we are moving the control-flow logic, the "Why", to the private methods and keeping only the "What" in the perform public method:

 sync_customer     
 create_qualified_notification
 create_twilio_proxy_session

The argument for this is that anyone from our team or future me can read the perform method and reason about what it is trying to accomplish faster because it's just the "What".

Much of the credit goes to JP for recommending this "What" and "Why" separation in a code review

How to name Rails Concerns?

Manuel Ortega — Thu, 15 Apr 2021 18:28:57 +0000

Rails concerns are a handy technique to organize code / logic within your classes. But how do we name these Rails Concerns?

We usually follow these two conventions:

able suffix

We suffix Concerns with able when the object we are including the concern to is able to act or behave as the concern describes.

module Avatarable
  extend ActiveSupport::Concern
  ...

  included do
    ...
  end
  ...

end

The Concern above tells us that the class we include this concern to is able to act / behave as we would expect from an avatar.

We also follow this convention when we can execute the action that the concern describes to the object we are including the concern to.

module Subscribable
  extend ActiveSupport::Concern
  ...
end

In this case we are making clear we are able to subscribe to objects from the class we include this Subscribable Concern to.

has prefix

We prefix our Concerns with has when the logic we are trying to group within our Concern is not describing a behavior but a has relation between the class where we will include the Concern to and a second entity. In the following scenario we may have a User entity that has mentions within a blogging platform. At some point we may come up with a Concern that groups all the logic tied to a user having mentions.

module HasMentions
  extend ActiveSupport::Concern

  included do
    ...
  end
end

In case none of the conventions described above makes sense within a specific scenario we don't follow them and goes with whatever better describes what the concern groups together.

How do you name your Rails Concerns? What conventions do you follow?