BasecampのAjax操作のほとんどは、サーバーが生成したJavaScriptのレスポンスを処理しています。このように動作します：
- フォームは XMLHttpRst ドリブンのフォームで送信されます。
- サーバーはモデルオブジェクトを作成または更新します。
- サーバーはモデルオブジェクトの更新された HTML テンプレートを含む JavaScript レスポンスを生成します。
- クライアントはサーバーから返されたJavaScriptを評価し、DOMを更新します。
このシンプルなモデルには、いくつかの重要な利点があります。
メリット1：パフォーマンスを損なうことなくテンプレートを再利用
テンプレートは、最初のレンダリングにも、その後のテンプレート更新にも再利用できます。Railsを使用している場合、メール/メッセージのような技術には両方のケースで使用される部分があります。
JSON形式でしか情報を返さない場合、その情報を2回表示するテンプレートを使用する必要があります。ただし、シングルサイドのJavaScriptアプリで、アプリの最初のレスポンスがJSON/クライアントサイド生成である場合を除きます。
後者のアプローチは、Javascriptライブラリ全体がロードされ、クライアント上でテンプレートが生成されるまで結果を見ることができないため、時間がかかります。しかし、少なくともいくつかのケースでは合理的な選択肢であり、複数のテンプレートを必要としません。
HTMLテンプレートに埋め込まれたJavaScriptは、JSON形式のレスポンスよりもレスポンスデータ量が多くなる可能性がありますが、この場合、ページを更新するためにクライアントが多くの演算を行う必要はありません。
つまり、エンドツーエンドの観点からは、JavaScript+HTMLのレスポンスデータの処理は、本来クライアント側テンプレートを使用したJSONデータの処理よりも高速であるべきであり、その程度はクライアント側テンプレートの複雑さとクライアント側の計算パフォーマンスに依存します。また、サーバーが生成したテンプレートはキャッシュによって複数のユーザー間で共有できるため、この速度は二重の関係にあるはずです。
SJRを使うことで、実行フローの追跡がとても簡単になります。リクエストメカニズムは標準化されており、"likeform_for @post, remote: true "というヘルパーロジックが付属しています。 もちろん、すべてのアクションにヘルパーロジックを含める必要はありません。 コントローラは、フルビューをレンダリングするのと同じ方法でレスポンスのパーシャルビューをレンダリングします。
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 によって生成されたXMLHttpR されたフォームによって自動的に処理されます。こうしてビューは新しいメッセージで更新され、さらにJS/CSSアニメーションによってハイライトされます。
SJRを使い始めるときは、RJSと呼ばれる前身と一緒に使ってください。RJSでは、Rubyのテンプレートを書いて、それをJavaScriptに変換する必要があります。
今はRJSは使っていませんが、SJRにはこれまで通りコミットしています。
これは、JSONデータがサーバー側で生成され、ビューがクライアント側で形成されるモデルが役に立たないという意味ではありません。UIが非常に忠実である必要がある場合や、カレンダーのように多くのビューの状態を維持する必要がある場合には、良いモデルです。このルートに移行するときは、Sam の優れた Eco テンプレート・システム .
ウェブアプリがすべて忠実度の高いUIであれば、上記のようなルートでもまったく問題ありません。ただ、自分のために派手なものに高いお金を使うのはちょっと問題ですが。しかし、アプリがBasecampやGithubのようなウェブ上のテキストベースの定番のようなものであれば、SJRを両手を広げて受け入れるべきです！
ロシアンドールキャッシュ、Turbolinks、 SJRの融合は、信じられないほどパワフルなカクテルです。高速で、モダンで、とても美しくコーディングされたウェブアプリケーションを作成します！
