JavaScript response generated by the server

Most of the Ajax operations in Basecamp are processing the JavaScript response SJR generated by the server ). It works like this:

This simple mode has some important advantages.

Advantage #1: reusing templates without affecting performance

Whether it is the first rendering or subsequent template update, You can reuse the template. If Rails is used, some technologies like mail/information are used in both cases.

If you only return information in JSON format, you must use your template to display the information twice (one is the first response from the server, and the other is the subsequent update from the client) -Unless you create a JavaScript app with a single page, the app's first response is generated using JSON/client.

The later method will be slow, because you will not be able to see the effect until the entire Javascript library is loaded and a template is generated on the client (this is the method that Twitter used earlier, but is then abandoned ). But in at least some cases this is a reasonable choice and does not require multiple templates.

Advantage #2: The client requires less computing performance

Although JavaScript embedded in HTML templates may cause more response data than responses in JSON format, although it can be ignored after gzip compression), the client does not need to perform many operations to update the page.

This means that from an end-to-end point of view, processing the response data of JavaScript + HTML is faster than processing the JSON data with a client template, depending on the complexity of the client template and the computing performance of the client. In addition, this speed should be double, because the template generated by the server can be shared among multiple users through the cache. For details, see the Russian Doll cache ).

Advantage #3: easy to track execution streams

The use of SJR will make the tracking and execution flow very easy. The request mechanism is standardized, with the auxiliary logic "likeform_for @ post, remote: true". Of course, no auxiliary logic is required for each action. The Controller then renders some views in the response in the form of rendering the complete view, where the target can only be JavaScript rather than the full HTML

Complete example

0) use the message template first.

 
 

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

1) submit the form in Ajax mode.

 
 

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

2) create a model object on the server.

 
 

  
  
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) The server generates JavaScript responses embedded in HTML.

 
 

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

Finally, the evaluation response is automatically processed by the XMLHttpRequest-powered form generated by form_for. The view is updated due to new messages. In addition, new messages are highlighted through JS/CSS animations.

Beyond RJS

When we started using SJR, we used it with a predecessor called RJS. To use RJS, you need to write Ruby templates and then convert them into JavaScript. It is a simplified version of Coffeescript or Opalrb, if you like). It mistakenly makes many people discard the SJR mode.

Now we don't use RJS. The reason for this change is usually very simple-the advantage is not that big, and only a few situations do not need to be so complicated), but we are committed to SJR as always.

This does not mean that the JSON data is generated on the server and the view is formed on the client. This mode is very suitable when we need high fidelity of our UI and a large number of view states like calendar need to be maintained. When this path is needed, we use Sam's superior Eco template system (think ERB for CoffeeScript ).

If all your network applications have a high-fidelity UI, there is no problem following the path mentioned above. It's just that you are spending a high price to buy fancy things for yourself, but this is a problem. However, if your application is a text-based mainstream application such as Basecamp or Github, you should embrace SJR with open arms.

The combination of Russian Doll-caching, Turbolinks, and SJR is an incredible cocktail. It can create fast, modern, and elegant network applications for code classes. Enjoy it!

Http://www.oschina.net/translate/server-generated-javascript-responses.