matochondrion/.DS_Store

Mat's Blog and Notes

Temporary home until I get something more formal in set up.

Instance Variables vs Local Variables, and How Many?

date_created: 2020-05-13
date_updated: 2020-05-13
tags: ruby, rails, controller, instance variables, local variables

TL;DR

Hiding instance variables means creating instance variables outside of a controller action. Instance variables are passed to the view regardless of where they are created. If the view uses variables that are created somewhere outside of the action in a large messy controller, they can be difficult to track down.

Since some people don't like using instance variables at all, as they can pollute not only the controller but also the view template, one can optionally use Rails' "Local Variables" instead.

Aim to only use one ivar/local-variable per Controller Action (use Facade pattern if needed)

Intro

When learning Rails I grasped that Controllers have both instance variables (ivars) and local variables that get passed to view templates. But I had struggled to understand why you would use one over the other.

What "Don't Hide Instance Variables" Means

What Use Local Variables Instead

How Many Variables Should be Passed to The View Template

Why Use Locals in Partials

Sources

The Rails Way vs The OOP Way

date_created: 2020-05-10
date_updated: 2020-05-10

TL;DR

When deciding where to put non-MVC code in a Rails project there are two competing theories - The Rails Way (promoted by Rails Framework developers like DHH and a more traditional OOP philosophy that I'll call the The OOP Way. The Rails Way promotes a smaller set of primary models with many public methods - backed by Concerns and POROS, for an easier to read user interface. The OOP Way promotes more classes, that are smaller, have fewer public methods, and are not mixed into the database backed classes. For example:

The Rails Way The person instance has methods for numerous operations on the person data, resulting in easier to read code.

person = Person.new("Jack", "Skellington")

puts person.full_name

The OOP Way The person instance strictly deals with the data for person while other classes process that data. Has the advantage of keeping classes focused on a single task and promotes more reusability.

person = Person.new("Jack", "Skellington")

puts FullName.for(person)

Introduction

While trying to refactor Rails code that falls outside of typical MVC roles, I kept coming across authoritative sounding, yet competing advice. One source would indicate code should go into a Rails Concern, while another would say Concerns are only used in one specific way, or to never use Concerns at all. They would instead promote using non-Rails, Plain Old Ruby Objects (PORO) directly (see above example).

What I didn't realize is that there's a war going on (or a "disagreement"). I wish more of these sources had clarified up front that there are basically two camps in the Rails community when it comes to where to put code that falls outside of the typical MVC framework. Missing this key information led to spinning my whiles as I searched for articles, trying to clarify my understanding of where code like mine should really go, and why.

Proponents of traditional OOP will say these large Models have too broad a service area - each Model has too many public methods. Classes should strive to do just do one thing.

Concerns Have Multiple Uses

Mixins

Eg, Filterable

Easy Code User Interface

Attaching code from a PORO to instances of a data backed Class

class User < ActiveRecord::Base
  include Personable
  include SignalUser, AccountsSharingIdentity

  include Applausee, Appearant, Announcee, Assigner, Bookmarker, Devicee,
          Drafter, Locker, Notifiee, Profiled, Reader, Reportee

  def addtributes_for_person
  end

  def enroll(enrollee_params)
  end

  def settings
  end
end

Module User::Notifiee
  extend ActiveSupport::Concern

  included do
  end

  def notifications
    @notifications ||= User::Notifications.new(self)
  end

  private

    def default_to_hiding_badge_counts
    end
end

# This way code can be written easily as:
# Current.user.notifications
#
# Instead of:
# User::Notifications.new(Current.user)

Organizing PORO Directories

Passing Values and Context to Models

User of ActiveSupport::CurrentAttributes or Not?

https://ryanbigg.com/2017/06/current-considered-harmful

Sources

The Rails Architecture Controversy
A good overview of the two competing camps.
DHH On Writing Software Well #4 A video where DHH explains his reasons for Classes with broad surface area and why he sees it as an advantage instead of a weakness.
Put Chubby Models on a Diet With Concerns
7 Ways to Decompose Fat ActiveRecord Models
About Rails Concerns
My Rails Models Are Bloated. Should I use Concerns
Ruby on Rails Guides