7

次のGoogle Apps Office ビデオを見て、 browserify を使用してノードの CommonJS パッケージング システムを使用して JS を 1 つのファイルにパッケージ化する方法を学びました。ブラウザに移植された多くのノード ライブラリも追加され、CoffeeScript を処理できるため、このアイデアが気に入っています。

このビデオで取り上げられていないことの 1 つは、複数のビューを持つ Chrome アプリで引き続き browserify をDRYの方法で使用する方法です。説明させてください。通常、browserify コマンドは (モジュールとして設計された) 一連の JS ファイルを取得し、それをいくつかのパッケージ シュガーを使用して 1 つの JS ファイルに連結します。これは、コンテンツ ページ、背景ページ、またはポップアップ ページなどからその JS ファイルを参照するのに最適です。ただし、バックグラウンド ページとポップアップ ページには、それぞれに同じコンパイル済みの JS ファイルを含めますか? これにより、クロムがスクリプトを 2 回 (2 回) ロードすることはありませんか? もしそうなら、必要な部分だけを得るためにすべてを解釈するのは無駄なことのように思えます。または、require()/exports モーダルは、特定のコンテキストで必要のないモジュールの不要な解釈を防いでいますか?

これがベスト プラクティスではない場合、各ページが必要なモジュールをドライな方法で取得する方法でモジュールを 1 つパッケージ化する必要があります。他の人はこのトピックにどのようにアプローチしましたか?

4

4 に答える 4

9

私がうまく機能することがわかったテクニックは、各コンテキスト (背景、コンテンツなど) ごとに個別のバンドルを作成することです。ディレクトリ構造の例を次に示します。

.
├── extension
│   ├── js
│   └── manifest.json
├── lib
│   ├── background
│   │   └── index.js
│   ├── content
│   │   └── index.js
│   └── frame
│       ├── index.js
│       ├── models
│       │   └── ...
│       └── views
│           └── ...
└── package.json

ディレクトリ内に、エントリ ポイントとしてlib各コンテキストのフォルダを作成します。index.jsこのファイルは、その特定のコンテキストのアプリケーションをブートストラップし、requireモジュールに関係なく、アプリのその部分を初期化します。

次に、browserifyまたはwatchifyを使用してバンドルを作成します./extension/js/。

$ browserify ./lib/background/index.js -o ./extension/js/background.js
$ browserify ./lib/content/index.js -o ./extension/js/content.js
$ browserify ./lib/frame/index.js -o ./extension/js/frame.js

同じモジュールをたとえば と で再利用する場合はbackground.js、各コンテキストでそれを再利用するcontent.jsだけrequire()で、browserify はそれに応じてバンドルを構築します。

このプロセスは、Gruntfile.jsまたはカスタム npm スクリプトを使用して合理化できます。

このアプローチの実例をこちらで試すことができます。

于 2013-08-31T22:45:30.587 に答える
4

複数のエントリページと1つのモノリシックJSスクリプトの場合、background.htmlまたはバックグラウンドスクリプトが必要な関数/オブジェクトをグローバル（読み取りウィンドウ）コンテキストに公開するようにJSロジックをカプセル化するというアイデアがあります。次に、オプションやポップアップなどの他のエントリページで、これを使用してバックグラウンドページのグローバルコンテキストにアクセスします。

Application = chrome.extension.getBackgroundPage().myGlobalFunction();

このSOの質問は、レイアウトと相互作用についての洞察を提供します。

これにより、browserifyの1つのバージョンでJSを作成しながら、同じ拡張子の他のページで通信/実行できるようになります。

于 2013-03-08T12:08:40.080 に答える
2

Browserify のようなライブラリは通常、「単一ページ Web アプリケーション」をサポートするように設計されています。つまり、通常、アプリケーションに含まれる HTML ファイルは 1 つだけ (通常は public/index.html) であり、ハード依存関係 (browserify の連結された出力など) をロードするエントリ ポイントとして機能します。それ以外はすべて Javascript と、選択したフロントエンド フレームワーク (つまり、Backbone、SpineJS など) によって管理されます。

単一ページの Web アプリにはデータの複数の「画面」が含まれる場合がありますが、これらのページの実際の HTML は通常、html のフラグメント (多くの場合、Handlebars、Moustache、ECO などの javascript テンプレート ミドルウェアを使用) であり、AJAX を介してロードされ、ページの本文に挿入されます。つまり、これらの新しいページ フラグメントは、このページに以前にロードされた JavaScript にすでにアクセスできます。

したがって、ページが1つしかないため、SPAでDRYになっているため、JSインポートを繰り返すことはありません。

UI の大部分がサーバー側の言語によってレンダリングされるフルスタックの Web 開発にこれまで慣れていた場合、単一ページの Web アプリケーションのアイデアは少しショックを受ける可能性があります。ほとんどの SPA はサーバー側のコンポーネントを持つ傾向がありますが、これは通常、データ エンドポイント (AJAX 呼び出しがヒットする) と永続性を提供する RESTful API に縮小されます。

于 2013-03-07T08:50:27.933 に答える