We all know the tropes of performative magic. Be it a person in Victorian garb pulling a rabbit out of their unusually tall hat or your uncle you only see once every three years picking out the card you selected in secret at the kitchen table, magic is a way to bypass basic human deduction in a way that seems otherworldly. But we all know it’s a trick of the mind — a carefully crafted illusion designed to distract a viewer for enough time to complete another task, which would otherwise seem impossible. For the third project at the Flatiron School for Software Engineering, we were given the great undertaking of building our own Rails web application. As a person who, apparently, wants to do everything by hand, Rails has some of its own “magic” and sleight of hand built in to make every developer’s life a little easier with its use of Active Record. One of these “magic tricks” and requirements for this project was to build a class level Active Record scope method to be placed inside one of the models of our app. With just one line of code, a programmer can write a succinct, powerful Active Record query that will always return an ActiveRecord::Relation object. It feels just like magic.
For my project I built a web app that would simulate a music venue, where a user could log in and “purchase” tickets for concerts. After implementing the Ruby gem Faker and seeding my database, iterating through my Concert instances to display them on their index page made sense. However, there was one issue: they were all out of order based on their date attribute. No music venue website displays concerts out of order. I could have written extensive logic in my index.html.erb file, but I wanted to adhere to the separation of concerns. Within my Concert model I would need to write one of these class level scope methods that I could then chain onto my iteration back in my Concert index page.
Here I begin with the named scope method “scope.” This method takes two arguments, name and lambda(which is symbolized by “->”). You could call this method whatever you wish, but to name it something clean and readable makes the most sense. After the lambda symbol you have your block of code. Here I use the Active Record method “order” which will order whichever attribute I wish as the argument in parentheses. I wanted my Concerts to be ordered in ascending order from soonest, to latest, so we have “:asc” following the “date:” attribute. I truly could not believe this was almost all I had to do. Back on my index page I could chain this method to my iteration through each instance of Concert.
This method taps directly into the database and always returns ActiveRecord::Relation objects. I could have also chained other Active Record methods onto this method using other Active Record methods such as where or limit. For instance, I could have ordered these concerts by date and limited the return to only concerts with a certain band as the headliner using the where method. On top of all of this, since the method is declared in the Concert model, it adheres to the separation of concerns by not leaving scattered logic in a view or a controller. For a simple line of code, these methods are not only versatile, but also extremely powerful.
Now magic may be an illusory fever dream for the naive or uninformed, and, quite frankly, these scope methods may not really even be all that mystical, but they absolutely will benefit any programmer wishing to dodge database headaches or meandering logic somewhere else in the application. With the use of these class level Active Record scope methods, any programmer can quickly and efficiently query their database in a seamless, almost too-straightforward manner.
So when you’re staring down the blinding white heat of the stage’s spotlight about to saw your Rails application in half, just remember to ask the audience if they’re watching closely.
Resources