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.
Top comments (0)