背景

Question

我一直在研究这个问题：

Using Rails 3.1, where do you put your "page specific" javascript code?

但我还没有看到一个令人满意的答案，这也让我怀疑自己是否做错了。

这是我的心理模型：对于不同的观点，我将有不同的

$(document).ready(....)

块，显然是引用非常特定于该页面的元素。我不希望通过为每个页面加载代码来污染事物，并以某种方式试图弄清楚如何在特定页面上执行它;这看起来很难看。

我的直觉，无可否认，没有任何初步实验支持，理想的是：

从application.js。
从assets / controller_name / shared.js
从资产/ controller_name / show.js

脱离我的头顶。帮助器第一次运行时会检查文件是否存在，如果存在，请执行javascript_include。

或许这有一些性能问题，而“让我们把整个事情包装成一个大粘球并发送所有”的方法，但似乎是一种更好的方法来划分代码。

然而，如上所述，我感觉我错过了一些东西。 $（document）.ready在每页基础上是一个坏主意吗？应该只是在模板中并从application.js调用JS的页面特定位？上面的链接文章得出了这个结论，但我不喜欢我在一个巨大的$（文件）头脑中的图像。如果这样，如果这样，如果是另一件事，那就很复杂了。

Answer 1

你建议的是声音，但不是轨道3.1方式。

他们说将JS分成许多文件，但作为一个整体用户。这样可以获得更好的性能和可扩展性，如果最后的大块泥浆不那么大，这是一件好事。实际上3个http请求的性能比1个http请求更差。

因此，您已经对代码进行了二次规划，因为您有不同的Coffeescript文件，这些文件具有不同的范围。

要在您的应用中加载，只需标准化初始化单段代码的方法，例如调用“myapp.users.init（）”方法 - 。

您甚至可以使用帮助程序自动化代码的安静性，因此它对控制器来说是透明的。

Answer 2

背景

（为什么要使用资产管道？）

Rails资产管道背后的基本前提之一是，最好先预先为站点加载所有JS和CSS，然后无限期地缓存它们（至少在网站更新之前）。 Asset Pipeline允许您相对自动地执行此操作，同时仍以逻辑方式组织JS和CSS src文件。

这当然会带来前期负载成本，可以节省加载单个文件的额外往返时间。如果这个前提并不合适，那么资产管道可能不适合你。

问题的坚果

好的，我们希望将所有JS合并到一个文件中，以便更有效地加载它。仅仅因为我们要加载我们所有的JS并不意味着我们想运行所有我们的JS。

在复杂的Web应用程序的现实中，您可能会拥有许多页面特定的功能，当用户没有查看相应的页面时，您不希望花费资源执行。我们需要的是一个统一的策略，只执行适用于当前页面的大单片JS文件部分。

救援公约

我不知道有一个正式的Rails策略来处理这个问题，但是有一些很好的解决方案可以建立并利用一个好的约定（这会使事情感觉变得困难＆＃34; railsy＆＃34;）。一般的想法是将所有特定于页面的JS代码定义到对象文字中，然后在加载时仅运行与当前页面相关的代码。

有关如何组织和有条件地执行JS代码的具体策略，请参阅@ welldan97关于此问题的答案：
Using Rails 3.1, where do you put your "page specific" javascript code?

反过来基于杰森加伯的这篇文章：
http://viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution

Rails 3.1中的页面特定javascript文件

2 个答案:

背景

（为什么要使用资产管道？）

问题的坚果

救援公约