Объясните, что такое 'concern' в Rails.ruby-47

Concerns in Rails are a powerful tool for extracting and organizing reusable pieces of code across your application. Let me explain this concept thoroughly.

What is a Concern?

A Concern is a module that extends ActiveSupport::Concern and provides two main benefits:

  1. Code reuse - Share common functionality across models/controllers
  2. Organization - Keep your code modular and maintainable

Basic Structure of a Concern

Here's the anatomy of a typical Concern:

module Visible
  extend ActiveSupport::Concern

  included do
    # Code to run when included (callbacks, validations, etc.)
    scope :visible, -> { where(visible: true) }
  end

  class_methods do
    # Class methods go here
    def default_visibility
      true
    end
  end

  # Instance methods go here
  def toggle_visibility
    update(visible: !visible)
  end
end

Where Concerns Live

Rails has two standard directories for concerns:

  1. app/models/concerns/ - For model-related mixins
  2. app/controllers/concerns/ - For controller-related mixins

Why Use Concerns?

1. Avoiding Code Duplication

Instead of repeating the same code in multiple models:

# Before
class Article < ApplicationRecord
  scope :visible, -> { where(visible: true) }
  def toggle_visibility
    update(visible: !visible)
  end
end

class Comment < ApplicationRecord
  scope :visible, -> { where(visible: true) }
  def toggle_visibility
    update(visible: !visible)
  end
end

# After with Concern
class Article < ApplicationRecord
  include Visible
end

class Comment < ApplicationRecord
  include Visible
end

2. Better Organization

Break large classes into logical components:

class User < ApplicationRecord
  include Authenticatable
  include Profileable
  include Notifiable
end

Advanced Concern Patterns

1. Configuration Options

module Taggable
  extend ActiveSupport::Concern

  class_methods do
    def taggable_on(*fields)
      fields.each do |field|
        has_many :"#{field}_tags"
      end
    end
  end
end

# Usage:
class Article < ApplicationRecord
  include Taggable
  taggable_on :category, :author
end

2. Dependent Concerns

module Commentable
  extend ActiveSupport::Concern

  included do
    has_many :comments
    include Visible # Includes another concern
  end
end

When NOT to Use Concerns

  1. Simple applications - If the functionality won't be reused
  2. Tightly coupled code - When the concern needs too much context
  3. Business logic - Concerns should handle cross-cutting concerns, not core business rules

Testing Concerns

Test concerns in isolation using anonymous classes:

RSpec.describe Visible do
  let(:model_class) do
    Class.new(ApplicationRecord) do
      self.table_name = 'articles'
      include Visible
    end
  end

  it 'adds visible scope' do
    expect(model_class).to respond_to(:visible)
  end
end

Real-World Examples

1. Paginatable Concern

module Paginatable
  extend ActiveSupport::Concern

  class_methods do
    def paginate(page: 1, per_page: 10)
      page = [page.to_i, 1].max
      offset((page - 1) * per_page).limit(per_page)
    end
  end
end

2. Slugable Concern

module Slugable
  extend ActiveSupport::Concern

  included do
    before_validation :generate_slug
    validates :slug, presence: true, uniqueness: true
  end

  def to_param
    slug
  end

  private

  def generate_slug
    self.slug ||= title.parameterize if respond_to?(:title)
  end
end

Резюмируем: Concerns in Rails provide a structured way to extract and share common functionality across your application. They help maintain DRY principles while keeping your code organized and modular. Use them for cross-cutting concerns that don't fit naturally into service objects or other patterns, but be mindful not to overuse them for core business logic.

Вопросы

Собеседования