scriptタグで読み込むファイルとデプロイについて

Twitterの僕のタイムラインでは、Loader使っている場合にちょいと遅いぞとか、 Loader使う時には、どのjsファイルを読み込めばいいんだ？とか いろいろ話が出てます。 ですので、そのあたりのことと、デプロイの際にはどんなことをやるのかをまとめてみました。

scriptタグで読み込むファイルはどれ

ここらあたりのことは、オフィシャルブログの Using Ext.Loader for Your Application に書いてあります。このサイトに翻訳があります。

アプリケーションでExt.Loaderを使う

ext-all-debug-w.comments.js
フレームワーク全体のデバッグバージョン、コメント付きです。
ext-all-debug.js
上記と同じですが、コメントがありません。
ext-all.js
フレームワーク全体が連結・ミニファイされています。
ext-debug.js
このファイルはExt JS の基本部分だけが入っています。
ext.js
ext-debug.js のミニファイバージョン。

allがついているとフレームワーク全体。debugがついているとミニファイされていない。というルールになっています。 Ext.Loaderはとても賢くて、ロードしようとするクラス定義がすでに読み込まれていたらなにもせず、 読み込まれていなければ、必要なjsファイルを読みに行きます。

ですから、ext-debug.jsを読み込んでいたら、必要になったjsファイルを、src以下のフォルダから読み込むので、 数百というオーダーのリクエストが発生します。 そのかわりクラス毎にソースファイルが分かれているので、デバッグで後追いするときにわかりやすくなります。

ext-all-debug.jsを読み込んでいたら、フレームワーク全体が読み込まれていますから、 Ext JS内のクラスが必要になった時にロードされることはありません。 読み込み時のリクエスト数が劇的に減ります。数百がext-all-debug.js一本になりますから。 ただしExt JS 4の時みたいに、何万行もあるソースの中から目的のクラスの場所を探さなければならなくなります。

実験したらわかりますが、ローディングにかかる時間はものすごい差があります。 デバッグの場面によってどちらを使うかを切り替えるといいんでしょうね。

次にミニファイ版ですが、ext-all.jsはExt JS 4のフレームワーク全体を読み込みますから、 本番環境ではこれをつかうのだろうなと想像できます。 では、ext.js ファイルはなんのためにあるのでしょう。 ext.jsは基本部分しか入っていませんから、他の部分はLoaderを使ってロードするしかありません。 しかし、前述したようにExt.Loaderを使ったプログラムはリクエスト数がはんぱないので、本番環境ではとても使えません。

このファイルは実は、デプロイ作業時にSenchaコマンドによって作られたファイルと一緒に使うのです。

デプロイ

次にLoader使ったプログラムを最終的にデプロイするにはどうすりゃいいんだ？ というあたりを書いてみたいと思います。 オフィシャルドキュメントの Getting Started に話が書いてあります。中途半端な訳がこのサイトにあります。

Getting Started

Ext.Loaderを使ってプログラムを書いていると、とくにMVCアーキテクチャで、 構造化されたディレクトリ構造の中に必要なファイルを配置して、わかりやすくプログラムを作成できて本当に便利です。 ですが、アプリケーションの規模が大きくなってきたら、当然、読み込むファイル数も増えてきます。 そうするとやっぱりロードが遅くなるのは自明です。 やっぱり、JavaScriptのコードをミニファイ・マージする必要があります。

Senchaコマンドは、自分が作ったアプリケーションのJavaScriptファイルをミニファイ・マージしてくれます。 しかも、その時にExt JS 4フレームワークの中の必要なファイルもマージしてくれて、 Ext JS + 自前のアプリがセットされた、app-all.js というファイルを作ってくれるのです。

手順としては、sencha create jsb で jsb3 ファイルを作成し、shencha build でミニファイ・マージする、 という流れになります。早速、Getting Started のとおりやってみると、

[bash] $ sencha create jsb -a index.html -p app.jsb3 undefined:0 TypeError: ‘null’ is not a constructor [/bash]

動かないのかよ(´･ω･`)

本家のフォーラムを読んでいたら、書いてあった

Deployment Error with Sensha SDK Tool – ‘null’ is not a constructor

というわけで、http://〜で指定してみる。

[bash] $ sencha create jsb -a http://localhost/~ext4direct/index.html -p app.jsb3 [/bash]

無事終了。これで 次にビルドします。

[bash] $ sencha build -c -p app.jsb3 -d . Loading the Project Name Project Loaded 0 Packages Loaded 2 Builds * Parse all-classes.js with options: – debug: true – debugLevel: 1 * Parse app-all.js with options: – debug: false – debugLevel: 1 Copy resources… Done building! [/bash]

-c オプションは、”Don’t compress the targets” です。 現在のバージョンで試したところ、ミニファイまでやると日本語の一部で不具合が出ます。 ですからこのオプションをつけています。 ここで2つのファイルが作成されます。

app-all.js と all-classes.js です。

app-all.js は本来ですとミニファイされるのですが、-c をつけて作成しているので、ミニファイされていません。 Getting Started によると、この二つの差はミニファイしているかどうかの違いだと書いていますので、同じファイルのはずですが、 ファイルのサイズが違っています。 実は、ミニファイの有無いがいにもちょっとだけ違いがありました。 app-all.jsには、app.jsの内容が含まれるのに対し、all-classes.jsにはapp.jsの内容は含まれません。

次にこの app-all.js をGoogle Closure Compiler でミニファイします。

[bash] $ mv app-all.js app-all-debug.js $ java -jar ~/bin/compiler.jar –compilation_level WHITESPACE_ONLY –js app-all-debug.js –js_output_file app-all.js [/bash]

もとのapp-all.js をapp-all-debug.jsとリネームした後にミニファイしました。 –compilation_level WHITESPACE_ONLY を指定しているのは、そうしないとエラーがでたからです。 こうして、アプリケーションのミニファイ・マージしたJavaScriptファイルができました。 index.html を変更します。

app-all.js に必要なファイルがすべて含まれるのであれば、ロードされるJavaScriptファイルは、わずか2つ (ext.jsとapp-all.jsだけ)になります。

が、やってみると、ちょっと漏れがあるようで、いくつかのファイルがマージされていませんでした。 (でも Ext.Loader が働くのでちゃんと実行は出来ます) まだ、Senchaコマンドの動きは完璧ではないのでしょうか、それとも僕の作り方がまずいのでしょうか。

Senchaコマンドが完璧になってくれれば、デプロイは相当に楽になりそうです。 現在の状況でも、うまく付き合えばそこそこには便利ですね。

1 thought on “scriptタグで読み込むファイルとデプロイについて”

  1. ピンバック: addProvider呼び出しとデプロイ | Sunvisor Lab. Ext JS 別館

コメントは停止中です。