伺服器端產生的 JavaScript 響應

Basecamp中的大多數Ajax操作都是在處理伺服器產生的JavaScript響應SJR）。它的工作原理是這樣的：

這種簡單的模式有一些重要的優勢。

優點#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)首先使用訊息模板

 

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

1) 以Ajax方式提交表單.

 

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

2) 伺服器建立模型對象.

 

  
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) 伺服器產生內嵌入HTML的JavaScript響應.

 

  
<%# renders messages/_message.html.erb %> 
  
$('#messages').prepend('<%=j render @message %>'); 
  
$('#<%= 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的融合簡直就是一杯難以置信的給力雞尾酒。它可以創造出快速的，現代化的，而且非常優美的代碼類的網路應用，好好享用吧！

譯文連結：http://www.oschina.net/translate/server-generated-javascript-responses