初めて知ったSeaJS
7451 ワード
最近はNodeJSとCommon JSがとても人気があります.先端は以前のように単純ではなく、もっと多くの伝統的なソフトウェア開発の知識と技能を身につけなければなりません.ここではなぜNodeJSとCommon JSを一緒にするのですか?私は主に中のモジュール構造に興味があります.ちょうどNodeJSのモジュール実現方式もCommon JSの関連規定に従います.
不思議なレクリエーション
まずコードを見ます.
1
2
3
4
5
6
1
2
3
4
5
6
7
8
9
レイクの神秘的な上着をかき分けます.
NodeJSのコードの性質と難しさの間に、requireの実現方法をしばらく研究していません.SeaJSについて、SeaJSは何ですか?まず、そのウェブサイトにアクセスすることを提案します.ここでは自然にCommon JSの規範問題も多く取り上げられています.
この不思議な
はい、見間違えていません.seajsというオブジェクトが露出したインターフェースはこのように簡単です.しかし、暴露されたインターフェースが簡単で精巧なために、その豊富な内容を無視することはできません.ソースコードを開けて、プロジェクト全体の構造を大体見てみます.ここでは主にSrcディレクトリの中に目を向けます.
ファイル名は主にseaから始まるブートファイルとapiファイル、fnから始まる補助関数ファイル、utilから始まるツールファイルです.SeaJS全体がファイルの構成を知ることができます.sea.jsファイルを開くと、先ほど述べた補助関数、ツールはプロジェクト全体の展開においてプライベートで暴露に保存されています.seajsオブジェクトの中で、これらの私有属性が実際に見られないのはなぜですか?sea-appi.jsの中で発見したいです.コードを詳しく見てください.ここでは詳しく説明しません.全体として、seajsはクローズドの利点を十分に活用して、私有変数をクローズドに保存して使いやすく、最終的なapiインターフェースで暴露の私有属性インターフェースを削除しますが、クローズド特性のためです.その内部値はまだ保持されています.この方式は個人的には非常に斬新で、特にこのような多文書プロジェクトを行う時、最終的なapiリリース段階で不要なプライベートインターフェースをクリアします.
問題が遠くなるほど、今神秘的なrequire関数に戻ります.このインターフェースは暴露されたどの内部補助関数ですか?名前を見るとfn-require.jsの中にあると思いますが、実はそうではないです.また遠くを見ると、require関数の最外層はdefine関数です.fn-define.jsを開けば、コードは雲の中に見えますが、でも、require関数はdefine関数です.現在の目標を明確にする時にrequire関連の実現を見つけます.しかし、まず、話題をそらして、CommonJSの中のこの仕様説明を見てください. Modules/Wrappings、ハハ、問題は正中下ですか?まさに私達が今関心を持っている方向です.コードを見続けて、このような関数に気づきました.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
はい、今回はもう大体SeaJSの基本状況を了解しました.私を困らせている問題もようやく解けました.ソースコードのさらなる分析と解読は次の機会にしましょう.
JavaScript SeaJS 関連記事
JavaScriptのクローズドを深く理解する(2) JavaScriptのクローズドを深く理解する(1) KISSY深く研究する(3)——loader.js KISSY深く研究します。(2)——dom-data.js KISSY研究(1)——kisy.js 回転:
http://ghsky.com/2011/05/seajs-first-view.html
不思議なレクリエーション
まずコードを見ます.
1
2
3
4
5
6
var
http = require(
'http'
);
http.createServer(
function
(req, res) {
res.writeHead(200, {
'Content-Type'
:
'text/plain'
});
res.end(
'Hello World
'
);
}).listen(1337,
"127.0.0.1"
);
console.log(
'Server running at http://127.0.0.1:1337/'
);
これはNodeJSのトップページの上のコードです.require
の関数の使い方を見てみます.ここのコードはhttpというモジュールが必要なので、var http = require('http');
です.しかし、私は疑問に思っています.require
の関数は非同期の呼び出しです.httpのモジュールファイルは同期できないので、ここでロードを実行することができません.(もちろん、同期のAJAXを使って要請したという人もいますが、私たちもクロスドメイン問題をサポートする必要があります.)このコードはNodeJSのコードですが、主にサーバー端で実行されています.V 8エンジン駆動を使って、いくつかの手段を使ってrequrieのモジュールを同期させて実行することができます.しかし、一つのWebアプリケーションに対してこのようなコードを見たら、なぜここには1つのコールバック関数が必要ないのかと疑問になります.次のコードを見続けます.1
2
3
4
5
6
7
8
9
define(
function
(require, exports, module) {
// :
var
$ = require(
'jquery'
);
// :
exports.someMethod = someFunction;
});
このコードはSeaJSトップページからのコードです.ここに再びvar $ = require('jquery');
というrequire関数が現れました.ここにも先ほどのような問題があります.明らかに非同期の必要性なのに、どうやってここで同期の書き方ができますか?require関数はここですでにjqueryのオブジェクト(jquery.jsをロードして実行します.)が用意されています.しかし、これは何の策略がありますか?サポートされているモジュールは全部このように事前にロードしなければならないわけではないです.しかも今後は自分のモジュールを拡張することができなくなります.第二の仮説はjqueryオブジェクトはここで初めて現れて、ファイルをダウンロードしてファイルを実行します.しかし、私の知っている限りでは、同期のAJAXを使ってこそできますが、ドメインを越えます.の問題は一番致命的な問題です.ここで解決できないはずがないですよね?!悩んでいます.悩みます..一つのリキュールにはこんな不思議な力があります.レイクの神秘的な上着をかき分けます.
NodeJSのコードの性質と難しさの間に、requireの実現方法をしばらく研究していません.SeaJSについて、SeaJSは何ですか?まず、そのウェブサイトにアクセスすることを提案します.ここでは自然にCommon JSの規範問題も多く取り上げられています.
この不思議な
require
関数をよりよく探究するために、まずgithubから最新のSeaJSソースコードまで引っ張ってきました.大体seajsコードの実行を見て、何が発生しますか?はい、見間違えていません.seajsというオブジェクトが露出したインターフェースはこのように簡単です.しかし、暴露されたインターフェースが簡単で精巧なために、その豊富な内容を無視することはできません.ソースコードを開けて、プロジェクト全体の構造を大体見てみます.ここでは主にSrcディレクトリの中に目を向けます.
ファイル名は主にseaから始まるブートファイルとapiファイル、fnから始まる補助関数ファイル、utilから始まるツールファイルです.SeaJS全体がファイルの構成を知ることができます.sea.jsファイルを開くと、先ほど述べた補助関数、ツールはプロジェクト全体の展開においてプライベートで暴露に保存されています.seajsオブジェクトの中で、これらの私有属性が実際に見られないのはなぜですか?sea-appi.jsの中で発見したいです.コードを詳しく見てください.ここでは詳しく説明しません.全体として、seajsはクローズドの利点を十分に活用して、私有変数をクローズドに保存して使いやすく、最終的なapiインターフェースで暴露の私有属性インターフェースを削除しますが、クローズド特性のためです.その内部値はまだ保持されています.この方式は個人的には非常に斬新で、特にこのような多文書プロジェクトを行う時、最終的なapiリリース段階で不要なプライベートインターフェースをクリアします.
問題が遠くなるほど、今神秘的なrequire関数に戻ります.このインターフェースは暴露されたどの内部補助関数ですか?名前を見るとfn-require.jsの中にあると思いますが、実はそうではないです.また遠くを見ると、require関数の最外層はdefine関数です.fn-define.jsを開けば、コードは雲の中に見えますが、でも、require関数はdefine関数です.現在の目標を明確にする時にrequire関連の実現を見つけます.しかし、まず、話題をそらして、CommonJSの中のこの仕様説明を見てください. Modules/Wrappings、ハハ、問題は正中下ですか?まさに私達が今関心を持っている方向です.コードを見続けて、このような関数に気づきました.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
deps = parseDependencies(factory.toString());
/* ------------------------------------------ */
function
parseDependencies(code) {
var
pattern = /\brequire\s*\(\s*[
'"]?([^'
")]*)/g;
var
ret = [], match;
while
((match = pattern.exec(code))) {
if
(match[1]) {
ret.push(match[1]);
}
}
return
ret;
}
なるほど!define関数の信頼関係(実際にはrequire関数の役割)ハード解析関数コードを通して、requireの使用状況を観察して決めました.思ったほど不思議ではありませんが、解決策ですね.ここで馬の仮説を見てみたら、仮説に合っています.ただここでは他のモジュールを全部ロードする必要はなく、コードの「ハード解析」を通して依存需要を完成させるには、define段階でチャンスがあります.まず、requireのモジュールを非同期的にロードして、そして、本当にrequireの時にはもちろん同期方式です.これは素晴らしいですね.はい、今回はもう大体SeaJSの基本状況を了解しました.私を困らせている問題もようやく解けました.ソースコードのさらなる分析と解読は次の機会にしましょう.
JavaScript SeaJS 関連記事
JavaScriptのクローズドを深く理解する(2) JavaScriptのクローズドを深く理解する(1) KISSY深く研究する(3)——loader.js KISSY深く研究します。(2)——dom-data.js KISSY研究(1)——kisy.js 回転:
http://ghsky.com/2011/05/seajs-first-view.html