Solving Edge Cases in Rails with Active Record Callbacks

While working on my current project with a React front end along with a Rails API back end I realized that, upon creation and update of User instances, I needed certain other things to happen. First, I needed a User to be created with a List instance, in my case, that holds movies. I didn’t realize this until well into the process. Second, I needed to make sure that every field of my update form for a User was not left blank, so that my fetch request to the back end would not cause my application to break with blank User form data. Instinct told me that this had to be done on the back end, or, that it’s simply easier to accomplish in the back end.

I already knew about built-in Active Record Validations. As a brief recap, Active Record (AR) is simply a Ruby gem, or collection of code that someone else has written, that gets installed via your Gemfile. Active Record truly does include some “magic” with what it can accomplish, especially when it comes to it’s association macros and the pre-existing methods they provide to the programmer.

While I am using AR’s belongs_to and has_many macros in my models and serializers (yet another extremely useful Gem, Active Model Serializers — do some digging!) the AR magic I am concerned with is it’s built in validation methods. According to the Rails Guides, “Validations are used to ensure that only valid data is saved into your database.” Let’s say, for instance, you want to ensure that a User’s password is not only a certain amount of characters in length, but only includes certain characters as well. AR validation helpers are built-in to make that process incredibly easy. Chapter 2 in the AR guides will provide all of the validation helpers available in Rails.

Username and Email validations in a Rails back end.

The interesting aspect of using AR callbacks comes in understanding the lifecycle of an object. Callbacks, used in the model just like belongs_to, or has_many, “are methods that get called at certain moments of an object’s lifecycle. With callbacks it’s possible to write code that will run whenever an Active Record object is created, saved, updated, deleted, validated, or loaded from the database.”

So, in my case, after looking at the list of available callbacks (conveniently listed in the same order in which they are called in the lifecycle of an object), I found that I needed the use of two callbacks — after_create and before_update.

In order to use callbacks, they must be registered and implemented as ordinary methods. Then, macro-style class methods are used to register them as callbacks. Convention says to declare callbacks as protected or private, as seen below.

Callbacks being called and used in my project.

These AR callbacks are triggered by the very actions that call them — among them are create, destroy, save, update, and valid?. Callbacks are incredibly useful in triggering actions in the life cycle of an object, or instance. AR gives you the logic built-in, so take advantage of it!