3

Javascript モジュールを必要とすることができる CommonJS 構造を使用して、BackboneJS アプリケーションで記述する方法を検討しています。このアプリケーションは、ノードを使用してクライアント側またはサーバー側で動作する可能性があります。

私はrequirejsやその他の同様のオプションを調べましたが、私の意見では本当に面倒に見える特定の方法でアプリを作成する必要があります.

また、コードと必要なモジュールを取り、欠落している (必要な) メソッドを含む単一の js ファイルに結合するbrowserifyとwebmakeも調べました。すべてが巧妙なアイデアですが、クライアント側のコードは少し面倒です。

commonJS 形式で記述されたコードを取り、ブラウザーと互換性のあるすべての必要なモジュールをコンパイルし、心配することなくブラウザーで使用できる Javascript ファイル (またはいくつか) を吐き出すことができるようなものはありますか?欠落しているrequireメソッドについて? バックボーン アプリケーションに合わせて調整されたソリューションは、さらに優れています。

4

2 に答える 2

6

ブラウザーで CommonJS 構造化モジュールを使用するには、いくつかのオプションがあります。

  1. RequireJS 2.0.2 は構成オプションをサポートしていますcjsTranslate。これをcjsTranslate: truer.js オプティマイザ構成で に設定すると、CommonJS 形式であると思われる組み込みモジュールがdefineボイラープレートでラップされます。詳細はこちらをご覧ください。
  2. Cajonは、CommonJS 形式のモジュールをサポートする RequireJS の上に構築された新しいモジュール ローダーです (これも RequireJS の作者 @jrburke によって書かれています)。
  3. Volo依存関係管理ツール( @jrburke によるもの) には、cjs モジュールを含めて amd モジュールに変換する機能があります。これはおそらくあなたにとって素晴らしいオプションではありませんが、完全を期すために含める価値があります。
  4. defineAMDボイラープレートでコードを自動的にラップするサーバー コンポーネントを作成できます。これが、 SoundCloudで採用されているアプローチだと思います。このブログ記事を参照してください。

編集 2014 年 8 月 29 日:ここでの現在のベスト プラクティスは、間違いなく、クライアント側のデバッグを容易にするために生成されたソース マップを使用するBrowserifyです。

于 2012-08-01T13:11:09.397 に答える
1

なぜ webmake のようなものがあなたの問題を解決しないのか、私には明らかではありません。

  1. サーバー側モジュールの場合とは異なる方法でクライアント モジュールを作成する必要はありません。

  2. あなたは、webmake/browerify が js をむさぼり食うという懸念を提起します。まあ、何を推測します。RequireJS/Curl も同じことを行います。はい、必ずしもそうとは限りませんが、2012年頃の実際の運用状況では、js を結合してネットワーク経由で送信する前に縮小するための何らかのツールが必要でした。

  3. @rharper によって現在受け入れられている回答の最初の 3 つのポイントは、基本的に AMD ローダー スペースの代替案を示しています。概念としての AMD は明らかに Common JS とは大きく異なり、CJS 仕様書作成者の注意を逃れた非常に有効な懸念事項に対処しています。しかし、現在スクリプトのサイズは画像などのサイズよりも小さいため、これは将来の懸念事項です。スクリプトのサイズがパフォーマンスの問題として顕著になるまでには、ネイティブ ブラウザーをサポートする必要がある ECMA Harmony モジュールを使用することになるでしょう。 . (そして今日でも、モジュールを手動で論理グループに分割し、必要に応じて結合された各グループをロードすることを妨げるものは何もありません。それほど頻繁に必要とされるわけではありません)。

  4. webmake は、@rharper がリストした 4 番目の代替案の (一種の) 実装です。私は browserify よりも webmake を推奨します。なぜなら、webmake は 1 つのことだけを行うことになっていると述べているからです。and メカニズムを介して依存関係が記述された一連のモジュールを作成した後require("foo")、exports.bar = ...最初の JavaScript ファイルを指定してコマンドを実行し、推移的に検出されたすべての依存関係を含む js ファイルを吐き出します。そして、それを使用した私の限られた経験では、それはうまく機能します。最小限のオーバーヘッドで、縮小されていないコードのわずか 75 行がプリアンブルとして追加されます。

  5. 余分なビルドステップが開発中に摩擦を引き起こしている場合は、代わりに、結合された js を動的に再生成し、node.js サーバー (数行のコード) を介して提供することができます。webmake はソースマップもサポートしているため、webkit ブラウザーでのデバッグも機能します。

  6. 私が webmake を提案していることを覚えておいてください。これは、いろいろ探し回った結果、私が見つけた最も簡単な解決策だったからです。しかし、それはあなたのために働くという意味ではありません。この分野に非常に多くの選択肢がある理由は、それぞれに独自の付加機能があり、そのうちのいくつかはユースケースに不可欠である可能性があるためです. しかし、ほとんどの優れた JavaScript ローダーの場合、一般的な原則が適用されます。

    • AMD を使用するか CJS を使用するかに関係なく、AMD ボイラープレートを作成する必要はありません。@rharper は、自動実行をサポートする AMD の代替案をいくつか挙げています。

    • 本番用と開発用の 2 つの異なるパスが必要です。本番の JavaScript は、今日の時点で縮小/結合する必要があります。開発用の JavaScript はそうすべきではなく、保存 (エディタ内)/リロード (ページ)/デバッグ (ブラウザ内) サイクルに余分なステップを追加する必要もありません。

于 2012-08-22T06:30:39.290 に答える