asset pipelineとは何ですか?
Railsアプリケーションを構築している場合は、おそらくasset pipelineについて聞いたことがあります。 アセットパイプラインは、Javascriptファイル、スタイルシート、および画像が処理され、ブラウザで使用するために準備されるツールとメカニズムと考えることが これらのプロセスは、CoffeescriptやSassなどの他の言語で記述されたプリプロセスアセットと同様に、アセットを縮小および圧縮できます。
資産パイプラインは、静的資産に関連するさまざまな問題を解決するために作成されました。 そのような問題の1つは、HTMLマークアップで個別に指定された各アセットを個別に取得する必要があるため、HTTP要求の数が多くなり、最終的にはロード時間が長くなることです。 生のJavascriptとCSSファイルは、コメント、余分な空白、長い変数名で多くの帯域幅を無駄にすることもあります。 出てくる別の問題には、キャッシュが含まれます。 たとえば、サーバーからJavascriptファイルを提供すると、ブラウザはそのファイルを一定期間自動的にキャッシュします。 これにより、ページの読み込み時間が改善されますが、そのアセットが後で変更された場合はどうなりますか? ブラウザはそれについて知らないので、キャッシュの有効期限が切れるまでキャッシュされたアセットを使用し続けます。 最後に、Coffeescript、Sass、Less、Erbなどの言語は、JavascriptとCSSを整理して書くことを容易にしましたが、ブラウザはそれらを直接解釈することができないため、ブラウザに送信される前にそれらのファイルを適切な対応するファイルに変換するためのプリプロセッサが必要です。
資産パイプラインは、その慈悲の中で、適切に使用されると、上記の問題のすべてを解決することができます。 複数のアセットを1つにコンパイルし、アセットを縮小および圧縮し、キャッシュの問題を回避するためのアセットの消化を提供し、代替言語を前処理してJavascriptおよびCSSに変換することができます。
この記事は、資産パイプラインに関連するさまざまなトピックをカバーしています:
- アセットパイプラインの使用方法の基本
- アセットパイプラインによって処理されるファイルを指定するためのプリコンパイル配列の使用方法
- SassとCoffeescriptを活用する方法
- Railsアセットヘルパーメソッドの使用方法、および
- いくつかの落とし穴
基本的な使用法
資産パイプラインを使用する基本的な方法は二つあります:
- 開発モードでサーバーを実行すると、自動的に前処理され、その場でアセットが準備されます。
- プロダクションモードでは、アセットの前処理、バージョン化、圧縮、コンパイルに使用することができます。 これを行うには、次のコマンドを実行します:
1 |
|
これにより、(デフォルトで)assets
ディレクトリがpublic/
フォルダに作成されます。 その後、適切な形式で、新しい消化されたバージョンで、そのディレクトリにすべての圧縮され、コンパイルされたファイルを追加します。 これらのファイルを直接サーバーにするようにNginxまたはApacheを設定して、Railsがそれらを配信する必要がないようにすることができます(そして、オンザフ)自体。
デフォルトは変更できるので、期待どおりに動作しない場合は、config/application.rb
のアプリケーション設定ファイルを確認してください。 Rails4では、資産処理は通常config/initializers/assets.rb
で構成されています。
ファイル構造
資産パイプラインの既存の機能を容易にし、理解できる方法で資産を整理することが重要です。 最初に知っておくべきことは、カスタムJavascript、スタイルシート、および画像のすべてがapp/assets/
ディレクトリに入ることです。 デフォルトでは、javascripts
、stylesheets
、およびimages
の各フォルダがあります。 これらの種類のアセットのfonts
、audios
、およびvideos
をapp/assets/
ディレクトリに追加することもできます。 使用しているすべてのサードパーティのコード(例:jQuery、backbone。jsなど)はvendor/assets/
ディレクトリに配置する必要があります:
1234567891011 |
|
webサーバーはpublic/
ディレクトリから静的ファイルを自動的にサーバーするので、すべてのJavascript、image、およびstylesheetアセットをそこに配置すべきではないのはなぜですか? 一つは、public
フォルダ内の何も自動的に事前処理、コンパイル、または圧縮されませんので、そこに資産を置くことによって、あなたは完全にアセットパイ アセットをそこに配置すると、Railsコード内でそれらを簡単に参照することもできなくなります。 たとえば、次のコードを持つビューを持つことができます:
12345678910 |
|
第二のシナリオ(public/images/logo.png
)では、サイトがベースディレクトリから配信されている場合にのみ動作します。 また、アセットパイプラインのファイルのバージョン管理を利用することもできません。
プリコンパイル
app/assets/javascripts/
フォルダに入れたものがすべて自動的にアプリのプリコンパイルされるかどうか疑問に思うかもしれません。 幸いなことに、アセットパイプラインは、どのファイルをコンパイルするか、どの順序でコンパイルするかを指定する方法を提供します。 デフォルトでは、アプリケーション。cssとアプリケーション。js(またはそれらのsass/coffeescriptに相当するもの)と、すべての非Javascript、非CSSアセットが含まれています。 アプリケーション以外のCSSまたはJavascriptファイルを含める。cssとアプリケーション。jsでは、次の2つの方法のいずれかでそれを必要とする必要があります:
- これを
config/initializers/assets.rb
(Rails4)またはアプリケーション設定ファイル(config/application.rb
など)のプリコンパイル配列に追加するか、 - アセットのマニフェストまたはそのサブファイルのマニ
最初のオプションは次のようになります:
12 |
|
このオプションは、特定のページにのみ含めることが理にかなっており、他のページに含めるべきではないファイルに最適です。 たとえば、iframe埋め込みウィジェットとして使用されるサイトの一部がある場合は、そのページでwidget.js
とwidget.css
などのようなものだけを使用することができます。 これらのファイルは、上記のようにプリコンパイル配列に追加する必要があります。
第二のオプションは、ほとんどの時間を使用する必要があり、あなたのJavascriptとCSSファイルを一つのアプリケーションにコンパイルすることができます。jsと一つのアプリケーション。cssファイル。 マニフェストは、該当する資産の上部に書かれています。
coffeescriptでは、次のようになります:
12345 |
|
上記のマニフェストには、jQuery、Rails jQuery unobtrusive scripting adapter(jquery_ujs)、および現在のツリー内のすべてのファイル(つまりapp/assets/javascript/*
)が含まれます。 require_tree
はディレクトリを介してアセットを再帰的にコンパイルしないことに注意してください。 含めるファイルのフォルダがある場合は、それをマニフェストにも追加する必要があります:
1 |
|
もう一つのマニフェストディレクティブはrequire_self
で、チェーン内のその時点で現在のファイルのJavascriptを含めるために使用されます。 上記のrequire_self
は、次のように.js
ファイルに書き込むことができます:
1234567 |
|
sass/CSSマニフェストは、同じ基本的な形式を使用しますが、適切なコメントスタイルを使用します:
123456 |
|
sassを使用する場合、マニフェストによってコンパイルされた各ファイルには独自のスコープがあるため、変数とmixinを利用するには@import
ルールを使用する必
require_tree
ディレクティブの使用に注意してください。 つまり、”a”で始まるファイルが”z”で始まるファイルに依存している場合、Javascriptがブラウザによって評価されたときに必要な部分が利用できないという問 この問題は、適切なjQuery(document).ready()
またはwindow.onload
ガードを使用したり、手動で順序を指定したり、ファイルの前に01_
、02_
などの番号を付けることで回避できます:
12345 |
|
プリコンパイルされたJavascriptまたはCSSファイルには、一番上にマニフェストを含めることができるので、サブフォルダのファイルを使用して最上位マニ
SassとCoffescript、およびRails Asset Helpers
上記のセクションでSassとCoffeescriptについて少し言及しましたが、まだそれらが何であるかについては触れていません。 すでにそれらに精通している場合は、”Rails Asset Helpers”セクションにスキップしてください。
sassとCoffeescript
sassとCoffeescriptは、それぞれの構文をCSSとJavascriptに変換するためにプリプロセッサを使用する言語です。 TypescriptやLessなどの前処理された言語は他にもいくつかありますが、SassとCoffeescriptはデフォルトでRailsに含まれており、おそらく最も人気があります。 私はこれらの言語についてここで詳細には触れませんので、詳細については上記のリンクをチェックしてください。
私の経験から、SassとCoffeescriptは多くの構文糖(きれいなコード機能)を提供していますが、前処理段階で無効なコードに対して例外がスローされるという事実は、そ Coffeescriptはファイルごとにコードを自動的にラップし、var
キーワードをローカル変数に追加するため、バニラJavascriptでより簡単に発生する可能性のあるスコープの頭痛を防
たとえば、次のCoffeescriptコード:
12345 |
|
次のJavascriptに変換されます:
1234567891011 |
|
プリプロセッサがファイルを処理すると、コードは自動的に無名関数((function() {}).call(this)
)でラップされ、var
キーワードがstate
の最初の使用法に追加されます。 グローバルスコープを使用する場合は、window.
という接頭辞を付けて指定する必要があることに注意してください。
Coffeescriptにはさらに多くのことがありますが、自動スコープは、見つけにくいバグを防ぐために個人的に非常に役立ちました。
Rails Asset Helpers
RailsプロジェクトでSassを使用することによってのみ得ることができるもう一つの優れた機能は、asset path helpersです。 Sass内の他のアセットを参照する場合は、次の構文を使用して適切なパスを取得できます:
123 |
|
ヘルパーimage-path
、asset-url
、およびasset-path
も使用できます。 -url
ヘルパーはパスをurl()
でラップします。
Erb in Assets
アセットパイプラインを使用すると、CSSおよびJavascriptアセットのerbコードをファイル名の末尾に付けることで評価できます。erb(例:application.js.erb
またはapplication.scss.erb
)。 これはjavascriptにアセットパスを追加するのに役立ちますが、全体的にこの機能を使用することはお勧めしません。 ファイルに別の前処理ステップが追加されるため、プリコンパイルにかかる時間が長くなります。 また、悪い習慣につながることができます。 文字列の翻訳のように、コンパイル時に意味をなさないコードを追加したくなるかもしれません。 これらの文字列はコンパイル時にのみ翻訳されるため、翻訳の目的全体が無効になります。 JavascriptファイルでErbを使用する唯一の理由は、ガイドで説明されているようにasset_path
ヘルパーを使用することです。
Asset Pipeline Gotchas
以下は、Railsアプリケーションのアセットを開発するのに役立ついくつかのgotchasとtidbitsです。
- 使用するJavascriptのグローバルデータを追加するにはどうすればよいですか?
- gon gemは、Javascriptが消費するページにグローバルスコープのデータを挿入するために使用できます。 これは、現在のユーザーのIDやサイト設定を提供するなどの場合に最適です。
- プリコンパイル配列をどこで拡張する必要がありますか?Rails4では
config/initializers/assets.rb
で配列を拡張し、Rails3ではconfig/application.rb
で配列を拡張する必要があります。 資産を使用します。rbまたはアプリケーション。rbは、環境を追加する場合(おそらくstaging
)、その新しい環境のために特別にプリコンパイル配列を拡張する必要がないように、すべての環境に対してプリコンパイル配列を設定します。- rb:
Rails.application.config.assets.precompile += %w( widget.css widget.js )
- アプリケーション。rb:
config.assets.precompile += %w( widget.js widget.css )
- rb:
- これはめったに行われるべきではありません。 ほとんどの場合、これを行う唯一の理由は、iframe埋め込みウィジェットなど、アセットの残りの部分を必要としない特別ページにアセットが単独で含まれている場合です。 アプリケーションを使用します。jsとアプリケーション。cssは、あなたの資産を引き出すためにマニフェストします。
- はい。 これは、Twelve-Factorアプリのガイドラインに従い、プリコンパイル配列にファイルを含めるのを忘れた場合やプリコンパイルを忘れた場合のエラーを防
- はRails3に
config.serve_static_assets = true
、Rails4にconfig.serve_static_files = true
を設定します。
- 高品質のJavascriptとCSS(またはCoffeescriptとSass)を書くには多くの時間と経験が必要ですが、私を大きく助けてくれたことの一つはlinterを使用しています)。 Sublime TextのようないくつかのIdeには、linterを統合するプラグインがあります。 私は個人的にSublimeLinterパッケージを使用します。 普通のJavascriptとCSSを書くつもりなら、間違いなくlinterを使用する必要があります。
-
config.asset.prefix
設定を/static
などの別のディレクトリに変更することができます。 - 本番環境で使用するためにgitでプリコンパイルされたアセットを追跡する場合は、
development.rb
のアセット接頭辞を変更します。 - コントローラに
/assets
path名前空間を使用する場合は、assetプレフィックスをグローバルに変更します。
- 基本的なnginxディレクティブは次のようになります(詳細については、RailsガイドのPrecompiling Assetsセクションを参照してください):
1234567 |
|
- マニフェストとは何か。ymlまたはマニフェスト-。json?
- マニフェスト。yml(Rails3)またはmanifest-.json(Rails4)ファイルは、
rake assets:precompile
でアセットをプリコンパイルすると自動的に作成されます。 アプリで使用されるファイルに関する情報が含まれています。
- マニフェスト。yml(Rails3)またはmanifest-.json(Rails4)ファイルは、
- アセットパイプラインに含めるべきではないファイルの種類は何ですか?
- 通常は大きなファイル(ビデオ、大量のPDFダウンロードなど)を保持したいと思うでしょう。)別のリポジトリまたはAWS S3などのクラウドファイルマネージャにあります。 ファイルはアプリから参照できますが、gitリポジトリを沼地にする必要はありません。
- Rails3assetsをより速くコンパイルするにはどうすればよいですか?
-
turbo-sprockets-rails3
宝石を使用してください。
-
- アセットにCDN(コンテンツ配信ネットワーク)を使用できますか?
- はい! 各資産にサフィックスされたダイジェスト、または指紋は、それらがCdnで素晴らしい仕事になります。 RAILSアプリからアセットを提供するようにCDNを設定し、
config.action_controller.asset_host
設定をCDNに適切なドメイン(例:config.action_controller.asset_host = 'mycdn.fictional-cdn.com'
)に設定します。 これを設定するには、環境変数を使用することをお勧めします:config.action_controller.asset_host = ENV
。
- はい! 各資産にサフィックスされたダイジェスト、または指紋は、それらがCdnで素晴らしい仕事になります。 RAILSアプリからアセットを提供するようにCDNを設定し、
をラップアップすると、アセットパイプラインを適切に使用することで、パフォーマンス、回復力、コードの清浄性の点でアプリケーションの全体的な質 アセットパイプラインの機能を使用することで、静的アセットのコーディングと配信に関連する最大の問題のいくつかを自動的に克服できます。