Rails: the quest to dumb views and skinny controllers

(como cualquier chapiadora)

Viktor Justo Vasquez

You can stalk me out on 

 twitter/github/instagram 

@vjustov

blog.vjustov.me

It's a mee.

Acknowledgments

Decorators

The solution

Decorator Pattern

• The decorator pattern is a design pattern that allows behavior to be added to an individual object, without affecting the behavior of other objects from the same class.[4] 
• Decorator is a design pattern that is used to extend the functionality of specific object by wrapping it, without effecting other instances of that object.[5]

class NiñitaPerfecta
  def ingredients
    ['Azucar', 'Flores', 'Muchos Colores']
  end
end

class ChicasSuperpoderosas < SimpleDelegator
  def ingredients
    super << 'Sustancia X'
  end
end

class Burger
  def price
    100
  end
end

class BaconCheeseBurger
  def initialize(burger)
    @burger = burger
  end

  def price
    @burger.price + 30
  end
end

class DobleCarneBurger
  def initialize(burger)
    @burger = burger
  end

  def price
    @burger.price + 50
  end
end

DobleCarneBurger.new(
  BaconCheeseBurger.new(
    Burger.new
  )
).price 
=> 180

How does a decorator solve our problem?

Come the Presenter

• So, Presenters are just decorators. 
• The main goal of presenters is to keep logic out of the view.
• Its secondary goal is to keep related functionality, which would have previously existed in helpers, in close proximity to the relevant objects. Presenters maintain an object-oriented approach to logic in the view.
• If you have conditionals in your views, you'll likely benefit greatly from moving that logic to a presenter. [6] 

They TURN your controllers from this:

• The Presenter pattern creates a class representation of the state of the view.
• A Presenter can encapsulate aggregating data from various objects and leave the controller with more focused responsibilities.
• This also allows for testing of aggregation or calculation behavior without a dependency on setting up a Controller to a testable state.

class CarsController < ApplicationController
  def show
    car = Car.find(params[:id])
    dealer = Dealer.find(params[:dealer_id])

    @car = ViewCarPresenter.new(car, dealer)
  end
end

class ViewCarPresenter
  def initialize(car, dealer)
    @car, @dealer = car, dealer
  end

  def availability
    count = dealer.cars_in_stock.select { |c| c == car }.count
    "There are #{count} of this car."
  end

  def price_description
    if price > 500_000
      "Expensive piece of metal this one is!!"
    else
      "Damn it's was cheap!!"
    end
  end
end

#car-view
  .availability
    = @car.availability
  .comments
    = @car.price_description

describe ViewCarPresenter do 
  let(:car) { double(car, price: 2000) }
  let(:dealer) { double('dealer', cars_in_stock: [car]) }

  let(:presenter) { ViewCarPresenter.new(car ,dealer) }

  it 'calculates the availability' do
    expect(presenter.availability).to eql('There are 1 of this car.')
  end
    
  it "renders the price description" do
    expect(presenter.price_description).to eql("Damn it's was cheap!!")
  end
end

Enter the Exhibits

• Wraps a single model instance.

• Encapsulates decisions about how to render an object. The tell-tale of an Exhibit is telling an object "render yourself", rather than explicitly rendering a template and passing the object in as an argument.

• Brings together a model and a context. Exhibits need a reference to a "context" object—either a controller or a view context—in order to be able to render templates as well as construct URLs for the object or related resources.

class ReadingListExhibit < DisplayCase::Exhibit

  def self.applicable_to?(object)
    object_is_any_of?(object, 'ReadingList')
  end

  def to_json(options={})
    output = "["
    books[0..-2].each do |book|
      output << " { \"book\": #{book.to_json}"
      output << " },\n"
    end
    output << " book: { #{books[-1].to_json} } "
    output << "]"
  end

  def to_csv(options={})
    output = ""
    books.each do |book|
      output << "\"#{book.title}\", \"#{book.author}\", \"#{book.publisher}\" \n"
    end
    output
  end

  def render_navigation(template)
    template.render(
      :partial => "shared/reading_list_navigation", 
      :locals => { 
        :selected_reading_list => self.name, 
        :other_reading_lists => ReadingList.without_current(__getobj__) 
        }
    )
  end

  def render_books(template)
    template.render(:partial => "shared/book", :collection => self.books)
  end

  def render_overview(template)
    template.render(:partial => 'shared/reading_list', :object => __getobj__) 
  end
end

class BookExhibit < DisplayCase::Exhibit
  def self.applicable_to?(object)
    Rails.logger.debug("app/exhibiit #{object}")
    object_is_any_of?(object, 'Book')
  end

  def render_book(template)
    Rails.logger.info(template.class)
    template.render(
      partial: 'shared/book', 
      locals: { :book => __getobj__})
  end
end

<div class="row-fluid">
  <div class="span8">
    <% @books.each do |book| %>
      <%= book.render_book(self) %>
    <% end %>
   </div>
   <div class="span2 well">
      Suggested Reading Lists:
      <% @reading_lists.each do |e| %>
        <%= e.render_overview(self) %>
      <% end %>
   </div>
</div>

class ReadingListsController < ...
  respond_to :html

  def index
    @books = exhibit(Book.all)
    @reading_lists = exhibit(ReadingList.all)
    respond_with(@reading_lists, @books)
  end
end

View-model spectrum

Let's merge 'em together: Presenter + Exhibits

Presenters and exhibits are not mutually exclusive.

 We can combine presenters and exhibits to take advantage of both. We use presenters to deal with any view-related logic. We use exhibits to manage rendering the objects.

class ShowAllReadingListsPresenter
  attr_reader :books, :reading_list

  def initialize(books, reading_list)
    @books = BooksExhibit.new(books)
    @reading_list = ReadingListExhibit.new(reading_list) 
  end

end

<div class="row-fluid">
  <div class="span8">
    <% @presenter.books.each do |book| %>
      <%= book.render_book(self) %>
    <% end %>
   </div>
   <div class="span2 well">
      Suggested Reading Lists:
      <% @presenter.reading_lists.each do |e| %>
        <%= e.render_overview(self) %>
      <% end %>
   </div>
</div>

class ReadingListsController 
  respond_to :html

  def index
    @presenter = ViewAllReadingList.new(
        Books.all, 
        ReadingList.all, 
        self
    )
  end
end

So, what about what i read on the internet this morning?

"Classic" presenters are oriented towards a particular view; they are, in Jay Fields' words, "class versions of your views". They have names like ReportPresenter or OrderCompletionPresenter.

In contrast, this second generation of presenters are oriented primarily towards specific models. They have names like UserPresenter or PicturePostPresenter. They enable a particular model instance to render itself to a page.

• Regarding decorators, I personally prefer to refer to them as such only when we are using them in a general way, with no particular interest on views or anything.