Rails Issues: To Concern Or Not To Concern

If you happen to’ve ever used Ruby on Rails, you’ve most likely come throughout the idea of issues. Everytime you jumpstart a brand new Rails venture, you get a listing app/controllers/issues and app/fashions/issues. However what are issues? And why do individuals from the Rails group generally speak badly about them?

Fast Overview

A Rails Concern is any module that extends ActiveSupport::Concern module. You may ask — how are issues so completely different from modules? The primary distinction is that Rails issues assist you to do a little bit of magic, like so:

module Trashable
  lengthen ActiveSupport::Concern

  included do
    scope :present, -> { the place(trashed: false) }
    scope :trashed, -> { the place(trashed: true) }
  finish

  def trash
    update_attribute :trashed, true
  finish
finish

You see that phrase included. It’s a little bit of Rails carbohydrates sprinkled upon a Ruby module. What ActiveSupport::Concern does for you is it lets you put code that you really want evaluated contained in the included block. For instance, you wish to extract the trashing logic out of your mannequin. The included lets you do what we did and later embody your mannequin’s concern like so:

class Track < ApplicationRecord
  embody Trashable

  has_many :authors

  
finish

Fairly helpful and naive at this level, proper? The Mannequin misplaced a little bit of weight and trashing can now be reused all through different fashions, not simply our Track mannequin. Nicely, issues can get difficult. Let’s dive in to seek out out.

A Traditional Instance of a Mixin

Earlier than we embark additional into the depths of issues, let’s add one other rationalization of them. While you see embody SomeModule or lengthen AnotherModule, these are known as mixins. A mixin is a set of code that may be added to different lessons. And, as everyone knows from the Ruby documentation, a module is a group of strategies and constants. So what we’re doing right here is together with modules with strategies and constants into completely different lessons in order that they’ll use them.

That’s precisely what we did with the Trashable concern. We extracted frequent logic round trashing a mannequin object right into a module. This module can later be included elsewhere. So, mixin is a design sample used not solely in Ruby and Rails. However, wherever it’s used, individuals both prefer it and suppose it’s good, or they hate it and suppose it could simply spin uncontrolled.

To raised perceive this, we’ll undergo a few execs and cons of utilizing them. Hopefully, by doing this, we are able to acquire an understanding of when or whether or not to make use of issues.

I Have It All

While you resolve to extract one thing to a priority, like Trashable concern, you now have entry to the entire performance of wherever Trashable is included. This brings nice energy, however as Richard Schneeman mentioned in his weblog publish on the subject — “with nice energy comes nice potential to make difficult code”. He meant complicating code that you just may depend on, one thing that’s supposed to be there in your issues.

If we check out the Trashable as soon as extra:

module Trashable
  lengthen ActiveSupport::Concern

  included do
    scope :present, -> { the place(trashed: false) }
    scope :trashed, -> { the place(trashed: true) }
  finish

  def trash
    update_attribute :trashed, true
  finish
finish

The logic of the priority depends on the truth that the trashed subject exists wherever the priority is included. Proper? No biggie, that is what we would like in any case. However, what I see occur is that individuals get tempted to tug in different stuff from the mannequin into the priority. To color an image of how this could occur, let’s think about that the Track mannequin has one other technique featured_authors:

class Track < ApplicationRecord
  embody Trashable

  has_many :authors

  def featured_authors
    authors.the place(featured: true)
  finish

  
finish

class Album < ApplicationRecord
  embody Trashable

  has_many :authors

  def featured_authors
    authors.the place(featured: true)
  finish

  
finish

To raised illustrate, I added an Album mannequin that additionally contains Trashable. Let’s then say we wish to notify featured authors of the track and the album after they get trashed. Individuals will get tempted to place this logic inside the priority like so:

module Trashable
  lengthen ActiveSupport::Concern

  included do
    scope :present, -> { the place(trashed: false) }
    scope :trashed, -> { the place(trashed: true) }
  finish

  def trash
    update_attribute :trashed, true

    notify(featured_authors)
  finish

  def notify(authors)
    
  finish
finish

Proper right here, issues are beginning to get difficult a bit. Since we’ve got trashing logic exterior our Track mannequin, we is likely to be tempted to place notifying within the Trashable concern. In there, one thing “fallacious” occurs. The featured_authors is taken from the Track mannequin. OK, let’s say this passes pull request evaluation and CI checks.

Then, a few months down the street, a brand new requirement is about the place the developer wants to alter the best way we current featured_authors for songs. For instance, a brand new requirement needs to indicate solely featured authors from Europe. Naturally, the developer will discover the place featured authors are outlined and edit them.

class Track < ApplicationRecord
  embody Trashable

  has_many :authors

  def featured_authors
    authors.the place(featured: true).the place(area: 'Europe')
  finish

  
finish

class Album < ApplicationRecord
  embody Trashable

  has_many :authors

  
finish

This works properly wherever we present authors, however after we deploy to manufacturing, the parents from different elements of the world received’t get notified anymore about their songs. Errors like these are straightforward to make when utilizing issues. The instance above is a straightforward and synthetic one, however the ones which can be “within the wild” may be tremendous tough.

What’s dangerous right here is that the priority (mixin) is aware of rather a lot in regards to the mannequin it will get included in. It’s what is known as a round dependency. Track and Album rely upon Trashable for trashing, Trashable will depend on each of them for featured_authors definition. The identical may be mentioned for the truth that a trashed subject must exist in each fashions with a view to have the Trashable concern working.

That is why a no-concern membership is likely to be towards, and the pro-concern membership is for. I’d say, the first model of Trashable is the one I’d go together with in my codebase. Let’s see how we are able to make the second model with notifying higher.

The place Do Y’all Come From

Trying again at our Trashable with notifying, we’ve got to do one thing about it. One other factor that occurs when utilizing issues is that we are inclined to over-DRY issues. Let’s strive to try this, for demonstration functions, to our present fashions by creating one other concern (bear with me on this one):

module Authorable
  has_many :authors

  def featured_authors
    authors.the place(featured: true)
  finish
finish

Then, our Track and Album will seem like this:

class Track < ApplicationRecord
  embody Trashable
  embody Authorable

  
finish

class Album < ApplicationRecord
  embody Trashable
  embody Authorable

  
finish

We dried all the pieces up, however now the requirement for featured authors from Europe is just not fulfilled. To make issues worse, now the Trashable concern and the fashions rely upon the Authorable. What the hell? Precisely my query after I was coping with issues a while in the past. It’s laborious to trace down the place strategies are coming from.

My answer to all of this could be to maintain featured_authors as near the fashions as doable. The notify technique ought to not be part of Trashable concern in any respect. Every mannequin ought to deal with that by itself, particularly if they have a tendency to inform completely different subgroups. Let’s see the way to do it much less painfully:

module Trashable
  lengthen ActiveSupport::Concern

  included do
    scope :present, -> { the place(trashed: false) }
    scope :trashed, -> { the place(trashed: true) }
  finish

  def trash
    update_attribute :trashed, true
  finish
finish

module Authorable
  has_many :authors

  
  
finish


class Track < ApplicationRecord
  embody Trashable
  embody Authorable

  def featured_authors
    authors.the place(featured: true).the place(area: 'Europe')
  finish

  
finish

class Album < ApplicationRecord
  embody Trashable
  embody Authorable

  def featured_authors
    authors.the place(featured: true)
  finish

  
finish

Issues like these are manageable and never too complicated. I skipped the notify performance I described earlier since that may be a subject for an additional day.

For Basecamp, the Rails creators, issues referencing different issues appear completely effective as DHH illustrated in a tweet some time in the past:

By wanting on the code screenshot, you’re both opening your mouth in awe or in appall. I really feel there is no such thing as a in-between right here. If I acquired an opportunity to edit this code, I’d envision it because the “Last Concern Boss Battle”. However jokes apart, the attention-grabbing factor right here is that there are feedback that say which concern will depend on which. Check out:

  

  embody Subscribable 
  embody Eventable    

  

Placing feedback like these may be useful, but it surely’s nonetheless arrange for doing one thing sketchy, particularly in case you are new to the codebase. Being new and never being conscious of all of the “gotchas” a code has can definitely ship you down the priority downward spiral.

One thing like that is what DHH shared in a remark contained in the dialogue. A response tweet inside asks how are people who work with this codebase speculated to work together with issues like these. DHH responds that they don’t have a lot written docs, they hardly ever rent so their workforce is nicely acquainted with these.

However having an skilled workforce that is aware of the codebase nicely as an argument for utilizing them is bizarre and never sturdy. I suppose it’s extra of a sense whether or not to make use of them or not. Are you extra snug with a number of inheritances that modules present, or do you favor composition? Your name.

Conclusion

As we’ve seen, issues are nothing greater than modules that present some helpful syntax sugar to extract and DRY up your code. You probably have extra helpful instruments underneath your belt, possibly you shouldn’t attain out for issues straight away. Habits like dealing with file attachments and the trashing logic we confirmed within the examples is likely to be good candidates to extract into modules (issues).

Hopefully, you get to see the doable good and unhealthy issues when coping with issues and modules basically. Keep in mind that no code is ideal. And in the long run, how are you going to be taught what is sweet and what’s unhealthy for you should you don’t try to probably fail or succeed?

No answer is ideal, and I hope you bought to know the Rails issues approach of doing issues within the weblog publish. As at all times, use your judgment and concentrate on the professionals and cons.

Till the subsequent one, cheers!