3

私は大学生の仲間と一緒にRoRプロジェクトに数ヶ月取り組んできました。私はフロントエンドとアセットの部分を担当していますが、Sprocketsを最善の方法で使用する方法を考えていました。

アセットパイプラインを持つことのポイントは、ページの読み込み時間の観点からパフォーマンスを向上させることです。Railsで生成されたアプリのやり方は、すべてのスタイルシートとJavaScriptを2つの圧縮ファイルに入れることです。

しかし、アプリのボリュームと複雑さが増すと、このIMHOは悪い考えになります。これは、オールインワンファイルのサイズが大きくなり、要素を検索して見つからないcssルールまたはスクリプトの重複に問題が生じる可能性があるためです。ページのjavascript部分全体がクラッシュします。

注：チーム間の優れたコーディングルールと規則により、これらの問題の発生を減らすことはできますが、0まで減らすことはできません。

私はこれまでのところこれらの主張に正しいですか？

ポジティブな場合、ページの範囲に役に立たない多くのルールやスクリプトを提供せずに、クライアントに送信するいくつかのアセットの利点を失うことなく、大きなプロジェクトを処理するための良い方法は何ですか？

私の現在のアプローチは、アプリケーションの「コンテキスト領域」ごとに1つずつ、オールインワンファイルのセットを定義することです。だから基本的に私は2+2ファイルを送ろうとします。

しかし、次のようなケースを処理する方法：

それぞれがそれぞれのショーにリンクされているエントリのリストだけを含む、リソースの非常に単純なインデックスビューがあります。代わりに、ショーはまったく単純ではなく、CSS3ルールとjavascriptがたくさんあります。

私のアプローチでは、インデックスアクションには未使用のコードがたくさん含まれます。大きなプロジェクトをどのように処理しますか？

ページが取得するリソースやパフォーマンスをより重要視していますか？

もう1つ気になるのは、パーシャルの処理方法です。オブジェクト指向設計では、各パーシャル（？）には、ロードされるすべての場所で正しく機能するために必要なすべてのインクルードが含まれている必要があります。ただしjavascript_include_tag、ビューとパーシャルの両方で同じアセットを呼び出すと、インクルードが重複することになります。

私のこれらすべての考えは意味をなしますか、それとも私は何かを逃していますか？または、間違った視点から問題を見ている可能性がありますか？リンクやオープンソースプロジェクトを教えていただけますか？その件についてどう思いますか。

長い質問をありがとう、申し訳ありません。

4

1 に答える 1

4

ベストプラクティスから始める（Tier 1コード）：

プリコンパイル済み（縮小/圧縮）され、サーバー圧縮と遠い将来のヘッダーで提供される2つのファイルがあります。ヘッダーの結果として、これらのファイルは最初のリクエストでクライアントブラウザーによってキャッシュされ、その後、キャッシュの有効期限が切れるまで、またはパージされるまで、すべてのページで使用されます。

ファイルは、透過プロキシによってキャッシュされる場合もあります。ISPはこれらを使用して、顧客のネットを高速化します。これにより、リクエストがさらに削減されます。

したがって、パフォーマンスの観点からは、最初のリクエストのみが高額になります。

管理セクション（Tier 2コード）

管理セクションがあるサイトでは、それを別のファイルのペアにスピンオフするのが非常に一般的です。管理者はjquery-uiを使用する可能性がありますが、パブリックサイトは使用しません。その場合、これが最善の妥協案です。すべての公開リクエストに対して、完全に未使用のライブラリを提供する必要はありません。

Railsパイプラインガイドには、これを設定する方法が記載されています。

ページコード（Tier 3）

3番目のレイヤーは、ページ固有のjsおよびcss（あなたの質問）用です。

その場合、パフォーマンス/メンテナンスの面で電話をかける必要があります。コードのビットが多い場合は、これらすべてを分離する必要があり、アセットパイプラインのプリコンパイル配列に追加する必要があります。たくさんあるかコードが小さい場合、これは苦痛です。

これを行う必要がある（または望んでいる）ことは、CSSの全体的な設計を改善できる可能性があることをプログラマーであるあなたに知らせることができます。特定のページに多くのルールを追加する必要がある場合は、CASCADE（CSSのC）を使用していない可能性があります。:-)

オブジェクト指向のCSSは、この問題に対する1つの答えです。弟子として、それはどこでも使用できるCSSの再利用可能なブロックを定義することです。そうすれば、パフォーマンス（すべてのページのルールを含む）またはメンテナンスの観点から、ページ固有のルールの数が少なくても問題は少なくなります。

ページごとに個別のファイルが必要な場合は、これらのファイルのパイプラインのベストプラクティスに従うことで、少なくともファイルのキャッシュ可能性がトレードオフになることはありません。

私のプロジェクトで行っているのは、ビューがメインアプリケーションレイアウトのファイルとコードをスタックできるようにするヘルパーを提供することです。これの利点は、ページの中央ではなく、生成されたコードが表示される場所を制御できることです。これは、ビューの部分にファイルを含めると発生します。（ミッドページファイルにはブロックレンダリングが含まれているため、これはページレンダリングのパフォーマンスに非常に悪いです）

私はこれをします：

application_helper.rb

def deferred_javascript(&block)
  @deferred_javascript ||= []

  if block_given?
    @deferred_javascript << capture(&block)
  end

  @deferred_javascript
end

def deferred_javascript_files
    @javascript_includes ||= []
end

def deferred_css_files
    @stylesheet_includes ||= []
end

そして、ビューで：

<% deferred_javascript_files << 'extras/public_form' %>
<% deferred_css_files << 'extras/public_form' %>

または、ワンライナーの場合は、deferred_javascriptヘルパーでブロックを使用できます。（私はこれをめったに使用しません）。

public_formファイルは、このフォームに必要なもの（jquery-ui、formtastic）のマニフェストであり、他のページでは必要ありません。

注意：このように使用されるファイルはすべて、プリコンパイル配列に追加する必要があります。

config.assets.precompile += ['extras/public_form.css', 'extras/public_form.js']

私のメソッドは開発モードで動作するため、忘れがちですが、本番環境にデプロイすると失敗します。

最後に、アプリケーションレイアウトの、CSSの上部（headタグ内）にあります。

<%= stylesheet_link_tag('application', :media => 'all' ) -%>
<%= stylesheet_link_tag(deferred_css_files) if deferred_css_files.any? %>

JSのレイアウトの下部（終了ボディタグの前）：

<%= javascript_tag do %>
  $(document).ready(function() {
<%= raw deferred_javascript.join("\n") %>
  });
<%- end unless deferred_javascript.blank? -%>
<%= javascript_include_tag 'application' %>  
<%= javascript_include_tag(deferred_javascript_files) if deferred_javascript_files.any? %>

この行は、メインマニフェスト、およびビューマニフェストとコードを追加します。

私が概説したことは、ビューが追加されたファイルがパイプラインの一部であり、メインファイルと同じようにキャッシュされる可能性があることを保証します。

要約する：

すべてをメインマニフェストに配置することは、ほとんどの場合正しいことですが、ページ固有のコードが非常に大きい場合は、別のファイルに移動して、概説したとおりに提供できます。どのアプローチが優れているかについてパフォーマンスコールを行う必要があります。すべてのページに追加のコードを配置したり、1つのページに追加のファイルリクエストを配置したりする必要はありません。

于 2012-05-12T20:00:30.310 に答える