モジュール化、Common JS仕様、require原理とバッグ検索メカニズムなどの整理
6531 ワード
モジュール化のメリット:より効果的な組織コードのために、再利用性を高め、開発効率を高めるために、プロジェクトを異なるモジュールに分割し、各モジュール、職責は単一で、複数の人が協力し、効率的に実行し、メンテナンスしやすくなります.
モジュールの発展過程 jsは他の高級言語と違って、モジュールシステムがあります.標準ライブラリが少ないです. jsは最初はグローバルオブジェクトの形だけであり、個々の小さな関数によって異なるモジュール機能 を実現する.は徐々に発展し、対象の形を構築することによって、異なる機能を武装する. は、関数およびクローズドの形を即座に実行することによって、さらに別の小さなコンポーネント を分離し続ける.オブジェクトが多くなると、名前空間を介して階層管理を開始する .最終的に、十数年を経て、コミュニティはだんだん発展して強大になって、common JS規範の提出はjavascript歴史の上で最も重要な一里塚になりました. Best Wishes:ホープjavascript can run everwhere! Common JS仕様
Common JSはただ一つの規範であり、文書や枠組みではないので、この点は必ず明確にしてください.公式サイト:http://www.commonjs.org/CommonJSの大部分は草案または理論であり、ここ数年の発展の中で著しい効果がありました.これらの規範は以下を含みます.モジュール バイナリ I/Oストリーム プロセス環境 ファイルシステム ソケット ユニット試験 ウェブサーバゲートウェイ 包の管理などは各方面の面をカバーしています. バックエンドのnodejsでは明らかにCommonJS仕様の最適な実践です.
nodejsの中のrequireの内部の構造
私達は知っています.nodejsには各ファイルが独立したモジュールです.モジュール間で変数の汚染や命名の衝突などの問題が発生しません.exportsまたはmodule.exports出力機能またはAPIを提供することによって、我々はrequireを通じてモジュールを導入し、先端がscriptタグを通じてjsファイルを導入するようになる.しかし、内部の詳細はどうですか?朴霊の『深入浅出』の中でjavascriptに関するモジュールのコンパイルはもういくつかの説明をしました.じゃ、繁雑に簡単に残して、深く体験してみます. require関数のソースコードはこのように理解できます.もちろん多くのものを簡略化しました.今はそれだけを引き出します. 説明:上に挙げた小さな栗はnodejsの中のrequireの実現をシミュレートしました.もちろんソースはこのように書かれていません.ソースに関するものはもっと複雑になります.上には理解を助けるデモがあります. 私たちが自分で書いた論理機能はすべてpathに代表されるファイルモジュールの中にあります.内部ですべての機能をmodule.exportまたはexportの対象にかけて、最終的にreturnは彼らに暴露されます. module.exportとexportsは同じオブジェクトを指していることが分かります. は、requireモジュールにおいて、このステップを概ね経験した. パス解析 ファイル位置決め コンパイル実行 小さいrequireモジュール導入事例は、util.jsファイルモジュールにおいて、私達はこうして を書きます. index.jsファイルの中で、私達はこのように書きます. はCLIでindexモジュールを実行し、3 を出力します.
nodejsのモジュール分類とロード順序 nodejsにおけるコアモジュールとファイルモジュールの参照方法: コアモジュール:require(コアモジュール名) ファイルモジュール:require(“パス+ファイル名”);パスは、 カスタムモジュール:特殊なファイルモジュールは、おそらくファイルまたはパケットの形である .
モジュールのロード順序: 優先的にキャッシュから をロードする.コアモジュール:http、fs、pathなど(優先検索コアモジュール) ファイルモジュール:./または./から始まる相対パスファイルモジュール カスタムモジュール:検索するのに一番時間がかかります. 目次とカバンの検索原則は、例えば、ルートディレクトリのnode_まで経路に沿って段階的に再帰されるモジュールパスがある.modulesディレクトリ: これはカスタムモジュールのロード速度が一番遅い原因です. .requireの識別子が拡張子nodeを含まないときは.js.json.nodeの順序で拡張子を補足して、順次試します. もしrequire中に対応ファイルが見つからなかったら、ディレクトリが得られます.その時、nodeは現在のディレクトリを一つのパッケージとして処理します. このとき、nodeはディレクトリ下のpackage.jsonファイルを検索し、JSON.parse()の解析パケット記述オブジェクトを通して、メール属性で指定されたファイル名を取得して を位置決めする.もしmain属性の指定が間違っていたり、package.jsonファイルがない場合、nodeはindexをデフォルトのファイル名として順次index.js、index.json、index.node を検索します.は、ディレクトリ分析においてモジュールが配置されていません.前のレベルのディレクトリを巡回して検索します.見つけられなかったら、検索に失敗した異常を投げ出します.
モジュールの発展過程
Common JSはただ一つの規範であり、文書や枠組みではないので、この点は必ず明確にしてください.公式サイト:http://www.commonjs.org/CommonJSの大部分は草案または理論であり、ここ数年の発展の中で著しい効果がありました.これらの規範は以下を含みます.
nodejsの中のrequireの内部の構造
私達は知っています.nodejsには各ファイルが独立したモジュールです.モジュール間で変数の汚染や命名の衝突などの問題が発生しません.exportsまたはmodule.exports出力機能またはAPIを提供することによって、我々はrequireを通じてモジュールを導入し、先端がscriptタグを通じてjsファイルを導入するようになる.しかし、内部の詳細はどうですか?朴霊の『深入浅出』の中でjavascriptに関するモジュールのコンパイルはもういくつかの説明をしました.じゃ、繁雑に簡単に残して、深く体験してみます.
// require
function _require(path) {
// Module
var Module = function() {
this.exports = {};
}
// nodejs nodejs require
var fs = require('fs');
//
var sourceCode = fs.readFileSync(path, 'utf8');
//
var packSourceCode = '(function(module,exports){ ' + sourceCode + ' return module.exports; })';
//
var packFunc = eval(packSourceCode);
// Module exports
var module = new Module();
// module module.exports
// module.exports exports
var res = packFunc(module, module.exports);
// path API
return res;
}
//
var Calculator = function() {};
Calculator.prototype = {
add: function(x, y) {
return x + y;
},
subtract: function(x, y) {
return x - y;
},
multiply: function(x, y) {
return x * y;
},
divide: function(x, y) {
return x / y;
}
}
// exports module.exports
// exports = new Calculator(); ,
module.exports = new Calculator(); // API
var cal = require('./util');
var res = cal.add(1, 2);
console.log(res); // 3
$ node index
3
nodejsのモジュール分類とロード順序
./
によって表される相対パスまたは絶対パスを使用することができ、ファイル名は、拡張子名を省略することができる.├─/node_modules/
└─/home/node_modules/
└─/user/test/node_modules/