Basecamp中的大多數(shù)Ajax操作都是在處理服務(wù)器生成的JavaScript響應(yīng)（SJR）。它的工作原理是這樣的：

創(chuàng)新互聯(lián)建站是一家專(zhuān)業(yè)提供岳普湖企業(yè)網(wǎng)站建設(shè),專(zhuān)注與成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、H5網(wǎng)站設(shè)計(jì)、小程序制作等業(yè)務(wù)。10年已為岳普湖眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專(zhuān)業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

1. 表單通過(guò)一種XMLHttpRequest驅(qū)動(dòng)的形式提交。
2. 服務(wù)器創(chuàng)建或更新模型對(duì)象。
3. 服務(wù)器生成包含了針對(duì)該模型對(duì)象的更新了的HTML模板的一個(gè)JavaScript響應(yīng)。
4. 客戶來(lái)評(píng)估處理由服務(wù)器返回的JavaScript，然后會(huì)更新DOM。

這種簡(jiǎn)單的模式有一些重要的優(yōu)勢(shì)。

優(yōu)點(diǎn)#1：重用模版而不影響性能

無(wú)論是第一次渲染和隨后的模版更新,你都可以重用模版.如果使用Rails,有一部分技術(shù)像郵件/信息用于這兩種情況。

如果你只返回JSON格式的信息，你得用你的模版將展示這些信息兩次(一次是服務(wù)器端的第一次回應(yīng)，一次是客戶端隨后的更新)—除非你做一個(gè)單一面頁(yè)的JavaScript app,這個(gè)app的第一次回應(yīng)是用JSON/客戶端生成方式。

后面那種方式會(huì)很慢，因?yàn)橐日麄€(gè)的Javascript庫(kù)load完并在客戶端生成好模版你才能看到效果(這是Twitter早期所用的方式，但隨后被背棄)。但至少在某些情況下這是一個(gè)合理的選擇而且不需要多個(gè)模版。

優(yōu)勢(shì) #2: 客戶端需要更少的計(jì)算性能

雖然嵌入HTML模板的JavaScript可能造成響應(yīng)數(shù)據(jù)量比JSON格式的響應(yīng)要多（盡管用gzip壓縮后幾乎可以忽略），但是這不需要客戶端去做很多的運(yùn)算來(lái)更新頁(yè)面。

這意味著，從端到端的觀點(diǎn)出發(fā)，處理 JavaScript+HTML的響應(yīng)數(shù)據(jù)的速度，應(yīng)該比處理帶有客戶端模板性質(zhì)的JSON數(shù)據(jù)要快，至于快多少，取決于客戶端模板的復(fù)雜程度，以及客戶端計(jì)算性能。而且這個(gè)速度應(yīng)該是二倍關(guān)系，因?yàn)椋?wù)器生成的模板可以通過(guò)緩存在多個(gè)用戶之間共享（詳見(jiàn) Russian Doll緩存）。

優(yōu)勢(shì) #3: 容易跟蹤執(zhí)行流

使用SJR會(huì)讓跟蹤執(zhí)行流變得非常容易。請(qǐng)求的機(jī)制是標(biāo)準(zhǔn)化的，是會(huì)帶有輔助邏輯“l(fā)ikeform_for @post, remote: true”. 當(dāng)然沒(méi)有必要對(duì)于每個(gè)動(dòng)作都帶上輔助邏輯。 接著控制器會(huì)以渲染完整視圖的方式來(lái)渲染響應(yīng)中的部分視圖，其中的目標(biāo)只能是JavaScript 而不是完全的HTML

完整示例

0)首先使用消息模板

 
 
 

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

1) 以Ajax方式提交表單.

 
 
 

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

2) 服務(wù)器創(chuàng)建模型對(duì)象.

 
 
 

  
  
  
class MessagesController < ActionController::Base 
  
  
  
  def create 
  
  
  
    @message = @project.messages.create!(message_params) 
  
  
  
 
  
  
  
    respond_to do |format| 
  
  
  
      format.html { redirect_to @message } # no js fallback 
  
  
  
      format.js   # just renders messages/create.js.erb 
  
  
  
    end 
  
  
  
  end 
  
  
  
end 
 
 
 

3) 服務(wù)器產(chǎn)生內(nèi)嵌入HTML的JavaScript響應(yīng).

 
 
 

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

最后評(píng)估響應(yīng)工作是由form_for產(chǎn)生的XMLHttpRequest-powered表單來(lái)自動(dòng)處理的。視圖因此由于新消息而更新，此外新消息也通過(guò)JS/CSS動(dòng)畫(huà)高亮顯示。

超越RJS

當(dāng)我們一開(kāi)始使用SJR時(shí)我們將它和一個(gè)叫做RJS的前身一起使用，使用RJS你需要寫(xiě)Ruby模板，然后再將它們轉(zhuǎn)變成JavaScript。它是Coffeescript（或Opalrb，如果你喜歡的話）的簡(jiǎn)化版，它錯(cuò)誤地讓許多人舍棄了SJR模式。

現(xiàn)在我們不使用RJS了（更迭的原因通常很簡(jiǎn)單——優(yōu)勢(shì)不是那么大，只有極少數(shù)情況下才需要的沒(méi)有必要那么復(fù)雜），但我們卻一如既往地致力于SJR。

這并不意味著JSON數(shù)據(jù)在服務(wù)器端產(chǎn)生和視圖在客戶端形成的模式一無(wú)是處。對(duì)于我們的UI需要很高的保真度的時(shí)候，以及像日歷這樣的，有大量的視圖狀態(tài)需要維護(hù)的時(shí)候，這樣的模式還是非常合適的。當(dāng)需要走這條路的時(shí)候，我們使用Sam的卓越 Eco template system (認(rèn)為ERB對(duì)于CoffeeScript).

如果你的網(wǎng)絡(luò)應(yīng)用都是高保真度的UI，那么走上面提到的那個(gè)路子是完全沒(méi)有問(wèn)題的。只是你正在花費(fèi)高價(jià)給自己購(gòu)買(mǎi)些花哨的東西，不過(guò)這算是個(gè)問(wèn)題。但是如果你的應(yīng)用有點(diǎn)像Basecamp或者Github這樣網(wǎng)絡(luò)上的以文本為基礎(chǔ)的主流應(yīng)用，那么你完全應(yīng)該張開(kāi)雙臂擁抱SJR

 Russian Doll-caching, Turbolinks 和 SJR的融合簡(jiǎn)直就是一杯難以置信的給力雞尾酒。它可以創(chuàng)造出快速的，現(xiàn)代化的，而且非常優(yōu)美的代碼類(lèi)的網(wǎng)絡(luò)應(yīng)用，好好享用吧！

網(wǎng)站標(biāo)題：服務(wù)器端生成的JavaScript響應(yīng)
網(wǎng)頁(yè)地址：http://www.5511xx.com/article/djgshee.html