个人中心
gpt4 book ai didi

ruby-on-rails - Rails : Refactoring, View ，助手 : how does it all go together?

转载 作者：行者123 更新时间：2023-12-03 14:37:04 24 4
gpt4 key购买 nike

警告:这里是菜鸟。

我知道这是一个微不足道的主题，但我很难弄清楚如何通过将部分 View 移入助手来简化我的 View 。例如，我一直读到您观点中的条件是提取到帮助程序中的主要候选者，但我真的找不到这方面的例子，而且我实现这一目标的尝试失败了。

例如，假设我有:

#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 -%>

在我看来，这让我有点恼火，但我怎么能把它移到一个助手身上呢？如果可能的话，进一步简化它。 (我在某处读到条件语句不好，但我无法在没有它们的情况下编写任何东西。)

另一个例子:我需要 id我的 body格式为 controller_action 的标签.到目前为止，我得到的最好的是: 
#index.html.erb

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

…和… 
#application_helper.rb

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

我不是专家，但这对我来说仍然很丑陋。

为了让事情变得更复杂， Ryan Singer said something I liked :将ERB视为图像标签，使用助手“揭示意图”。然后在下一次呼吸中说你不应该在帮助程序中使用 HTML，因为那是通往 hell 的道路。怎么回事？两者如何兼容？如果到了可以只在 View 中声明行为的地步，那么肯定应该有很多 HTML 需要在幕后渲染吗？我无法掌握。

所以，基本上就是这样。如果有人能就此分享一些想法，或者指出我对这个主题的一些深入阅读，我将不胜感激——我发现它在网络上的报道非常薄弱。我已经用谷歌搜索了它，但谁知道呢。

最佳答案

重构使您的 View 更易于维护。问题在于选择重构代码的去向。

你的两个选择是部分 和 helper .没有一成不变的规则规定应该在哪里使用。有几条准则漂浮在各处，例如声明助手不应包含 HTML 的准则。

通常，partials 更适合重构 HTML/ERB/H​​AML 而非 ruby​​ 的部分。另一方面，帮助程序用于具有最少 HTML 的 ruby​​ 代码块或从参数生成简单的 HTML。

但是，我不同意助手根本不应该包含 HTML 的观点。一点点就好了，不要过度。处理助手的方式阻碍了它们用于生成大量 HTML。这就是为什么建议您的助手包含最少量的 HTML 的原因。如果您查看 Rails 附带的帮助程序的源代码，您会注意到它们中的大多数都生成 html。少数没有，主要用于生成参数和评估常见条件。

例如，任何形式的帮助程序或 link_to 变体都适合第一种形式的帮助程序。而像url_for和logged_in这样的东西？由各种身份验证模型提供的属于第二种。

这是我用来确定是否将 View 中的代码分解为部分代码或帮助程序的决策链。

  • 重复或几乎相同的语句产生单个浅 html 标记？ => helper 。
  • 用作另一个助手的参数的常用表达式？ => helper 。
  • 用作另一个助手的参数的长表达式(超过 4 个术语)？ => helper 。
  • 4 行或更多行 ruby​​(未评估为 HTML)？ => helper 。
  • 几乎所有其他东西=>部分。

    • 我将以您要重构的代码为例:

    我会以这种方式重构问题中的观点:

    应用程序/帮助者/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

    应用程序/views/beasts/_beast.html.erb: 
    <%= beast.body %>
    <%= beast_action(beast) %>

    应用程序/ View /野兽/index.html.erb: 
    <%= render :partial => "beast", :collection => @beasts %>

    它在技术上更复杂，因为它是 3 个文件，总共 10 行，而不是 1 个文件和 10 行。这些 View 现在只有 3 行组合，分布在 2 个文件中。最终结果是您的代码更加干燥。允许您在其他 Controller / Action / View 中重用部分或全部，而增加的复杂性最小。

    至于你的 body 标签ID。你真的应该使用 content_for/屈服。对于那种事。

    应用程序/ View /布局/application.html.erb 
    ...
    <body id="<%= yield(:body_id) %>">
    ...

    应用程序/ View /野兽/index.html.erb 
    <% content_for :body_id, controller_action %>
    ...

    这将允许您在任何需要它的 View 中覆盖 body 的 id。例如:

    app/views/users/preferences.html.erb 
    <% content_for :body_id, "my_preferences" %>

    关于ruby-on-rails - Rails : Refactoring, View ，助手 : how does it all go together?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2194745/

    24 4 0
    文章推荐： .net - 我的 URL 中问号的名称是什么？
    文章推荐： json - 从JSON提取值
    文章推荐： python - 如何在绘图中使用自定义png图像标记？
    文章推荐： f# - F#:如何优雅地选择和分组受歧视的工会？
    行者123
    个人简介

    我是一名优秀的程序员,十分优秀！

    滴滴打车优惠券免费领取
    滴滴打车优惠券
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com