6

私は現在、JavaScriptの名前空間についてこの議論に直面しており、コミュニティの意見が必要です。

シナリオ： このプロジェクトを担当するアーキテクトは、どういうわけかRequireJSに専念しており、実際にそれを使用したいと考えています。

アプリケーションはバックオフィスであり、ウィザードとしてレイアウトされていると言わなければなりません。そのため、複雑なビジネスロジックを使用して、6ページを行ったり来たりして、最後にプロセスリクエストとして説明できるものを入力します。

わかりました。シングルページアプリケーションはありません。これらの問題については何も派手ではありません。プレーンなバックオフィスWebアプリ、マルチページ、非常に複雑なUIを備え、すべてのページがサーバーに要求され、すべてのリソース（css、javascriptなど）がページの読み込み時に読み込まれる必要があります。

主な質問：私たちが話しているアプリの種類を知っているのに、そもそもなぜRequireJSなのか？

2番目の質問： javacriptでの名前空間の最良のアプローチは、RequireJSを使用することであると納得させようとするのはなぜですか？私は何かが足りないのですか？

私の意見： 私にとって、それはまったく意味がありません。ここでRequireJSを使用するのは面倒です。リソースはオンデマンドで読み込まれず、すべてページの読み込み時に読み込まれるためです（ページの読み込み時にすべてが必要なため）。少なくともIE8、Chrome、Firefox、Operaをサポートする必要があり、これらすべてのブラウザでのリソースの読み込みにすでに多くの問題がありました。Requireを介してすべてが期待どおりにロードされるようにするためのトリックはすでにたくさんあります。

名前空間の場合、それはさらに悪いことです。確かにそれは機能しますが、繰り返しになりますが、私には面倒に思えます。この問題に関しては、実際には非常に限られています。

だから私は何かが欠けていますか？ここで3番目（または100番目）の意見が必要です。

  • これについてどう思いますか？
  • あなたは何を使うのですか？
  • なんで？

前もって感謝します

4

4 に答える 4

4

AMD ローダー (RequireJS がその 1 つ) は、さまざまな問題に対処します。

  • 適切なモジュール化、関心の分離
  • 地球規模の汚染なし
  • 名前の衝突はありません
  • オンデマンドの読み込み、または展開前の最適化
  • ローダーによっては、ローカライズされたリソースやロード時のコンパイルなどの高度な問題に対処するためのプラグイン

私はそのようなローダーの大ファンであり、非常に小さな単一ページのアプリを除いて、すべてに役立つと思います。

于 2012-12-17T20:42:47.307 に答える
3

「シングルページアプリ」であるかどうかに関係なく、RequireJSは、クライアント側のJavaScriptを開発する際に、開発者の多くの規律がなければ簡単ではない2つのことを支援します。

本番環境と開発環境

JavaScriptアプリケーションを、アプリケーションのさまざまな部分に論理的に似たファイルに分割することは、今では常識です。デバッグと保守が簡単です。ただし、本番環境では、圧縮されていないファイルを多数出荷するとパフォーマンスが低下します。したがって、すべてのファイルを1つのファイルに連結し、それを縮小して（たとえば、Googleクロージャーコンパイラを使用して）、単一のgzipファイルとして出荷します。コマンドラインツールを使用してこれを行うにはさまざまな方法がありますが（GruntJSを使用するなど）、RequireJSのようなスクリプトローダーがない場合は、2つの異なるユースケース（すべての開発ファイルをスクリプトタグまたは単一の本番環境として参照する）用にページを設定する必要があります.js）自分自身。RequireJSには、これらすべてを実行するNodeJSビルドツールがあります。

モジュール化

これで、コードを別々のファイルに保存するのはすべて良いことです。しかし、JavaScriptの性質とすべてがグローバルであるため、名前の衝突などの奇妙なことに遭遇する可能性があります。これは、名前空間が役立つところです。しかし、さらに良い代替策は、すべてを独自の関数にラップすることです（独自のスコープを導入します）。これが、ほとんどのJavaScriptコードが自己実行型の無名関数で提供される理由です。この関数がAPIを返す場合、Webモジュールがあることを公開したいと考えています。モジュールAPIをアプリケーションとは別にテストして、他の場所で再利用できます。

RequireJSドキュメントの「 WhyWebModules」セクションも読んでください。

于 2012-12-17T20:44:34.763 に答える
2

私の個人的な意見では、javascriptモジュールシステムの使用は決して悪い考えではありません。Requirejsは、javascriptモジュールの唯一の可能なローダーではありません（おそらく最も人気のあるローダーです）。いくつかの選択肢はLABjsまたはHeadJSです。

これらのローダーは多くの場合使いやすいですが（最初はそれほど問題はありません）、プロジェクトがどんどん大きくなっているときに大いに役立ちます。グローバル空間での名前の競合を回避し、モジュールを最小化/最適化することで展開ステップをサポートすることもできます。最も重要な事実は、よりモジュール化されたjavascriptコードを記述できることです。

  • あなたはいくつかの効用関数を持っていますか？ユーティリティモジュールを作成するだけです。
  • すべてのページに必要な機能がいくつかありますか？それらを共通のモジュールに入れます。
  • いくつかのページは多くの特定のjavascriptコードを必要としますか？これらのページ用に追加のモジュールを作成して、他のページにこのコードをロードする必要がないようにします。
于 2012-12-17T20:44:10.800 に答える
0

地球環境の汚染と名前の衝突を防ぐための私の現在の解決策は、を使用すること$.extendです。

ファイルシステムツリーは次のようになります。

RootFolder
  +-> js
  global.js
  ...
   +-> views
       index.js
       page1.js
       page2.js
       ...
index.html
page1.html
page2.html

したがって、これは通常、すべてのアプリケーション共有コードを含む1つのglobal.jsファイルであり、ページごとに別のファイルです。

名前空間については、$。extendが好きなので、各jsファイルには次のようなものがあります。

var app = app || {};  

/* only one document ready block per view if needed */
$(document).ready(function(){
    /* initialization code */
});

/* extend the app namespace with the Page1 code */
$.extend(app, {
    page1: {
        SayHi: function SayHi(name){
            alert('Hi ' + name);
        }
    }
});

したがって、次のように呼び出すことでコードにアクセスできます。

app.page1.SayHi("Alex");

このテクニックを使用すると、次のようになります。

  • コードを完全に制御します。あなたが完全に制御できない魔法のリソースの読み込みや派手なものはありません。
  • 地球環境汚染なし
  • 名前の競合はありません
  • 名前空間ツリーは必要なだけ深くすることができ、あなたはあなた自身の複雑さの所有者です。
  • 同じ名前空間レベルに実際に寄与する複数のjsファイルを持つことができます。これは、ヘルパーツールで特に役立ちます。
  • ページに含めるJavaScriptファイルに応じて、アプリの名前空間を大きくしたり小さくしたりできます。

結論：

Web環境は本当に簡単です。複雑にするべきではありません。

私はRequireJSをヒットしていません、誤解しないでください。それは意図されたとおりに機能します（本質的には純粋なリソースの遅延読み込みです）。それ以外はすべてパッケージに付属しているものですが、よりクリーンで透過的な方法で実行することもできます。

したがって、メイン機能が必要ない場合は、それを使用しても意味がありません。

乾杯！

于 2012-12-18T09:07:12.213 に答える