rails concerns controllers dry

Rails concerns for shared controller behavior

Maya Patel Jan 2026

2 tabs

module Paginatable
  extend ActiveSupport::Concern

  included do
    before_action :set_pagination_params, only: [:index]
  end

  private

  def set_pagination_params
    @page = params[:page]&.to_i || 1
    @per_page = params[:per_page]&.to_i || 20
    @per_page = 100 if @per_page > 100 # Max limit
  end

  def paginate(collection)
    collection.page(@page).per(@per_page)
  end

  def pagination_meta(collection)
    {
      current_page: collection.current_page,
      next_page: collection.next_page,
      prev_page: collection.prev_page,
      total_pages: collection.total_pages,
      total_count: collection.total_count,
      per_page: collection.limit_value
    }
  end

  def paginated_response(collection, serializer: nil)
    {
      data: serializer ? collection.map { |item| serializer.new(item).as_json } : collection,
      meta: pagination_meta(collection)
    }
  end
end

module Api
  module V1
    class PostsController < ApplicationController
      include Paginatable

      def index
        posts = paginate(Post.published.includes(:author))
        render json: paginated_response(posts, serializer: PostSerializer)
      end
    end
  end
end

2 files · ruby Explain with highlit

Concerns extract shared logic from controllers into reusable modules, keeping controllers DRY. I create concerns for cross-cutting features like authentication, pagination, or error handling. The extend ActiveSupport::Concern pattern provides included blocks for defining dependencies and class methods. Concerns can define both instance and class methods, plus before_action filters. I organize concerns by feature, not by model—authentication concerns go in one file, pagination in another. This modular approach makes testing easier since concerns can be tested independently. Rails autoloads concerns from app/controllers/concerns, making them available to all controllers.