8

私は個人的なプロジェクトで遊んで、誓いについて学んでいます。これは小さなクライアント側のライブラリであり、テストは誓いで行われます。したがって、次のように記述されたファイルをビルドしてテストする必要があります。

(function(exports) { 
    var module = export.module = { "version":"0.0.1" }; 
    //more stuff
})(this);

私のテスト（science.js、d3などに基づく）では、次のようなモジュールが必要です。

require("../module");

テストを実行しようとすると「モジュールが定義されていません」というエラーが引き続き発生したため、replに移動して次のコマンドを実行しました。

require("../module")

そしてそれは戻った：

{ module: { version: "0.0.1" } }

私は次のようなことができることに気づきました。

var module = require("../module").module;

しかし、特にこのプロジェクトのベースとなったライブラリが私が説明した形式でそれを行っているので、私はそれをそのようにすることによって問題を引き起こしているように感じます。

私のプロジェクトは、私がベースにしたものと同じように動作するようにしたいと思います。

require("../module");

この名前空間に変数を作成します。

module.version; //is valid.

私はこれをさまざまな図書館で見ました。私はTの形式と思考プロセスに従っていますが、私が知らない必須の動作について何かが欠けている可能性があると信じています。

4

1 に答える 1

16

この方法で作成しても問題ありません。モジュールは、module.exportsオブジェクトで返すものを定義します。ちなみに、実際には自己実行関数（SEF）は必要ありません。ブラウザのように、グローバルなリークはありません:-)

例

module1.js：

module.exports = {
    module: { 'version': '0.1.1' }
};

main.js：

var module1 = require( './module1.js' );
// module1 has what is exported in module1.js

これがどのように機能するかを理解したら、必要に応じてバージョン番号をすぐに簡単にエクスポートできます。

module1.js：

module.exports = '0.1.1';

main.js：

var module1 = require( './module1.js' );
console.log( module1 === '0.1.1' ); // true

または、ロジックが必要な場合は、次のmodule1.jsようにファイルを簡単に拡張できます。

module.exports = ( function() {
    // some code
    return version;
} () ); // note the self executing part :-)
// since it's self executed, the exported part
// is what's returned in the SEF

または、多くのモジュールと同様に、一部のユーティリティ関数をエクスポートする（そして他の関数を「プライベート」に保つ）場合は、次のように実行できます。

module.exports = {
    func1: function() {
        return someFunc();
    },

    func2: function() {},

    prop: '1.0.0'
};

// This function is local to this file, it's not exported
function someFunc() {
}

したがって、main.jsでは：

var module1 = require( './module1.js' );
module1.func1(); // works
module1.func2(); // works
module1.prop; // "1.0.0"
module1.someFunc(); // Reference error, the function doesn't exist

あなたの特別な場合

あなたの特別な場合については、彼らがしているようにそれをすることはお勧めしません。

ここを見ると：https ：//github.com/jasondavies/science.js/blob/master/science.v1.js

var彼らがキーワードを使用していないことがわかります。したがって、彼らはグローバル変数を作成しています。

requireこれが、グローバル変数を定義するモジュールが一度アクセスできる理由です。

ちなみに、exports彼らの場合、議論は役に立たない。それは実際にはオブジェクト（ブラウザglobalでは同等）であり、オブジェクトではないため（関数ではグローバルオブジェクトであり、厳密モードが有効になっている場合）、誤解を招く可能性があります。windowmodule.exportsthisundefined

結論

彼らがしているようにそれをしないでください、それは悪い考えです。グローバル変数は悪い考えです。ノードの哲学を使用し、必要なモジュールを再利用する変数に格納することをお勧めします。

クライアント側で使用してnode.jsでテストできるオブジェクトが必要な場合は、次の方法があります。

yourModule.js：

// Use either node's export or the global object in browsers
var global = module ? module.exports : window.yourModule;

( function( exports ) {
    var yourModule = {};
    // do some stuff
    exports = yourModule;
} ( global ) );

global変数の作成を回避するために、これに短縮できます。

( function( exports ) {
    var yourModule = {};
    // do some stuff
    exports = yourModule;
} ( module ? module.exports : window.yourModule ) );

このようにして、クライアント側で次のように使用できます。

yourModule.someMethod(); // global object, "namespace"

そしてサーバー側では：

var yourModule = require( '../yourModule.js' );
yourModule.someMethod(); // local variable :-)

参考までに、..「親ディレクトリ」を意味します。これは、モジュールを入手する場所の相対パスです。ファイルが同じディレクトリにある場合は、を使用します.。

于 2012-07-22T17:04:42.673 に答える