我听到一群 Rails 开发人员说 RJS 是邪恶的。我从来没有使用过它,因为我总是设法使用经典的 javascript 或 jquery 做我想做的事,所以我没有注意。现在我正在研究一些遗留代码,并且到处都是 RJS。
所以……是真的吗?使用 RJS 的缺点/优点是什么?
我听到一群 Rails 开发人员说 RJS 是邪恶的。我从来没有使用过它,因为我总是设法使用经典的 javascript 或 jquery 做我想做的事,所以我没有注意。现在我正在研究一些遗留代码,并且到处都是 RJS。
所以……是真的吗?使用 RJS 的缺点/优点是什么?
在讨论它是否邪恶之前,让我们先谈谈什么是 RJS。
RJS 将相同级别的抽象应用于 ActiveRecord 为 SQL 提供的高性能 Javascript 库。然而,Javascript 库的 RJS 覆盖远没有 ActiveRecord 对 SQL 适配器的覆盖那么完整。
Rails 仅附带对 Prototype/Script.aculo.us 的 RJS 支持。但是,有一些插件可用或正在开发中以支持其他 Javascript 库。例如 JRails 重写了基于 Prototype 的帮助器以使用 jQuery。mootools 和 Dojo 也有类似的插件。
认为 RJS 是邪恶的人,通常是那些对它生成 Prototype 代码感到不舒服的人,或者那些认为他们可以使用原始 Javascript 更轻松地完成事情的人。
RJS 并不完美,就像 ActiveRecord 也不完美一样,您必须经常放下编写原始的 Javascript 或 SQL 来完成您的工作。与 ActiveRecord 一样,您对高级选项越熟悉,您在不编写原始代码的情况下就能完成的工作就越多。
RJS 的一个奇妙之处在于它们本质上是视图,可以生成 Javascript。很容易将 RJS 提取为可以根据需要包含的部分,作为对控制器的响应或作为页面中包含的自定义 Javascript 函数的一部分。这使得代码更加 DRY 允许更简单的维护。
我个人经常使用 RJS。我发现它是一次接触大量 DOM 元素的完美方式。它带来了双重好处,即允许我创建丰富的 AJAX 网站,而无需编写太多 Javascript。然后我又讨厌写 Javascript。
考虑到我在 Rails 项目中用 JQuery 替换了我的 Prototype 底层库,我发现 RJS 非常有用。现在,有时可能会很痛苦,因为将 JavaScript 传回服务器执行还不是主流。
但是,我一般没有发现它与 RJS 有任何问题。我唯一的抱怨是我通常必须将 RJS 和普通的旧 Javascript 混合到我的 .rjs 文件中,所以这有点毫无意义。但它确实为您提供了一个干净的地方/方式来处理您的 Javascript 效果和 AJAX 调用,所以我认为作为“放置代码的标准地方”,它非常好。
RJS 很好,主要是因为它很容易集成到 Rails 项目中。为了让事情变得更简单并减少文件数量,你可以将它嵌入到你的控制器中,它有很多来自原型/脚本库的易于使用的帮助程序。感觉更像Ruby。
这确实意味着它与您的常规 Rails 代码没有完全分开,因为它很快就与您的其他代码混合在一起了。它还需要通过原型和 scriptaculous js 文件包含更多的外部库。
一些 jQuery 的东西非常干净。语法非常疯狂,但这意味着您可以将您的 js 完全从您的页面/控制器(不引人注目的 js)中提取出来,这是一种更清洁/分隔的做事方式。
更重要的是,jQuery 看起来像 javascript。所以你不会得到 javascript 和 Ruby 代码的奇怪组合。我喜欢鲁比。我不喜欢Javascript。但我更不喜欢两者的混合。如果你了解 JS,你会觉得它很熟悉。
Ryan Bates 有一个关于将 RJS 转换为 jQuery 的截屏视频。可能会让您对两者在语法上的区别有一个很好的了解:http ://railscasts.com/episodes/136-jquery
如果您不熟悉 JS(或 Prototype 之类的框架),但您需要 AJAX 功能 - RJS 是最好的方法。使用 RJS 的另一个优势是速度。轻松快速地编写 RJS 代码。
我之前在所有 Rails 项目中都使用了 RJS。现在我对 Prototype(和 jQuery)更加熟悉了,这就是我现在编写 JS 代码的原因。我需要这个,因为有很多 RJS 的控制器失去了它的生产力。将 RJS 代码移到 JS 中是扩展控制器的第一步。
没有人可以绝对地对你说,最好的方法是什么——是否使用 RJS。每个人都应该选择自己的方式。
例如,我更喜欢在我的应用程序的管理部分(不需要扩展任何东西)中使用 RJS,并为前端部分编写 JS。
RJS 不是“邪恶的”,但我认为它的问题是双重的:
用 RJS 做不显眼的 JavaScript 很难(不可能?)。如果您正在编写一个 Javascript 繁重的应用程序并且有很多逻辑,并且该逻辑发生了变化,那么您将不得不更改相当数量的文件,而不仅仅是一个。此外,这是个人喜好,看到带有压缩 Javascript 的标签遍布整个标签是相当难看的。
RJS 抽象出 Javascript,这可能导致对语言的无知。RJS 背后的想法是让开发人员能够只使用一种语言为 Web 应用程序编写所有内容(除了设计师可能会处理的 HTML 和 CSS):Ruby,但实际上这同样不足可以但不推荐通过拖放控件或使用大量繁重的代码生成向导来创建 ASP.NET 应用程序。如果您所需要的只是一个需要少量 Ajax 的简单解决方案,那么 RJS 就可以正常工作。
当您刚刚开始使用 Rails 并且需要一些“快速而肮脏”的 Ajax 效果时(例如,在同一页面上淡入淡出的博客的规范注释),RJS 是一个很好的工具。一旦你开始需要大量使用 Javascript,那么 RJS 就会成为一种负担,因为它使开发人员免受他们真正应该尝试理解的事情的影响。
RJS 只是 RHTML(现在称为 html.erb)的 JavaScript 等价物。它是一个执行嵌入式 Ruby 并将 JavaScript 返回到浏览器以更新页面的模板。这使您可以更好地控制 AJAX 应用程序中服务器端操作的结果。实际上,RJS 调用的结果由浏览器中的 JavaScript 解释器进行评估。将此与非 RJS AJAX 应用程序进行对比,在该应用程序中,服务器返回 HTML,该 HTML 通过异步请求的回调插入到页面中。
“邪恶”的部分是很多人对“eval”感到不舒服,但我认为这也可能是某种混淆的结果。
这里的许多响应似乎都集中在 JavaScript、Prototype 和 Scriptaculous Helpers,它们经常被用作 RJS 模板的一部分,但不是必需的。我确实广泛使用了这些帮助程序,因为它们与模板中的 Ruby 代码配合得更好,但它们不是 RJS 的必要部分。