服务器端生成的 JavaScript 响应

开发 前端
Basecamp中的大多数Ajax操作都是在处理服务器生成的JavaScript响应(SJR)。它的工作原理是这样的。

Basecamp中的大多数Ajax操作都是在处理服务器生成的JavaScript响应(SJR)。它的工作原理是这样的:

  1. 表单通过一种XMLHttpRequest驱动的形式提交。
  2. 服务器创建或更新模型对象。
  3. 服务器生成包含了针对该模型对象的更新了的HTML模板的一个JavaScript响应。
  4. 客户来评估处理由服务器返回的JavaScript,然后会更新DOM。

这种简单的模式有一些重要的优势。

优点#1:重用模版而不影响性能

无论是第一次渲染和随后的模版更新,你都可以重用模版.如果使用Rails,有一部分技术像邮件/信息用于这两种情况。

如果你只返回JSON格式的信息,你得用你的模版将展示这些信息两次(一次是服务器端的第一次回应,一次是客户端随后的更新)—除非你做一个单一面页的JavaScript app,这个app的第一次回应是用JSON/客户端生成方式。

后面那种方式会很慢,因为要等整个的Javascript库load完并在客户端生成好模版你才能看到效果(这是Twitter早期所用的方式,但随后被背弃)。但至少在某些情况下这是一个合理的选择而且不需要多个模版。

优势 #2: 客户端需要更少的计算性能

虽然嵌入HTML模板的JavaScript可能造成响应数据量比JSON格式的响应要多(尽管用gzip压缩后几乎可以忽略),但是这不需要客户端去做很多的运算来更新页面。

这意味着,从端到端的观点出发,处理 JavaScript+HTML的响应数据的速度,应该比处理带有客户端模板性质的JSON数据要快,至于快多少,取决于客户端模板的复杂程度,以及客户端计算性能。而且这个速度应该是二倍关系,因为,服务器生成的模板可以通过缓存在多个用户之间共享(详见 Russian Doll缓存)。

优势 #3: 容易跟踪执行流

使用SJR会让跟踪执行流变得非常容易。请求的机制是标准化的,是会带有辅助逻辑“likeform_for @post, remote: true”. 当然没有必要对于每个动作都带上辅助逻辑。 接着控制器会以渲染完整视图的方式来渲染响应中的部分视图,其中的目标只能是JavaScript 而不是完全的HTML

完整示例

0)首先使用消息模板

  1. <h1>All messages:</h1> 
  2. <%# renders messages/_message.html.erb %> 
  3. <%= render @messages %> 

1) 以Ajax方式提交表单.

  1. <% form_for @project.messages.new, remote: true do |form| %> 
  2.   ... 
  3.   <%= form.submit "Send message" %> 
  4. <% end %> 

2) 服务器创建模型对象.

  1. class MessagesController < ActionController::Base 
  2.   def create 
  3.     @message = @project.messages.create!(message_params) 
  4.  
  5.     respond_to do |format| 
  6.       format.html { redirect_to @message } # no js fallback 
  7.       format.js   # just renders messages/create.js.erb 
  8.     end 
  9.   end 
  10. end 

3) 服务器产生内嵌入HTML的JavaScript响应.

  1. <%# renders messages/_message.html.erb %> 
  2. $('#messages').prepend('<%=j render @message %>'); 
  3. $('#<%= dom_id @message %>').highlight(); 

最后评估响应工作是由form_for产生的XMLHttpRequest-powered表单来自动处理的。视图因此由于新消息而更新,此外新消息也通过JS/CSS动画高亮显示

超越RJS

当我们一开始使用SJR时我们将它和一个叫做RJS的前身一起使用,使用RJS你需要写Ruby模板,然后再将它们转变成JavaScript。它是Coffeescript(或Opalrb,如果你喜欢的话)的简化版,它错误地让许多人舍弃了SJR模式。

现在我们不使用RJS了(更迭的原因通常很简单——优势不是那么大,只有极少数情况下才需要的没有必要那么复杂),但我们却一如既往地致力于SJR。

这并不意味着JSON数据在服务器端产生和视图在客户端形成的模式一无是处。对于我们的UI需要很高的保真度的时候,以及像日历这样的,有大量的视图状态需要维护的时候,这样的模式还是非常合适的。当需要走这条路的时候,我们使用Sam的卓越 Eco template system (认为ERB对于CoffeeScript).

如果你的网络应用都是高保真度的UI,那么走上面提到的那个路子是完全没有问题的。只是你正在花费高价给自己购买些花哨的东西,不过这算是个问题。但是如果你的应用有点像Basecamp或者Github这样网络上的以文本为基础的主流应用,那么你完全应该张开双臂拥抱SJR

 Russian Doll-caching, Turbolinks 和 SJR的融合简直就是一杯难以置信的给力鸡尾酒。它可以创造出快速的,现代化的,而且非常优美的代码类的网络应用,好好享用吧!

原文链接:https://37signals.com/svn/posts/3697-server-generated-javascript-responses

译文链接:http://www.oschina.net/translate/server-generated-javascript-responses

责任编辑:陈四芳 来源: 开源中国编译
相关推荐

2010-03-23 10:04:00

JavaScript

2011-09-08 10:21:50

Node.js

2018-06-07 10:45:41

浏览器服务器响应

2009-06-06 19:13:48

服务器端动态生成gif服务器端动态生成jpg

2011-07-26 11:07:08

JavaScript

2012-10-15 13:40:15

IBMdw

2014-01-15 10:06:30

vFlash

2010-01-08 13:48:51

JSON 形式

2010-08-27 10:23:26

DHCP服务器

2014-11-14 11:03:56

微软.NET

2023-06-30 08:00:00

漏洞网络安全SSTI

2015-11-04 14:14:56

HTTP网络协议

2011-06-07 16:01:46

Android 服务器 数据交互

2017-12-06 22:29:53

2022-05-07 15:54:56

小熊派鸿蒙

2009-07-06 17:22:54

JSP服务器

2021-05-26 09:00:00

Node.js开发模块

2021-07-27 06:14:32

服务器端移动端性能测试

2010-05-27 18:49:38

SVN入门

2010-04-21 13:18:33

RAC负载均衡配置
点赞
收藏

51CTO技术栈公众号