View Objects in Ruby on Rails

Introduction

If you like writing object-oriented code, you will probably like the view object pattern. The basic concept is that a PORO (Plain Old Ruby Object) is used to generate HTML for the view. With all the power of object-oriented programming, view objects can make your life a lot easier when it comes to handling complex logic in the view.

Example: Tabs

Consider the example of creating page tabs like below:

Home Page Tabs:

Settings Page Tabs:

Analyzing these two groups of tabs, we see commonalities and differences.

Traits common to all tabs:

• Each tab group has one active tab
• Each tab links to another page
• Each tab group has the same styling

Traits unique to each tab group:

• The number of tabs may change
• Link paths change for every tab
• The text of each tab is different
• The logic to determine active tabs changes

In order to create a new group of tabs, a developer should only have to write code about the uniquenesses of those tabs. For example, when creating the settings page tabs, we should only have to specify the links (Profile, My Account), where those links point to, and some logic to determine which link is currently active.

However, in my experience the inclination is to just replicate the totality of the tabs HTML for every implementation of tabs throughout the application, like so:

home.html.erb:

<div class="tabs home-tabs">
  <%= link_to 'Home', root_path, class: "tabs--link #{'is-active' if is_active_home_tab?(:home)}" %>
  <%= link_to 'Dashboard', dashboard_path, class: "tabs--link #{'is-active' if is_active_home_tab?(:dashboard)}" %>
  <% if can?(:manage, @company) %>
    <%= link_to 'Company Admin', company_path(@company), class: "tabs--link #{'is-active' if is_active_home_tab?(:company)}" %>
  <% end %>
</div>

settings.html.erb:

<div class="tabs settings-tabs">
  <%= link_to 'Profile', profile_path(current_user.profile), class: "tabs--link #{'is-active' if is_active_settings_tab?(:profile)}" %>
  <%= link_to 'My Account', edit_user_registration_path(current_user), class: "tabs--link #{'is-active' if is_active_settings_tab?(:user}" %>
</div>

application_helper.rb

def is_active_home_tab?(tab)
  case tab
  when :home
    return true if controller_name == 'home'
  when :dashboard
    return true if controller_name == 'dashboards'
  when :company
    return true if controller_name == 'companies'
  end
  return false
end

def is_active_settings_tab?(tab)
  case tab
  when :profile
    return true if controller_name == 'profiles'
  when :user
    return true if controller_name == 'users'
  end      
  return false
end

There are quite a few problems with this approach. First of all, the HTML structure of our tabs component is duplicated in multiple spots. For example, they must be wrapped in a div with a class tabs and each tab within the group must have the class tabs–link. The knowledge of that structure is in both home.html.erb and settings.html.erb. If we need to modify the structure of the tabs, either to change the styling or behavior, we’ll need to do it in both of these files. This is the very reason why upgrading a framework like Bootstrap is such a pain – there are dependencies to the HTML structure and CSS classes all over the place.

Secondly, the logic about which tabs a user can see based on their permissions is just written with the ERB if statement. While in this example it is not a big deal, if the logic to determine whether or not to show particular tabs was more complex, performing it in the view would get unwieldy.

Finally, the implementation of the “is-active” class is clunky at best, and isn’t really something we want implemented in the application helper since it doesn’t really pertain to every part of the site.

Implementing View Objects

Boilerplate Code

While view objects can be implemented however you choose – they are just plain old ruby classes, afterall – there is boilerplate functionality that every view object should have. Some examples include:- Route helpers- Helper methods like numbertocurrency- CanCanCan methods (if you use the gem)- The view context (for methods like controller_name)

Because of that, I’m going to start by offering some boilerplate code that you can add to your Rails project to be able to start efficiently using view objects.

Let’s start with our base ViewObject class that all view objects inherit from:

# app/view_objects/view_object.rb

class ViewObject
  attr_reader :context

  include Rails.application.routes.url_helpers
  include ActionView::Helpers
  include ActionView::Context

  # comment these two lines out if not using cancan
  include CanCan::ControllerAdditions
  delegate :current_ability, :to => :context

  def initialize(context, args = {})
    @context = context
    after_init(args)
  end

  def after_init(args = {})
    # implemented by child classes
  end
end

Now we need to autoload the classes in app/view_objects/

# application.rb

config.autoload_paths += Dir["#{config.root}/app/view_objects/**/"]

Note: make sure to restart your server after changing application.rb

Last but not least, let’s add this helper method to application_helper:

# application_helper.rb

def view_object(name, args = {})
  if name.is_a?(Symbol)
    class_name = name.to_s.titleize.split(" ").join("")
  else
    class_name = name.split("/").map {|n| n.titleize.sub(" ", "") }.join("::")
  end
  class_name.constantize.new(self, args)
end

This view_object helper method dynamically finds and instantiates the correct view object class based on the name provided. This way, we can call <%= view_object(:home_tabs, company: @company).html %> from our view to instantiate a view object class called HomeTabs and automatically pass in the view context.

Creating our first View Object

The basic idea is that we can just create a plain old ruby class that ultimately spits out some HTML. Let’s start by creating the HomeTabs view object:

app/viewobjects/hometabs.rb:

class HomeTabs < ViewObject
  attr_reader :company

  def html
    content_tag :div, tabs.join('').html_safe, class: 'tabs'
  end

  private

    def after_init(args = {})
      @company = args[:company]
    end

    def tabs
      [home_tab, dashboard_tab, company_tab].compact
    end

    def home_tab
      build_tab('Home', home_path, :home)
    end

    def dashboard_tab
      build_tab('Dashboard', dashboard_path, :dashboard)
    end

    def company_tab
      return nil unless can?(:manage, company)
      build_tab('Company Admin', company_path, :company)
    end

    def build_tab(text, path, tab_name)
      link_to text, path, class: tab_class(tab_name)
    end

    def tab_class(tab)
      active_class = active?(tab) ? 'is-active' : nil
      ['tabs--link', active_class].compact.join(' ')
    end

    def active?(tab)
      case tab
      when :home
        return true if context.controller_name == 'home'
      when :dashboard
        return true if context.controller_name == 'dashboards'
      when :company
        return true if context.controller_name == 'companies'
      end
      return false
    end
end

Now in the view (home.html.erb):

<%= view_object(:home_tabs, company: @company).html %>

While this is quite a bit of code just to implement four tabs, the real value is realized when we want to make our next group of tabs. First, let’s try to figure out which methods in the above HomeTabs class are specific to the tabs rendered on the home page versus generic to all tabs throughout the app.

Methods specific to HomeTabs view object:- hometab- dashboardtab- company_tab

Methods generic to all tabs view objects:- html- tabclass- buildtab

Interface methods (i.e. every tabs view object must implement but implementation changes):- active?- tabs

Now, let’s refactor this into two classes (1) a generic “Tabs” class, and (2) the “HomeTabs” class

app/view_objects/tabs.rb:

class Tabs < ViewObject
  def html
    content_tag :div, tabs.join('').html_safe, class: 'tabs'
  end

  private

    # Interface Methods

    def tabs
      fail 'must be implemented by subclass'
    end

    def active?(tab)
      fail 'must be implemented by subclass'
    end

    # Generic Methods

    def tab_class(tab)
      active_class = active?(tab) ? 'is-active' : nil
      ['tabs--link', active_class].compact.join(' ')
    end

    def build_tab(text, path, tab)
      link_to text, path, class: tab_class(tab)
    end
end

app/viewobjects/hometabs.rb:

class HomeTabs < Tabs
  private

    # Interface Methods

    def tabs
      [home_tab, dashboard_tab, company_tab].compact
    end

    def active?(tab)
      case tab
      when :home
        return true if context.controller_name == 'home'
      when :dashboard
        return true if context.controller_name == 'dashboards'
      when :company
        return true if context.controller_name == 'companies'
      end
      return false
    end

    # Specific Methods

    def home_tab
      build_tab('Home', home_path, :home)
    end

    def dashboard_tab
      build_tab('Dashboard', dashboard_path, :dashboard)
    end

    def company_tab
      return nil unless can?(:manage, company)
      build_tab('Company Admin', company_path, :company)
    end
end

What I hope you’ve noticed is that the code in the HomeTabs class has been cut down to the core essence of what it means to be HomeTabs instead of any other type of tabs. That is, only code specific to HomeTabs is here – not code generic to all tabs. For example, CSS classes are not set within this HomeTabs view object, since the tabs’ CSS classes are the same for all tabs.

View Objects are Scalable

Now here’s where the beauty of View Objects really kicks in. Let’s create a new set of tabs: the settings tabs.

app/viewobjects/settingstabs.rb:

class SettingsTabs < Tabs
  private

    # Interface Methods

    def tabs
      [profile_tab, user_tab].compact
    end

    def active?(tab)
      case tab
      when :profile
        return true if context.controller_name == 'profiles'
      when :user
        return true if context.controller_name == 'users'
      end      
      return false
    end

    # Specific Methods

    def profile_tab
      build_tab('Profile', profile_path(context.current_user.profile), :profile)
    end

    def user_tab
      build_tab('My Account', edit_user_registration_path(current_user), :user)
    end
end

And then in the view (settings.html.erb):

<%= view_object(:settings_tabs).html %>

We need only follow the pattern already laid out in HomeTabs to implement a brand new set of fully functioning tabs. If we want to modify the way our tabs are structured, we can do so in one place: the generic “Tabs” view object. Further, should the logic become more complex surrounding what tabs to show under different circumstances, we have the power of object-oriented code to help ease the pain.

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*