Rails: Presenters, Facades, and Helpers - where does the html markup go?

Question

In a fairly large rails application we are running into the issue of overly complex views. Most of the views have too much logic.

Views have between 2 and 4 related instance variables, and make use of various logic checks and helper methods to render the view.

Here is a fake example:

<% if authorized?(@user) %>
  <!--some html-->
  <% recent_projects(@projects).each do |project| %>
    <!-- html & helper methods -->
  <% end %>
  <!--some more html-->
<% else %>
  <!--some html & helper methods-->
<% end %>

Presenters, Facades, and helpers:

I've been researching using the facade and/or presenter pattern to help expose the functionality we need in the view while extracting and isolating the complexity.

My Question is:

Where does the html live? Do I make several small view partials and render them conditionally from helper methods? Do I create a presenter which has methods that handle the logic and output of the html (using content_tag, etc)?

Any general "best practices" or guidance would be appreciated. If I haven't been clear ask questions and I will respond quickly.

Answer 1

I'm unsure what the best practice is specifically but what I think is that making smaller view partials is the way to go so that the view code is separated and can be separately maintained. Your presentation logic resides inside a Presenter class and renders appropriate partials from app/views.

I think that using content_tag is going to make your UI designer think, say, how to add a css class to an element, ultimately leading to more maintenance time. content_tags are fine if they are smaller and are not frequently updated in terms of styling.

Another point to keep in mind is if you are a developer who is also after cleanliness of code then imagine writing a content_tag for multi-line block of <div /> with paragraph of text with multiple inner tags. You'd have to start manipulating strings to handle this and sometimes it become time consuming to yourself and other developers to follow the code.

I'm sure there are many more goodies of keeping the view template separate from Presenters but the point mentioned above is one that I learned from one of my recent projects.