Why Rails Controllers need a Double Render

{{{
In one of my last posts I “already discussed the improvements”:http://nicksda.apotomo.de/2010/10/10-points-how-cells-improves-your-rails-architecture/ Cells brings to your Rails app by *providing view components*.

The last day I had an lively discussion about the concept of _partials_ or page fragments in Rails.

*Partials make me feel sick.* People ordinarily use ’em in order to have “_DRY_ code”. However, usually the extensive usage of partials makes the architecture even worse.

* Partials blow up your controllers which should be _slim_ – partials _always_ blindly access variables sitting in the controller, which *increases controller complexity* and makes your code break often. _Just use a non-existent local and you’re knocked out_.
* Partials can’t be rendered in the controller. Unavoidably this *shifts code and knowledge to views* – isn’t that a so called “NO-GO”?
* Partials itself *can’t be tested* separately.

Today I’d like to show one concrete use-case how to *really DRY up your view code* with Cells.

h3. What’s nice about partials

In our discussion we were refering to *a form that was rendered in every action*. A Rails developer will put the form in a partial. This is _a good thing_.

*_UPDATE:_* The real form was way more complex! For educational purposes *I cut down this example* – I wouldn’t implement such an easy task with Cells, Lonny! 😉

Now we found out we need a customized button title in the form. We have two possibilities at this time.

* Save the *title in an instance variable* read by the partial.
* Pass the *title as a local* when rendering the partial.

The first is terrible. The second looked like this.

render :partial => "form", 
  :locals => {:title => "Create item."}

And in another view.

render :partial => "form", 
  :locals => {:title => "Update this item."}

The coached colleagues learning Rails asked: “_But… isn’t that the opposite of DRY?_” and I said “Yes.”.

h3. Can Helpers help?

We had several *identical calls in our views*. They started working out different approaches with helpers.

def my_form(title)
  render :partial => "form", #...

*Using helpers they were forced to use instance variables, again*, for transporting information _from controller to view to helper to partial_. It was a mess.

Suddenly, someone came up with a new idea: _”What if we call the helper in the controller?”_ – they tried, and failed. Every Rails developer has to *meet the @DoubleRenderError@ once in his life*.

I interrupted the experiment and introduced Cells getting wet.

h3. DRY up your views!

We simply put the view and associated code in a cell.

class FormCell < Cell::Base
  def display
    @title = opts[:title] or raise "No title passed!"
    render
  end
end

The state view reads the instance variable.

  = form_tag do # ...
  
    = submit_tag @title, :id => :btn

Using instance variables here is ok. Remember, we’re *in a small cell instance.* You don’t pollute a complete request controller with some rich _title_.

Even better, we got some options validation, too.

h3. Rendering twice in the controller

As we needed the form in every action, we *rendered it in a before_filter*. Yeah, Cells can be rendered just anywhere.

  class ItemController  "Create item", 
                :edit   => "Update this item"}

      @form_html = render_cell(:form, :display, 
        :title => titles[action_name])
    end

This is pretty DRY.

* We define titles and render the corresponding form *in one place*, as they do go together. We *don’t spread a bit code to every action*.
* The controller instance variable contains the rendered form markup.

Naturally, you’re not bound to filters – this is just a simple example.

h3. Testing the form

Being an agile TDD team we instantly travelled back in time and *wrote a test before implementing the cell*.

class FormCellTest  "Test your partials!"
    assert_select "form #btn", "Test your partials!"
  end

Having an *object-oriented partial* with backing functional test we decided to knock off work for today.

You can find the “Cells repo here”:http://github.com/apotonick/cells.
}}}