DRYing rails视图:partial vs helper

san*_*rew 17 refactoring ruby-on-rails dry view

我需要有关DRYing视图代码的最佳实践的建议.我的应用程序中有三个类(NewsItem,RssItem和BlogItem),它们使用不同的视图,但其中包含类似的部分.其中一个部分是这样的:

<% if current_user %>
<footer>
  <%= marks_bar(@item) %>
  <%= favorite_button(@item, "blog_item") || delete_from_favorite_button(@item, "blog_item") %>
  <%= share_button(@item) %>
  <% if current_user.is_mine?(@item) %>
    <div><%= link_to "Edit", edit_user_blog_item_path(current_user, @item) %></div>
  <% end %>
</footer>
<% end %>
Run Code Online (Sandbox Code Playgroud)

这三个班级几乎相同,所以我决定把它带到一个不同的地方.在这里我很困惑:我应该使用部分或辅助方法吗?我知道帮助程序主要用于从HTML中分离ruby代码,但在这种情况下,帮助程序将如下所示:

def toolbar_for(item, type_str, edit_path)
  if current_user
    content_tag(:footer) do |b|
      marks_bar(item).to_s <<
      (delete_from_favorite_button(item, type_str) || favorite_button(@item, type_str)).to_s <<
      share_button(@item).to_s <<
      (content_tag(:div) { link_to("Edit", edit_path)} if current_user.is_mine?(@item)).to_s
    end
  end
end
Run Code Online (Sandbox Code Playgroud)

所以,这里几乎没有HTML代码.

你能不能给我一些建议,你认为哪种方法更好,为什么?此外,这些方法中是否存在一些性能问题(例如,多个字符串串联或频繁的部分加载可能代价高昂)?(这个应用程序相当高负载)

die*_*mes 17

我想说这是一个很好的例子.

我保留帮助生成任意动态内容.这是一个松散的描述,所以如何一个例子:我会做一个帮助,分割一个ActiveRecord对象数组并将它们显示为N列.在这种情况下,传递对象的结构以某种方式被利用以生成内容,但内容本身并不重要.如果您考虑一下,form_for也适合这种描述.

相反,partials非常适合"静态"内容,需要在多个页面上重复使用.例如,您将创建一个部分来呈现单个项目.部分确定特定项目的"静态"表示.

在我看来,你的例子更适合第二个垃圾箱.由于@item没有被操纵来生成内容,实际上它几乎没有被使用.看来这个助手大多是其他适当创建的助手(share_buttonmarks_bar)的胶水代码.部分完美的用例!


kar*_*kie 6

我会使用一个视图部分为此.好的经验法则:如果HTML是输出,请使用部分.帮助程序不是Rails应用程序的垃圾抽屉 - 它们应该用于输出数据,而不是表示.虽然我通常建议人们一般避开帮助者,而是赞成主持人,这些人在Rails世界中大量未充分利用.

  • 好吧,实际上我不认为,"如果HTML是输出,使用部分"是唯一的事实.事实上,form_for,link_to等等也是帮助者. (7认同)