Railsには、jsファイルとjs.erbファイルを介してプレゼンテーション層を更新する手段があります。Backbone.jsのようなフレームワークを使用することの具体的な利点は何ですか?
1 に答える
ここにいくつかの理由があります:
1) Backboneは、Railsを念頭に置いて特別に構築されており、backbone-on-railsを使用して簡単に統合できます。KnockoutとAngularのModel-View-ViewModel(MVVM)パターンはRailsアプリに簡単に組み込むことができますが、BackboneのMVCアーキテクチャは、アプリに非同期ページ更新が多数ある場合に本当に必要と思われるレベルの編成を提供します。簡単な例として、このStackOverflowページをご覧ください。
Railsでこの質問ビューを作成している場合は、質問show.html.erb、question_show.js、show.js.erb、およびこのページのコンテンツの非同期更新に関連する他のすべてのjs.erbファイルがあります(賛成/反対投票、賛成、コメントなどのアクション)。
バックボーンでは、ビューはshow.html.erbのようなマークアップテンプレートではなく、そのマークアップリソースに関連するすべてのコードが1か所に含まれています。したがって、リモートのquestion_show.jsファイルですべてのイベントリスナーを定義し、さまざまなjs.erbファイルですべてのAJAX更新を処理する代わりに、質問ショーリソースに関連するすべてのイベントリスニングと公開が1つの場所であるバックボーン質問に含まれますビューを表示します。確かに、コメントには独自のビューがあり、独自のコレクションや、私が言及していない他のMVC要素にコメントすることができます。ただし、バックボーンはフロントエンドリソースの定義に役立ちます。
2) BackboneのようなJavaScriptフレームワークを選択すると、サーバー側で実際に実行する必要のないコードの負荷をサーバーから取り除くことができます。クライアントのブラウザで実行できるのに、サーバー上のhtml.erbテンプレートのすべてのマークアップ要素をレンダリングする理由。セキュリティの質問に答えて、データベースオブジェクトをJSONとしてフォーマットし、それをクライアントに出荷するときに、データベースオブジェクト属性をホワイトリスト/ブラックリストに登録することができます。
3)バックボーン(具体的には)はかなりの自由度を与えるようです。これは、アプリケーションの整理に役立つ一連の規則を提供しますが、結局のところ、開発しているのはフレームワークです。BackboneのMVCフレームワークは、Railsよりも一方向ではありませんが、堅実な規則が維持されています。
4)バックボーン(他のフレームワークに賛成または反対ではない)を使用すると、pushStateはそのユースケースを期待するフレームワークに簡単に実装されます。ただし、pushStateには、コンテンツにアクセスするクローラーに関して欠点があり、サーバー側のレンダリングをクローラーに適した方法で組み込む必要があります。ただし、優れているのは、Backboneをすぐに使用しても同じ履歴/劣化性を実現できることです。それらのURLフラグメントは同じ機能を可能にします、それらはただそこに余分な#を持っています。
バックボーンのようなフレームワークを使用する理由は他にもたくさんありますが、1つのフレームワークがすべてに適合するわけではないため、実際には多くの選択肢があるようです。しかし、私が証明できることとして、アプリを最初から構築している場合、Backboneは優れたフレームワークのようです。また、既存のアプリケーションに組み込みたい場合にも、非常に実行可能と思われます。