How to add Concern in Ruby on Rails?

Overview:

In this article, we will discuss the usage of ActiveSupport::Concern. We will delve into what it is, why we need it, and the problems it can solve. Additionally, we will explore the pros and cons associated with its usage. To illustrate its practical implementation, we will provide three examples.

Definition:

In simple terms, Concern allows you to extract common logic from different models into a reusable module. You may ask, "Why can't we just use a module? Why do we need to define something else?" Here are the main differences: Essentially, Concern is an ordinary module, but it allows you to include any ActiveRecord behaviors that you can define on the model. Therefore, we can consider it as a module for encapsulating and reusing ActiveRecord methods.

Advantages:

• Code Reusability: ActiveSupport Concern allows us to follow the DRY principle by extracting common logic into reusable modules.

Problems:

• Complex Dependencies: Overusing concerns can result in a complex web of dependencies, making the code harder to understand and maintain.
• Difficulty in Code Search: Finding the definition of a specific behavior or functionality can be more challenging due to the dispersed nature of concerns.

In essence, concerns are well-suited for storing technical components, such as:

• Adding file helpers to facilitate handling files with a clear interface.
• Creating wrappers for existing attributes and values to enhance interface clarity.
• Implementing technical features like change history tracking, logging, and more.
• etc...

However, concerns are not well suitable for storing business logic.

Implementation

In the following section, we will discuss the key elements of concerns. To understand concerns, we only need to know what a module is and the included and class_methods methods from ActiveSupport::Concern.

Module

A module in Ruby is a container that groups together related methods, constants, and other module or class definitions. It provides a way to organize and reuse code in a modular manner. And Сoncern is just a module, so we need to know how to create it.

# app/models/concerns/concern_sample.rb # frozen_string_literal: true module ConcernSample def hello_world puts 'Hello World!' end end 

ActiveSupport::Concern methods

So, what is the main difference between a simple Ruby module and a concern? The main differences are that when you include ActiveSupport::Concern in a module, two new methods are added. These methods are:

• included

This method enables us to add Active Record logic directly to the module and reuse it at the model level. For example:

# app/models/concerns/concern_sample.rb # frozen_string_literal: true module ConcernSample extend ActiveSupport::Concern included do # Define class methods here def self.my_class_method # Class method logic end # Define instance methods here def my_instance_method # Instance method logic end # Define associations here has_many :comments belongs_to :category # Define validations here validates_presence_of :name validates_uniqueness_of :email # Define callbacks here before_save :do_something after_create :do_something_else # Define scopes here scope :active, -> { where(active: true) } scope :recent, -> { order(created_at: :desc) } end end 

• class_methods

This method allows us to add methods that can be called from the class itself:

# app/models/concerns/concern_sample.rb # frozen_string_literal: true module ConcernSample extend ActiveSupport::Concern class_methods do def my_class_method # Class method logic end end end 

Let's consider three examples to gain a better understanding of this concept.

Example 1: FullDescription.

In the first example, we will consider a very basic scenario to gain an understanding of how this actually works. For instance, let's assume we have the following model:

# app/models/animal.rb class Animal < ApplicationRecord end 

Then we decided to add a method to the model that would provide the full description of this animal.

# app/models/animal.rb class Animal < ApplicationRecord def full_description "Name: #{name}. Kind: #{kind}. Status: #{status}." end end 

Here's how it works:

animal = Animal.first animal.full_description # => "Name: Simba. Kind: Cat. Status: Adopted" animal = Animal.second animal.full_description # => "Name: Rocky. Kind: Rabbit. Status: Available" 

What do we need to do if we want to move this logic to the concern? First of all, we need to create a new concern:

# app/models/concerns/full_description.rb # frozen_string_literal: true module FullDescription def full_description "Name: #{name}. Kind: #{kind}. Status: #{status}" end end 

And include this concern at the model level:

# app/models/animal.rb class Animal < ApplicationRecord include FullDescription end 

So the same interface is still available:

animal = Animal.first animal.full_description # => "Name: Simba. Kind: Cat. Status: Adopted" 

We didn't include ActiveSupport::Concern here just to highlight that for simple methods without ActiveRecord logic, it will still work fine. However, it will also work with ActiveSupport::Concern:

# app/models/concerns/full_description.rb # frozen_string_literal: true module FullDescription extend ActiveSupport::Concern included do def full_description "Name: #{name}. Kind: #{kind}. Status: #{status}." end end end 

Like this:

animal = Animal.first animal.full_description # => "Name: Simba. Kind: Cat. Status: Adopted." 

And if you want to add class methods, we can do the following:

# app/models/concerns/full_description.rb # frozen_string_literal: true module FullDescription extend ActiveSupport::Concern class_methods do def full_description all.map { _1.full_description }.join(' ') end end end 

Now the full_description method is available on the Animal class:

Animal.full_description # => "Name: Simba. Kind: Cat. Status: Adopted. Name: Rocky. Kind: Rabbit. Status: Available." 

Example 2: UUID

In the second example, we will create a concern that generates and saves a unique UUID value before creating a new database record. To achieve this, we will define a new concern as follows:

# app/models/concerns/uuid.rb # frozen_string_literal: true module UUID extend ActiveSupport::Concern included do before_create :set_uuid private def set_uuid self.uuid ||= SecureRandom.uuid end end end 

And we will include it at the model level:

# app/models/animal.rb class Animal < ApplicationRecord include UUID end 

Then, every time we create a new Animal record in the database, the UUID will be automatically generated for us:

animal = Animal.create animal.uuid # => '7f934646-bc67-446c-920d-ca5415d28b94' 

P.S. To use the UUID acronym, you need to add the following code to config/initializers/inflections.rb:

# config/initializers/inflections.rb ActiveSupport::Inflector.inflections do |inflect| inflect.acronym 'UUID' end 

Example 3: PredicateMethods

In the last example, let's consider adding a concern that allows us to simplify the interface for attributes with a fixed number of available values. For instance, if an animal record has a status attribute with the following available values: ['available', 'adopted', 'pending'], then we would like to have the following interface:

animal = Animal.create(status: 'available') animal.available? # => true animal.adopted? # => false animal.pending? # => false  # or with prexix animal.status_available? # => true animal.status_adopted? # => flase # etc .. 

What do we need to do to implement it? Let's create a new concern called PredicateMethods and add its method to the model:

# app/models/animal.rb class Animal < ApplicationRecord include PredicateMethods define_predicate_methods attribute: :status, available_values: ['available', 'adopted', 'pending'], prefix: false end 

So how is this concern implemented? It's quite simple. We just need to define a new method called define_predicate_methods, and this method will generate new methods on the model for every available value that you pass as an argument. Inside this method, we will check if the current status value is equal to the given value or not. Here's the implementation:

# app/models/concerns/predicate_methods.rb # frozen_string_literal: true module PredicateMethods extend ActiveSupport::Concern MethodAlreadyDefined = Class.new(ArgumentError) class_methods do def define_predicate_methods(attribute:, available_values:, prefix: false) available_values.each do |value| method_name = [(prefix ? "#{attribute}_" : ''), value, '?'].join.to_sym raise MethodAlreadyDefined, "#{method_name} already defined" if instance_methods.include?(method_name) define_method(method_name) do public_send(attribute) == value end end end end end 

Now our interface works as desired:

animal = Animal.last animal.available? # => true animal.adopted? # => false 

If you'd like to add the status prefix, you just need to change the value of the prefix attribute from false to true:

animal = Animal.last animal.status_available? # => true animal.status_adopted? # => false 

That's it! Now we can add this concern to any of our models and make their interfaces more readable and simplified.

Conclusion

In conclusion, in this article we delved into the usage of ActiveSupport::Concern in Rails. We explored what it was, why we needed it, and the problems it could solve. We examined the pros and cons of utilizing this approach, considering different perspectives. Furthermore, to enhance our understanding of the concept, we provided three examples that illustrated its practical implementation.