Helpers and Partials

Noel Rappin, Friday, November 7, 2008 @ 3:08 pm

Picture of Sinatra from Wikipedia
Because he sang "Love and Marriage"..

Everybody sing! (to the tune of "Love and Marriage")

Helpers and Partials

Helpers and Partials

Go together like a

Fire and a Marshal.

Okay, that was silly. In my defense, the tune has been going through my head all day since I decided this would be my topic today.

Yes, we're back in Chapter One Zillion And Three in the ongoing epic: How Do You Write View Code Anyway?

Previously, I had tried to move as much view code as possible to helper methods. This produced some interesting code, as well as a threatened revolt on the part of the non-Ruby programming HTML designers and architects who had to look at it. Pitchforks and torches were mentioned, and there was muttering about know-it-all code monkeys. The primary complaint was that non-Rubyists couldn't easily modify the code buried in tangled Ruby gunk in helpers. At the same time, everybody agrees that ERb code running all over the place is a total mess.

What to do, what to do?

Listen to me, of course. Here are my thoughts about managing view code. This week.

Keep the view code as close to HTML as you can

This is something of a change for me -- I've always been a big fan of generating HTML from code, dating back to my first web apps. And I still think that generating HTML has a place. Still, working close to HTML has some advantages -- non-Ruby designers can tweak the view directly, which is much more efficient. It's easier for new people to join the team. ERb is, in my experience, close enough to HTML for people to be able to tweak. To give one other example, Haml is not.

Treat ERb with the respect that you treat your code

A slight attitude adjustment toward the ERb can help a lot. I see a lot of legacy Rails code that we get where the ERb files have been allowed to get out of hand in a way that a professional developer would never let plain Ruby code get out of hand. ERb is part of your code, and the same design principles that inform your code structure still apply.

• Don't Repeat Yourself in ERb
• Indentation and layout still help readability in HTML and ERb
• Refactoring ERb files is a valuable way to clean them up
• View code should be tested to ensure correct results

And so on. Replacing ERb with Ruby in the preceding list would make it seem like complete newbie advice, but not everybody treats their ERb the same way.

An individual ERb file is a method. Not a class.

The biggest problem in ERb files is that they get long and raggedy, which makes it increasingly difficult to find what's going on and make changes -- in exactly the same way that long methods make Ruby code hard to manage.

Luckily this is reasonably easy to manage by aggressively breaking ERb code off into partial methods, in much the same way that a long method is best refactored into a series of smaller methods. I like to break off code inside loops into a partial, headers, footers, and sidebars of various types are obvious candidates. Really, any coherent block of the page should be in it's own partial.

Doing this has several advantages.

• Keeping the ERb files smaller makes them easier to follow. I start to get nervous when they go longer then a screen, which is a mere 35 lines or so on my monitor. Obviously, sometimes you need an ERb chunk to be longer, but a long ERb file should at least trigger a "can I split this" thought.
• Your main page ERb will likely then largely consist of calling several partials. If you give the partials meaningful names, it's very easy to follow what the page is doing, you get some self-commenting code.
• It's almost inevitable that you'll find reuse opportunities for some of your small partials, especially in an Ajax-heavy site.

The main disadvantage is that it can get tricky to find a specific piece of page if you need to follow the code through nested partials. I find that clear naming tends to make this a minor problem.

Helpers are best used to help

Helpers are most useful, I think, for small, boilerplate pieces of code that are used frequently and which are unlikely to be messed with by designers. Basically, you're using them to improve the API to make it more specific to your application. Looking at recent projects, I see things like:

• Wrappers around commonly used link_to and link_to_remote patterns
• Wrappers around common HTML patterns -- such as header_row or label_block. Most of these are very short.
• Block guards along the lines of if_logged_in?
• Rarely, global data access methods along the lines of current_user, where it makes more sense to have a method rather than assign the data in some weird set of controller actions that might need it.
• As presenters, generating display-specific data based on a model, where you don't want to put the code in the model because it's view specific. The display-specific formatting of an address, for example.

Going much beyond that, I find from somewhat painful experience, and you run the risk of having some opaque view code in your helpers.

Your turn. How are you structuring view code these days?

Related posts:

1. Hide, Seek, and Stay Dry, part two: Controllers
2. Pretty Blocks in Rails Views
3. Down with HTML + Code Markup!
4. Bridging the Gap Between Rails Developers and HTML Designers
5. Hide and Go Seek, and Stay DRY (Part 1. Views)

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   How about using HAML?

   Comment by Seban, Wednesday, November 12, 2008 @ 6:09 am

2. 

   Great post! I wish I would’ve read something like this a couple of years ago. I still have a fair amount of legacy code that needs to be refactored into the “fewer helpers, more partials” model.

   For a long time, I felt like creating a partial (and thus adding another file to my app) made it more complex. But, it’s certainly better than bloated helper code.

   The Rails Textmate bundle is a lifesaver for this sort of refactoring. Highlight a chunk of view code, hit Ctrl-Shift-H, name your new partial and it does all the rest!

   http://github.com/drnic/ruby-on-rails-tmbundle/tree/master

   Comment by Doug Johnston, Thursday, November 13, 2008 @ 8:33 pm

3. 

   Seban — I meant to mention HAML in the original post, but I guess I forgot. Basically, I think that as long as you factor it well, and your designers are willing to work with it it’s fine, though I don’t see it as a huge breakthrough.

   Although I like the indent block thing — I was a happy Python programmer for a long time — it does break down on very long blocks, and poorly factored view code does have a lot of long blocks. Those people here who are primarily working with HTML had a pretty negative reaction to some sample HAML code that I was showing around.

   Comment by Noel Rappin, Friday, November 14, 2008 @ 2:11 pm

Leave a comment