Home/ Questions/Q 610347
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:39:55+00:00

Warning: Noob here. I know this is a trivial subject but I’m having a

  • 0

Warning: Noob here.

I know this is a trivial subject but I’m having a lot of difficulty in figuring out how exactly I can simplify my views by moving parts of them into helpers. For example, I’ve always read that conditionals in your views are prime candidates for extraction into helpers, but I couldn’t really find examples of this, and my attempts to achieve this failed.

For example, suppose I have:

#index.html.erb

<% for beast in @beasts do -%>
  <% if beast.dead? -%>
    <%= beast.body %>
    <%= link_to "bury", bury_beast_path( :id => beast.id ) %>
  <% else -%>
    <%= beast.body %>
    <%= link_to "kill!", kill_beast_path( :id => beast.id ) %>
  <% end -%>
<% end -%>

It annoys me a little to have this in my view, but how exactly could I move this to a helper instead? And further simplify it, if possible. (I’ve read somewhere that conditionals are bad but it’s just beyond me how you could program anything without them.)

Another example: I need to id my body tags with the format controller_action. The best I’ve got so far is this:

#index.html.erb

<body id="<%= controller_action %>">

…and…

#application_helper.rb

def controller_action
  @id = @controller.controller_name + "_" + @controller.action_name
end

I’m no expert, but that’s still ugly even to me.

To make things more complicated, Ryan Singer said something I liked: to treat ERB like an image tag, using helpers to “reveal intention”. Then in the next breath saying that you should have no HTML in helpers for that is the way to hell. WTF? How are both things compatible? If it’s come to the point where you can just declare behaviors in the view, surely there should be a lot of HTML to be rendered behind the scenes? I can’t grasp it.

So, that’s basically it. I’d appreciate if anyone could share some thoughts on this, or point me to some good in depth reading on the subject – which I’ve found to have a really weak coverage on the web. I’ve already googled it to exhaustion but who knows.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Refactoring makes your views easier to maintain. The problem is choosing where the refactored code goes.

    Your two choices are partials and helpers. There’s no stone-set rules dictating which should be used where. There are a couple of guidelines floating around like the one stating that helpers should not contain HTML.

    Generally partials are better suited for refactoring sections that are more HTML/ERB/HAML than ruby. Helpers on the other hand are used for chunks of ruby code with minimal HTML or generating simple HTML from parameters.

    However, I don’t agree with the sentiment that helpers should contain no HTML at all. A little is ok, just don’t over do it. The way helpers are processed hinder their use for producing large amounts of HTML. Which is why it’s suggested that your helpers contain minimal amounts of HTML. If you look at the source the helpers that ship with rails you will notice that most of them generate html. The few that don’t, are mainly used to generate parameters and evaluate common conditions.

    For example, any of the form helpers or link_to variants fit the first form of helpers. While things like url_for and logged_in? as supplied by various authentication models are of the second kind.

    This is the decision chain I use to determine whether to factor code from a view into a partial or helper.

    1. Repeating or nearly identical statements producing a single shallow html tag? => helper.
    2. Common expression used as an argument for another helper? => helper.
    3. Long expression (more than 4 terms) used as an argument for another helper? => helper.
    4. 4 or more lines of ruby (that is not evaluated into HTML)? => helper.
    5. Pretty much everything else => partial.

    I’m going to use the code you’re looking to refactor as an example:

    I would refactor the view in the question this way:

    app/helpers/beast_helper.rb:

    def beast_action(beast)
  if beast.dead?
    link_to "bury", bury_beast_path(beast)
  else
    link_to "kill!", kill_beast_path(beast)
  end
end

    app/views/beasts/_beast.html.erb:

    <%= beast.body %>
<%= beast_action(beast) %>

    app/views/beasts/index.html.erb:

    <%= render :partial => "beast", :collection => @beasts %>

    It’s technically more complicated, because it’s 3 files, and 10 lines total as opposed to 1 file and 10 lines. The views are now only 3 lines combined spread over 2 files. The end result is your code is much more DRY. Allowing you to reuse parts or all of it in other controllers/actions/views with minimal added complexity.

    As for your body tag id. You should really be using content_for/yield. For that kind of thing.

    app/views/layouts/application.html.erb

    ...
<body id="<%= yield(:body_id) %>">
...

    app/views/beasts/index.html.erb

    <% content_for :body_id, controller_action %>
...

    This will allow you to override the id of the body in any view that requires it. Eg:

    app/views/users/preferences.html.erb

    <% content_for :body_id, "my_preferences" %>
    • 0