拥有混合 Javascript 和 ruby​​ 的文件是否正确？ IE。 （.js.erb）？

Question

我最近读到在 JavaScript 中嵌入 ruby​​ 并不是一个好主意。 然而，在诸如 David Heinemeier Hansson 的 Agile Web Development with Rails 等书籍中，这正是它所做的。 如果用 JS 嵌入 ruby​​ 不是一个好主意，那么 这种情况的最佳做法是什么？ 给定这样简单的东西：（jQuery + ruby​​）

posts_controller

def create
  @post = Post.new(params[:post])
    respond_to do |format|
      if @post.save
        format.html { redirect_to(@post, :notice => 'Post was successfully created.') }
        format.js #will use this response to process ajax
      else
        format.html { render :action => "new" }
      end
    end
end

create.js.erb

$tr = $('<tr>');
$td1 = $('<td>').text('<%= @post.title %>');  
$td2 = $('<td>').text('<%= @post.content %>');
$tr.append($td1, $td2);
$('table tbody').append($tr);

应该如何重构以遵循不将 ruby​​ 嵌入 JS 的“最佳实践”？（如果是这样的话）

我真的需要对此有所启发，并且可能要正确理解这些概念，因为我已经读过 Rails 3.1 将通过资产将 JS 与 Ruby 完全分开？（这是正确的吗？）

谢谢！

Answer 1

是的，你可以写，但文件扩展名应该是

“.js.erb”

Answer 2

RJS 模板本质上是长期以来的工作方式，这就是为什么您仍然会在教程中看到该技术如此流行的原因。话虽如此，正如您所注意到的，他们正在退出，而且有充分的理由。

我确信 RJS 模板是一件非常糟糕的事情的原因有很多，但一个重要的原因是它们将您的视图 JS 与您的视图 HTML 耦合的紧密程度.许多问题由此产生，其中一些是：

1. 缺乏灵活性。

   以您的代码为例。如果您希望能够从不同的视图创建帖子怎么办？并有不一样的效果？也许页面上根本没有<table>，而您只想弹出“成功”消息？等等。

   如果您只是想要帖子的数据表示，但您的 javascript 模板是为了操作 HTML 而编写的？

   您如何在一个create.js.erb 中处理所有这些，这很可能与帖子new.html.erb 模板紧密耦合？

2. 复杂性。

   RJS 模板在某种程度上是在真空中运行的。在服务器端生成，它们的执行不受 DOM 事件的约束。这使得在创建对象后在页面上更新<form> 之类的操作变得很棘手，因为您没有参考框架来在 JS 模板中选择适当的<form>（例如<form id="new_post_123">） .有一些解决方法，但它们比需要的更复杂。

   通过绑定到一个表单客户端并处理结果，这个问题就被消除了。您无需在回复后找到合适的表格进行更新。

   使用 RJS，您没有这样的绑定，并且您不得不使用 HTML 的已知结构来检索和操作适当的元素。不必要的复杂性的一个例子。

---

关于您的问题：

我真的需要对此有所启发，并且可能要正确理解概念，因为我已经读过 Rails 3.1 将通过资产将 JS 与 Ruby 完全分开？（这是正确的吗？）

这基本上是正确的。资产管道虽然很酷，但并没有提供任何全新的东西。 Sprockets 和 Sass 等资产框架以及它们支持的工作流程已经存在了一段时间。 Rails 3.1 资产管道只是将它们带入标准实践。正如 DHH 在他最近的RailsConf keynote 中谈到的那样，这更像是一个观点问题。通过为这些资产（尤其是 js 文件）带来更大的组织，让它们感觉更像是一等公民，可以说，与您的后端代码一样值得关注。与public/javascripts 的“垃圾抽屉”感觉相反。

---

关于实现：

您可能会这样做（尽管未经测试且有点简化，例如在 Rails 3 中，您可能会为此使用响应者而不是 respond_to 块：

# as you have, but returning the object as data which can be handled client-side,
# rather than RJS generated by the server
def create
  @post = Post.new(params[:post])
  respond_to do |format|
    if @post.save
      format.js { render :json => @post }
    else
      # ...
    end
  end
end

// Then in your client side JS, a handler for your remote form.
$(function(){
  $('#your-create-form').bind('ajax:success', function(data, status, xhr) {
    // simply repeating what you had in the template, replacing the erb with
    // attributes from the returned json
    $tr = $('<tr>');
    $td1 = $('<td>').text(data.title);  
    $td2 = $('<td>').text(data.content);
    $tr.append($td1, $td2);
    $('table tbody').append($tr);
  });
}

Answer 3

我相信您会发现 PHP 开发人员、Perl、ASP 和任何其他服务器端语言的初学者都会问这个问题。似乎没有太多情况下您希望将 javascript 代码内联。唯一的情况可能是您根据特定情况对其进行自定义，但在我的脑海中我不能想想你需要像这样自定义它的任何情况。

性能方面，如果您有很多 javascript 并且将其全部包含在输出中，那么您的页面就会膨胀。如果您要添加一个大型应用程序，一个 1k 的页面将变成一个 >100k 的页面。此外，缓存该信息可能会更加困难，因为如果用户已登录，或者当天是否有特殊广告等。您最好将其拆分到自己的文件中，以便您也可以“最小化”它 (http://en.wikipedia.org/wiki/Minification_%28programming%29)。

从开发人员到开发人员，我可以给您讲述在 PHP 和 Smarty 模板中嵌入 javascript（和 html）的恐怖故事。善待与您合作的任何人，并将所有语言拆分成各自的文件。假设您正在与 Bob 一起工作，他是一个很棒的 javascript 人.. 但对应用程序以及它如何吐出代码一无所知。由于应用程序缺乏单点真实性，在 erb 中散布 javascript 会令人沮丧 - 如果他想调整某些东西，他将查看你所有的 erb 以确定他必须放在哪里它或它最初在哪里。您真的希望对您的后端结构知之甚少的人浏览这些文件吗？

虽然有几种情况您希望将 bootstrap 数据放入其中。如果您在启动时有大量数据要注入页面，请将其分配给页面启动时的几个变量比在每次页面加载时发出 ajax 请求更高效。

请对我们这些前端人员好点，除非你有一个真正好的理由.. 将 JS 保存在单独的文件中 :)

编辑：这是一个做你想做的事（我认为）的例子，没有真正使用模板化的 javascript：

app.js：

postUpdater = function (data) {
    $tr = $('<tr>');
    $td1 = $('<td>').text(data.title);  
    $td2 = $('<td>').text(data.content);
    $tr.append($td1, $td2);
    $('table tbody').append($tr);
};

$("#save_button").click(function () {
    $.post('/save/ur/', {the:data}, postUpdater);
});

在 ruby​​ 中，您只想将 @post 渲染为 json。我认为它实际上是 @post.to_json，但您可能必须 require 'json' 才能使其工作。不过，这可能会让你更快地到达那里：output formated json with rails 3（我不是真正的红宝石人..我们只是在我工作的公司使用它，所以我当然一直在接受它）

现在，关于为什么不只输出模板化的 javascript 文件的理论。假设您在保存该 javascript 文件时需要处理一大堆事情。这意味着您必须在该 ajax 请求上输出大量内容并执行它。您将通过互联网推送更大的文件（稍微慢一点），并且可能不得不“评估”响应（评估是邪恶的）。所以，这是一件坏事。另一个可能不好的事情是您无法访问您调用保存的位置。所以，如果我有这个观点..

new PostViewer({
    savePost: function () {
        var self = this;
        $.post('/save/url/', {the:data}, function (response) {
            self.trigger('saveSuccessful', response);
        });
    }
});

当 savePost 被调用时，简单地告诉视图“嘿，保存成功！”将更加困难（可能不会引入大量黑客）。

希望这对您正在寻找的目标更加准确。

Answer 4

如果您在 JavaScript 文件中嵌入动态数据，那么您通常必须为其提供适合经常变化的内容的缓存规则。

如果您需要使用 JS 处理动态内容，那么通常最好有一个静态的、可缓存的、可重用的脚本来从其他地方获取数据。

在这个具体的例子中，虽然我不确定，因为没有很多上下文，但看起来你最好直接生成 HTML，而不是生成生成 HTML 的 JS。