0

ExtJS 3.xに基づくフロントエンドを使用して、レガシー Web アプリケーションをモダナイズしています。

現在、ユーザー インターフェイスは数千行の大きなファイルに依存しており、ネストされた無名関数が多すぎて、ファイルごとにグローバルな `Ext.onReady()̀ にカプセル化されています。それは醜く、読みにくく、保守できません。

コードを維持して最新化するために、次のように徐々にリファクタリングしたいと考えています。

  1. 名前空間の使用
  2. 大きなファイルの分解:ファイルごとに 1 つのクラス(グリッド、ストア、フォーム ...)
  3. 適切なディレクトリ構造(app/module/grid|store|...)にクラス ファイルを整理する
  4. 必要に応じてクラスファイルを動的にロードします (おそらく Ext.Loader.load() を使用しますか?)
  5. 可能であれば、アセットとして minifierを使用して読み込みを最適化します (次のステップで)。

これらの問題はすべて ExtJS 4でネイティブに解決されているようで、そのクラス Loader、依存関係システム ( require)、ApplicationSingleton、および構造フォルダーの規則...

ExtJS 3 では、もっと混乱しているようです。そう ：

  • extjs 4 のようにコードを整理するための extjs 3 のベストプラクティスは何ですか?
  • これらの問題を説明する明確な例はありますか?
4

1 に答える 1

1

Ext3 は 4 とはまったく別物です。コードの編成は開発者次第です。私は個人的に、アプリ全体の縮小化を優先して動的読み込みを避けます。これは、本番アプリで ext4 が提供するものです。実際には、デバッグ目的での動的ロードのみを意図しています。以前 Ext3 で動的ローディング/モジュール ルートを使用したことがありますが、それは残念でした。クラスシステムに組み込まれているので4つでOKです。

  1. 3 以降のバージョンを使用している場合は、Ext.define で名前空間を作成してください。内部で Ext.ns を実行し、4 へのアップグレードを容易にします。

  2. 大きなファイルや構成オブジェクトを持つべきではないことは正しいですが、やりすぎないようにしてください。物事を論理クラスにグループ化してみてください。グリッドは、ビューとして意味のある他のコンポーネントを含むクラスの一部にすることができます。

  3. 後で 4 にアップグレードする場合は、少なくともストアとビューで構造を少しエミュレートすることをお勧めします。3は実際には構造を課していません。

  4. 3 での動的ロードは避けます。上記を参照してください。

  5. 必ず縮小します。ネットワーク経由で送信されるデータが大幅に減少するだけでなく、スクリプトごとに GET のオーバーヘッドをすべて取り除くことで、大幅な節約が得られます。Gzipも少し役立つかもしれません。

于 2013-10-05T04:37:00.360 に答える