Skip to content

Steve Hill

DRYing Views: Tables, Partials, and Helpers

code, rails, refactor3 min read

I recently morphed the complex multi-partial table-building system of my Ruby on Rails app, ExpenseLynx, into a more generic helper method. This is the story of how I arrived at the decision and test drove the result.

I've just been developing a hair over two years now, but one thing I've heard consistently since the beginning is that helpers are undesirable. Dare I say excessive use of helpers is even considered a smell. As a direct result, the very idea of adding to the generated *Helper classes in a Rails application rarely crosses my mind.

Receipt Tables

I'm displaying information about receipts in several places in ExpenseLynx. The information displayed with the receipts is context-sensitive, with the goal of enhancing the user experience by shedding information that isn't relevant.

Creating Expense Reports

If we're creating expense reports, for example, we already know the receipts we're looking at are expensable and unexpensed; displaying this information would just be clutter. Showing whether or not these receipts are ready for a full export to CSV is helpful. Further, we need to be able to select any combination of receipts and build an expense report from those.

Unexpensed Receipts

Viewing Receipts

For the vast majority of interaction, one doesn't need to leave the main screen. Entering receipts sends an AJAX call to the server, which then returns a new table of the most recent receipts. There are no editing functions in this context as of now, and thus checkboxes in a row are unnecessary. This view does essentially serve as a confirmation of entered receipts, which is why the expensable status is useful.

Recent Receipts


Duplicated code is a bad thing. Always.

My first solution for this table appearing everywhere was to create a partial called _receipt_table.slim. To get rid of the iterating logic inherent in creating tables, I took advantage of RoR's facility for passing a collection of receipts to another partial called _receipt.slim. The framework delightfully handles iteration.

As shown above, these tables aren't completely identical. There are six columns displayed in each, but only three are common. We could easily envision a seven column scenario where expense status is displayed and checkboxes appear for mass edit-ability. Every different display requires some conditional logic. This is where the partial system I had fell down and became brittle.

Adding a Receipt Table to a View

In order to add a receipt table with specified columns, one would have to first call the _receipt_table.slim partial, horrifically specifying all the local variables used in the template.

1== render :partial => "receipts/receipt_table", \
2 :collection => @receipts, \
3 :locals => { :expensable => expensable, \
4 :expensed => expensed }

This code would predictably render the called partial with the appropriate table headers. It then passes the collection and the previously mentioned local variables through to the _receipt.slim partial.

2 tr
3 th Date
4 th Store
5 th Total
6 - if expensable
7 th Expensable?
8 - if expensed
9 th Expensed?
10 == render :partial => "receipts/receipt", \
11 :collection => receipts, \
12 :locals => { :expensable => expensable, \
13 :expensed => expensed }

The _receipt.slim partial is called once for every item in the collection, where the passed in local variables are evaluated again to render the appropriate table cells.

2 td= receipt.purchase_date.to_date.to_s(:short)
3 td= link_to, edit_store_path(
4 td.right= link_to number_to_currency(, receipt
5 - if expensable
6 boolean_to_check receipt.expensable?
7 - if expensed
8 boolean_to_check receipt.expensed?

So, What's the Problem?

Certainly the code above wasn't going to win any elegance competitions. It did work though, and that was good enough at the moment. The biggest problem showed itself when I was adding the Export Ready? column. To add my column to the partials, I would have had to do several things:

  1. Add an if statement and new column name to _receipt_table.slim
  2. Add an if statement and new column name to _receipt.slim
  3. Change _receipt_table.slim to pass a new local variable into _receipt.slim
  4. Manually track down every instance of _receipt_table.slim and pass a new local variable with a value of false in

I found it so difficult to reuse these partials that I just ended up rewriting the table...which clearly duplicated code and gave me all the hints necessary that it was time to rework the partial system I had created. At a minimum, I want two things:

  1. open only one file to change column headers and cells
  2. not have to track down all usages when I modify the table

grid_for Helper

I had an idea of the syntax I wanted beforehand. Ideally, I'd like to be able to display a default grid easily:

1== grid_for @receipts

Adding options should also be in a sentence-like, declarative way:

1== grid_for @receipts, { :shows_expense_status => true }

In this style, we're avoiding passing difficult-to-remember :locals around, which as we saw above are sort of duplicative in their own right. We can abstract further than Expensable? and Expensed? since they always appear in tandem.

To get there, I test drove my helper with rspec tests.

1require 'spec_helper.rb'
1describe :grid_for do
2 before do
3 @receipts = [Receipt.make!(:colins_unexpensed_tv_from_circuit_city)]
4 end
6 context :default do
7 subject { grid_for(@receipts) }
8 it { should include "Purchase Date" }
9 it { should include "Store" }
10 it { should include "Total" }
11 it { should include @receipts.first.purchase_date.to_s }
12 it { should include }
13 it { should include }
14 end

Which ultimately yielded this implementation of grid_for

1def grid_for(receipts, options = {})
2 options.each { |opt| opt = false if opt.nil? }
3 render :partial => "receipts/table",
4 :locals => { :receipts => receipts,
5 :editable => options[:editable],
6 :shows_expense_status => options[:shows_expense_status],
7 :shows_export_status => options[:shows_export_status] }

The new helper is still calling a partial template, which effectively just combined _receipt_table.slim and _receipt.slim. Opening this one file now allows me to add to table headers and cells.

2 thead
3 tr
4 - if editable
5 th= check_box_tag "select_all"
6 th Purchase Date
7 th Store
8 th Total
9 - if shows_expense_status
10 th Expensable?
11 th Expensed?
12 - if shows_export_status
13 th Export Ready?
14 tbody
15 - receipts.each do |r|
16 tr
17 - if editable
18 td= check_box_tag "receipt_ids[]",
19 td= r.purchase_date
20 td= link_to r.store_name, [:edit,]
21 td.right= link_to money(r.total_money), [r]
22 - if shows_expense_status
23 boolean_to_check r.expensable?
24 boolean_to_check r.expensed?
25 - if shows_export_status
26 boolean_to_check r.exportable?


As was the goal with Pragmatic Refactor: JavaScript Confirmation Messages, we found something in a painful state and rearranged it to remove roughly half the pain.


  • Our views can now deal with a higher level of abstraction that doesn't require us to track down each usage with new additions to the table
  • Our grid_for helper is easier to modify than the series of partials
  • Table headers and cells can be added in the same file

Things to Improve

  • Adding a table still requires me to add the same if statement for table headers and cells
  • If I were to add a new conditional column in the table, I'd still need to add to the markup file and the helper file


  • Can this be a gem? Didn't find anything when briefly searching

Fun Fact The only thing currently evaluated in Export Ready? is whether or not the receipt's store has an expense category.

Fun Files At the time of this posting:

  • application_helper.rb
  • application_helper_spec.rb (see the rest of the tests!)
  • _table.slim