---
title: How to organize your code using Rails Concerns
published: "2023-11-02"
publisher: Honeybadger
author: Kingsley Silas
category: Ruby articles
tags:
  - Ruby
  - Rails
description: Rails Concerns are helpful but can be confusing for new and experienced developers alike. This article explains what Rails Concerns are and how to use them to improve your workflow.
url: "https://www.honeybadger.io/blog/rails-concern/"
---

There is a strong chance you’ve encountered Rails Concerns if you’ve been using Rails for a while. It can be confusing to understand where it fits into your Rails application and how best to make use of it. This is what we’ll be covering in this tutorial: what Rails Concerns are, why they exist, and their use cases.

## What are Rails Concerns?

In simple terms, a concern is a module. First, let’s review what a module is. A module is a collection of methods, constants, and class variables. Typically, modules can be used for two things:

1. To share functionality across multiple places, such as classes;
2. As [namespaces](https://www.oreilly.com/content/ruby-cookbook-modules-and-namespaces/#:~:text=When%20a%20module%20is%20used,up%20the%20main%20Kernel%20namespace).

For our use case, we’ll focus on sharing functionality across multiple places. You do this by including the module in the places where you need such functionalities.

You can think of a module as a bucket of related behaviors (methods) or data (attributes). These behaviors and attributes can then be used across different classes (or modules).

Here is what a concern looks like:

```ruby
require "active_support/concern" module M extend ActiveSupport::Concern included do scope :disabled, -> { where(disabled: true) } end class_methods do ... end end
```

If we’re writing an equivalent without using Rails concern, `ActiveSupport::Concern`, it will look like this:

```ruby
module M def self.included(base) base.extend ClassMethods base.class_eval do scope :disabled, -> { where(disabled: true) } end end module ClassMethods ... end end
```

In the code above, you can see that Rails Concern gives us a cleaner interface to work with. You can also see that we have what looks like a block: `included` and `class_methods`.

`class_methods` in the concern defines class methods that will be available on the including class. These methods can be accessed on the class itself, rather than on instances of the class. `included` is a callback method that allows you to include code as if it were written directly in the including class. It gives you the ability to modify the class itself when the concern is included. It's as if the code inside the included block has been pasted into the class where the concern is included.

## Why do they exist?

When we say a concern is a module, it means that, like a module, a concern makes it possible to share functionality across different classes in a Rails application. Here is a snippet from Rails Guides:

> Concerns are a way to make large controllers or models easier to understand and manage. This also has the advantage of reusability when multiple models (or controllers) share the same concerns. Concerns are implemented using modules that contain methods representing a well-defined slice of the functionality that a model or controller is responsible for. In other languages, modules are often known as mixins. If you have a piece of code that is used in different places in your code base, it will be helpful to abstract it into a concern. Let’s say I have different scopes that I use in different models:

```ruby
scope :created, -> { where(status: 'created') } scope :updated, -> { where(status: 'updated') } scope :deleted, -> { where(status: 'deleted') } scope :from_date, ->(date) { where(T.unsafe(arel_table)[:created_at].gteq(date)) } scope :to_date, ->(date) { where(arel_table[:created_at].lteq(date)) }
```

I can move that into a concern, which I can then use across the models involved.

## When should you use them?

As mentioned above, you can use Rails Concerns when handling code reusability. It’s also common to make use of it for things like validation and error handling. For example, you can have an error handler like this:

```ruby
module ErrorHandlerConcern extend ActiveSupport::Concern included do rescue_from(Unauthorized) do |exception| render json: { errors: "Unauthorized" }, status: 401 end rescue_from(UnprocessableEntity) do |exception| render json: { errors: "Unprocessable Entity" }, status: 422 end rescue_from(BadRequest) do |exception| render json: { errors: "There's something wrong with your request" }, status: 400 end rescue_from(Forbidden) do |_exception| render json: { errors: "You are not allowed" }, status: 403 end rescue_from(ActiveRecord::RecordNotFound) do |_exception| render json: { errors: "Record not found" }, status: 404 end end end
```

The code snippet above creates an error handler that rescues from certain errors. The rescue blocks are in the `included` block. This can then be included in the `ApplicationController` since this is something I’ll want to make use of across my application.

The same applies to validations or authorization.

## How should you use them?

By default, the Rails application comes with a directory for `concerns`. You’ll see this in the `controllers` and `models` directories. Thus, you’ll want to place concerns that are related to models in `app/models/concerns` and that of controllers in `app/controllers/concerns`.

In one of my projects, I have a concern called **VersionConcern** that looks like this:

```ruby
module VersionConcern extend ActiveSupport::Concern included do scope :active, -> { where(deleted_at: nil) } scope :deleted, -> { where.not(deleted_at: nil) } end class_methods do def delete_all_records update_all(deleted_at: Time.current) end def restore_all_records update_all(deleted_at: nil) end end end
```

This concern makes it possible for me to scope records based on whether they are active or deleted. To make use of this in a book model, I only need to include the concern in the model like this:

```ruby
class Book < ApplicationRecord include VersionConcern belongs_to :author, class_name: 'User', foreign_key: 'user_id' ... end
```

If I want to fetch the active books for a user, I can do this:

```ruby
Books.find_by(author_id: current_user.id).active
```

We can also make use of the class methods like so; `Book.delete_all_records`.

## Pitfalls

While Rails concerns help with reducing duplication, it is not the only “tool” out there. You can also create a service that holds this common code. It is important to know that [Concerns are inheritance](https://www.codewithjason.com/used-intelligently-rails-concerns-great/#:~:text=Some%20I%20don%E2%80%99t.-,Concerns%20are%20inheritance,-%2C%20and%20composition%20is). Therefore, for example, if you check the [lookup path](https://www.honeybadger.io/blog/ruby-method-lookup/#:~:text=this%20article.-,Method%20Lookup%20Path,-The%20first%20place) of `.active` methods, you’ll see that `VersionConcern` is included. If you are concerned about that, you might want to consider something else, like making use of a service.

Concerns are, however, a helpful tool to have in your Rails toolkit.

## Conclusion

While you might not necessarily use Concerns every time, it’s important to know what they do. In this tutorial, we’ve learned about the similarity between concerns and modules, why we have them, and how we can use them.

---

## Try Honeybadger for FREE

Intelligent logging, error tracking, and Just Enough APM™ in one dev-friendly platform. Find and fix problems before users notice.

[Start free trial](https://app.honeybadger.io/users/sign_up)

[See plans and pricing](https://www.honeybadger.io/plans/)