10

何百ものコーヒースクリプトファイルを含む大きなRailsアプリがあります。

Coffeescriptファイルに小さな変更を加えたり、ブランチを切り替えたりすると、アセット全体がプリコンパイルされ、ページが読み込まれるまで長時間待たなければならない場合があります。

Started GET "/assets/application.js" for 127.0.0.1 at 2013-01-11 19:39:45 +0100
Compiled sprockets/commonjs.js  (0ms)  (pid 18142)
Compiled jquery.js  (2ms)  (pid 18142)
Compiled jquery_ujs.js  (0ms)  (pid 18142)
Compiled underscore.js  (0ms)  (pid 18142)
Compiled backbone.js  (0ms)  (pid 18142)
Compiled backbone_rails_sync.js  (0ms)  (pid 18142)
Compiled handlebars.runtime.js  (0ms)  (pid 18142)
Compiled moment.js  (0ms)  (pid 18142)
...and so on

次のアセット構成を使用しますconfig/development.rb。

# Do not compress assets
config.assets.compress = false

# Expands the lines which load the assets
config.assets.debug = false

私が設定したとき、私config.assets.debug = falseは何百ものjsファイルをロードするのにかなり長い時間を待たなければなりません。問題は、中庸を見つける方法です。大規模なアプリの開発モードでアセット構成を最適化するにはどうすればよいですか？

4

3 に答える 3

7

Discourseチームのこのミドルウェアを見てください。Rails 4アプリで大きな成功を収めました。開発では、リロード時間が1分から5秒に短縮されました。

于 2013-12-16T19:31:23.673 に答える
2

それは悲しい真実ですが、あなたはそうではありません。これを解決するためのクリーンな方法はありません。

ただし、痛みを最小限に抑えるために従うことができるパターンがいくつかあります。私が正しく理解していれば、変更を確認するために開発で多くの時間を待たなければなりません。

言ったように、これらはここ1とここ2で見られました。

  1. ここから項目2を見てください1 。
  2. アセットを多くのファイルに分割します。これは、変更が発生したときに処理される行が少なくなることを意味します。
  3. css / jsをお勧めします。それほどクールではないかもしれませんが、コンパイルは必要ありません。
  4. アセットのプリコンパイル中に行うべき興味深いことを見つけてください。それは生産性を低下させるかもしれませんが、確かに痛みを殺します。
于 2013-01-19T02:09:51.630 に答える
0

他の人が指摘しているように、アセットを最適化することは、コンパイル速度を上げるための一番の方法です（不要なファイルとプリプロセッサーを排除し、慎重にインポートし、パーシャルを慎重に使用します）。しかし、なぜconfig.assets.debug = falseとにかく開発モードに切り替えているのですか？これがfalseの場合、スプロケットはすべてのファイルを連結します。ファイルの数が多い場合、これにはかなりの時間がかかる可能性があります。

代わりに、を回してconfig.assets.debug = true、アセットが最初のリクエストでコンパイルおよびキャッシュされるようにします。Sprocketsは、Cache-Control HTTPヘッダーを設定して、後続のリクエストでのリクエストのオーバーヘッドを削減します。ブラウザは304（変更なし）の応答を受け取ります。RailsAssetPipelineのドキュメントを参照してください。

于 2013-01-21T03:06:03.453 に答える