5

わかりました。Rails3.1の新しいアセットパイプラインに関する多くの情報を読みましたが、疑問に対する適切な答えを見つけることができませんでした。

オンデマンドで、レンダリングしていたview＃actionに従って.jsファイルをロードしていました。誤ったバインディングを防ぎ、小さな.jsファイルをロードするためにこれを行っていました。

Candidate_opportunities＃index

$(".sortable_drag_n_drop").sortable({
    update: function(event, ui) {
        $.post('/candidate_opportunities/sort', $(this).sortable('serialize'));
    },
    handle: 'span'
});

Candidate_companies＃index

$(".sortable_drag_n_drop").sortable({
    update: function(event, ui) {
        $.post('/candidate_companies/sort', $(this).sortable('serialize'));
    },
    handle: 'span'
});
$(".sortable_drag_n_drop").disableSelection();

今の最良の解決策は何ですか？

  • バインディングを変更し、Sprocketsにすべての.jsファイルを使用してコンパイルさせる必要があります//= require_tree .か？
  • または、ビューに従って.jsをロード して、巨大なapplication.jsになってしまわないようにする必要があり ますか？
4

2 に答える 2

6

これをパイプラインに更新する場合は、いくつかのオプションがあります。おそらく、パイプラインが機能する方法を考慮して決定する必要があります。

大まかに言えば、彼のパイプラインの目的は、すべてのJSを1つのファイルに結合し、それをminfy/compressすることです。これを行う際のポイントは、ページあたりのリクエスト数を減らし、リソースがブラウザまたは透過プロキシ/キャッシュのどこかにキャッシュされるように、遠い将来のヘッダーを設定できるようにすることです。

オプションに移ります。

1.今と同じです。

あなたが知っているのと同じことをし続けることができます。Railsヘルパーを使用して、これらのビューJSファイルをメインレイアウトファイルに追加していると思います。パイプラインでも同じことを続けることができますが、使用するすべてのファイルをプリコンパイル配列に追加する必要があります。

config.assets.precompile += ['candidate_opportunities.js', 'candidate_companies']

アセットはassets/javascriptsにある必要がありますが、それぞれを個別に追加するため、マニフェストファイルにアセットを追加する必要はありません。

パイプラインのRailsのデフォルトを維持し、本番用にアセットをプリコンパイルすることを強くお勧めします。

欠点は、これらのページでの追加のリクエストですが、これはアプリの負荷が高い場合にのみ問題になります。

2.アセットパイプラインウェイ（TM）

パイプラインでこれを行うには、これらのファイルをassets/javascriptsに移動する必要がありrequire_treeます。

あなたの場合の問題は、JSスニペットが同じクラスをターゲットにしている（ただし、投稿URLが異なる）ため、これが機能しないことです。また、require_treeを使用すると、ファイルの順序が希望どおりにならない場合があります。

新しい3.1アプリはビュー用のファイルを生成しますが（私は思う）、すべてのファイルがapplication.jsに含まれるため、マークアップ内の（サイトの観点から）一意の属性をターゲットにすることが期待されます。

JSの衝突の問題を回避するため。JSスニペットをリファクタリングして、より一般的なものにすることをお勧めします。data-post-urlソート可能なオブジェクトの属性を使用でき ます。

<ul class="sortable_drag_n_drop" data-post-url="/candidate_opportunities/sort">

次に、JSでURLを収集します。

そのDRYerであるだけでなく、全体的なJSが少なく、意図したとおりにパイプラインを完全に使用できます。

于 2011-09-18T21:29:18.777 に答える
0

Railsのアセットパイプラインに不満を感じています。アセットパイプライン全体ではないかもしれませんが、Railsがjavascriptを整理する方法は実際には論理的ではありません。

現在のところ、Railsにはコントローラーごとに個別のjavascriptファイルがあります。これは、論理的な編成の観点からはやや良いです。ただし、アセットパイプラインは、これらすべてのファイルを1つの大きなjsファイルに圧縮します。つまり、基本的にjsファイルは適切に整理されていますが、一度に読み込まれるため、変数の衝突、関数の衝突、その他のコードの衝突、その他の予期しない動作が発生します。開発者として本当に必要なのは、ページ固有のJavaScriptを実行またはロードする簡単な方法だからです。

有名なアプローチの1つは、ページごとに特定のjavascriptファイルを含めることです。はい、それは機能しますが、ページごとに異なるjavascriptファイルを要求している場合、アセットパイプラインによって提供されるパフォーマンスの向上は使用していません。

私の解決策は、すべてのページ固有の関数を保持するjavascriptオブジェクトを作成し、一致するコントローラーとアクションのペアがRailsによって実行されたら、それらをフェッチして実行することです。このようなもの：

PageJs = {};
PageJs["users/new"] = function(){ 
  alert("I will be called when users/new action is executed");
};

基本的に、それがコアアイデアです。さて、私はそのアイデアを実装し、そのための宝石を作成しました。Palomaをチェックアウトし、複雑な設定なしでjsファイルを論理的に整理してページ固有のJavaScriptを実行する方法を確認してください。

パロマの使用例は次のとおりです。

Javascriptファイル：

Paloma.callbacks['users/new'] = function(params){
  // This will only run after executing users/new action
  alert('Hello New Sexy User');
};

Railsコントローラー：

def UsersController < ApplicationController
  def new
    @user = User.new
    # No special function to call, 
    # the javascript callback will be executed automatically
  end
end

これは簡単な例ですが、提供できるものは他にもたくさんあり、問題を解決できると確信しています。簡単に。

ありがとう！

于 2012-12-22T02:38:52.570 に答える