根据我的理解，所有的JavaScript都合并到一个文件中。Rails在添加//= require_tree时默认这样做。到你的application.js manifest文件的底部。
这听起来像是一个真正的救星，但我有点担心特定于页面的JavaScript代码。这段代码是否在每一页上执行?我想要的最后一件事是当我的所有对象只在1页上需要时，为每一页实例化它们。
此外，代码是否也有可能发生冲突?
还是在页面底部放置一个小的脚本标记，只调用一个执行页面javascript代码的方法?
你不再需要require.js了吗?
谢谢
编辑:我很感激所有的答案…我认为他们并没有真正解决问题。其中一些是关于样式的，似乎没有关联……其他人只是提到javascript_include_tag…我知道这是存在的(很明显…)，但Rails 3.1的前进方式似乎是将所有JavaScript打包到一个文件中，而不是在每个页面的底部加载单个JavaScript。
我能想到的最好的解决方案是用id或类将某些特性包装在div标签中。在JavaScript代码中，只需检查id或类是否在页面上，如果在，则运行与之关联的JavaScript代码。这样，如果动态元素不在页面上，JavaScript代码就不会运行——即使它包含在由Sprockets打包的庞大application.js文件中。
我上面的解决方案的好处是，如果一个搜索框包含在100个页面中的8个页面上，那么它将只在这8个页面上运行。你也不需要在网站的8个页面上包含相同的代码。事实上，您再也不需要在站点的任何地方包含手动脚本标记。
我想这就是我问题的真正答案。
你可以在你的布局文件(例如application.html.erb)中添加这一行来自动加载特定于控制器的javascript文件(当你生成控制器时创建的那个):
<%= javascript_include_tag params[:controller] %>
您还可以添加一行来在每个操作的基础上自动加载脚本文件。
<%= javascript_include_tag params[:controller] + "/" + params[:action] %>
只需将页面脚本放到以控制器名称命名的子目录中。在这些文件中，您可以使用=require包含其他脚本。
最好创建一个助手，只在文件存在的情况下包含该文件，以避免浏览器出现404错误。
这个问题在很久以前就被回答和接受了，但是我基于其中一些答案和我使用Rails 3+的经验提出了我自己的解决方案。
资产管道是甜蜜的。使用它。
首先，在你的application.js文件中，删除//= require_tree。
然后在你的application_controller中。Rb创建一个helper方法:
helper_method :javascript_include_view_js //Or something similar
def javascript_include_view_js
if FileTest.exists? "app/assets/javascripts/"+params[:controller]+"/"+params[:action]+".js.erb"
return '<script src="/assets/'+params[:controller]+'/'+params[:action]+'.js.erb" type="text/javascript"></script>'
end
end
然后在你的application.html.erb布局文件中，在现有的javascript include中添加你的新helper，并以raw helper为前缀:
<head>
<title>Your Application</title>
<%= stylesheet_link_tag "application", :media => "all" %>
<%= javascript_include_tag "application" %>
<%= raw javascript_include_view_js %>
</head>
瞧，现在您可以使用与rails中其他地方相同的文件结构轻松创建特定于视图的javascript。简单地把你的文件放在app/assets/:namespace/:controller/action.js.erb!
希望这能帮助到其他人!
我没有看到一个答案，真正把它放在一起，并为你铺开。因此，我将尝试把meleyal, sujal (la ClosureCowboy)， Ryan回答的第一部分，甚至Gal关于Backbone.js的大胆陈述……以一种简短而清晰的方式把它们放在一起。谁知道呢，我甚至可能满足Marnen Laibow-Koser的要求。
例子编辑
资产javascripts / js应用程序。
//= require jquery
//= require jquery_ujs
//= require lodash.underscore.min
...
视图/布局/ application.html.erb
...
</footer>
<!-- Javascripts ================================================== -->
<!-- Placed at the end of the document so the pages load faster -->
<%= javascript_include_tag "application" %>
<%= yield :javascript %>
</body>
</html>
视图/ foo / index . html . erb
...
<% content_for :javascript do %>
<%= javascript_include_tag params[:controller] %>
<% end %>
资产javascripts / foo js。
//= require moment
//= require_tree ./foostuff
assets/javascripts/foostuff/foothis.js.coffee
alert "Hello world!"
简要描述
Remove //= require_tree . from application.js and list only the JS that each page shares.
The two lines shown above in application.html.erb tell the page where to include application.js and your page-specific JS.
The three lines shown above in index.html.erb tells your view to look for some page-specific JS and include it at a named yield region called ":javascript" (or whatever you want to name it). In this example, the controller is "foo" so Rails will attempt to include "foo.js" at the :javascript yield region in the application layout.
List your page-specific JS in foo.js (or whatever the controller is named). List common libraries, a tree, directories, whatever.
Keep your custom page-specific JS someplace where you can easily reference it apart from your other custom JS. In this example, foo.js requires the foostuff tree so put your custom JS there, such as foothis.js.coffee.
There are no hard rules here. Feel free to move things around and perhaps even create multiple yield regions of various names in various layouts if needed. This just shows one possible first step forward. (I don't do it exactly like this given our use of Backbone.js. I might also choose to drop foo.js down into a folder called foo instead of foostuff but haven't decided that yet.)
笔记
你可以用CSS和<%= stylesheet_link_tag params[:controller] %>做类似的事情，但这超出了问题的范围。
如果我在这里错过了一个明显的最佳实践，给我发个便条，我会考虑适应。Rails对我来说相当新鲜，老实说，到目前为止，我对它默认给企业开发带来的混乱以及普通Rails程序产生的所有流量并没有太大印象。
