初めて知ったSeaJs
4503 ワード
前に書いてください.SeaJs-環境モジュール化開発実践ppt
最近NodeJSとCommonJSは本当にいいですね.先端は以前のように単純ではなく、もっと多くの伝統的なソフトウェア開発の知識と技能を身につけなければなりません.ここではなぜNodeJSとCommonJSを一緒にして話していますか?主に中のモジュール構造に興味があります.NodeJSのモジュール実現方式もCommonJSの関連規定に従っています.
不思議なレクリエーション
まずコードを見ます.
1
2
3
4
5
6
1
2
3
4
5
6
7
8
9
レイクの神秘的な上着をかき分けます.
NodeJSのコードの性質と難しさの間に、requireの実現方法を研究していません.SeaJSについては、まずそのウェブサイトを訪問することを提案します.その中で、自然とCommunJSの規範問題にも言及しています.
この不思議な
はい、見間違えていません.seajsというオブジェクトが露出したインターフェースはこのように簡単です.しかし、暴露されたインターフェースが簡単で精巧なために、その豊富な内容を無視することはできません.ソースコードを開けて、プロジェクト全体の構造を大体見てみます.ここでは主にSrcディレクトリの中に目を向けます.
ファイルの名前は主にseaから始まるブートファイルとapiファイル、fnから始まる補助関数ファイル、utilから始まるツールファイルです.SeaJS全体のファイル構成が分かります.sea.jsファイルを開くと、先ほど述べた補助関数、ツールはプロジェクト全体の構造の中でプライベートで暴露されたseajsに保存されています.オブジェクトの中で、なぜこれらの私有属性が実際に見られないのですか?sea-appi.jsでコードを確認したいです.ここでは詳しく説明しません.つまり、seajs全体がクローズドの利点を十分に活用して、プライベート変数をクローズドに保存して使いやすいです.最終的なapiインターフェースで暴露された私有属性インターフェースを削除しますが、クローズド特性のため、その内部の値はまだ保持されています.このような方式は個人的には非常に新鮮で、特にこのような複数のファイルプロジェクトを行う時、最終的なappiリリース段階で不要なプライベートインターフェースをクリアします.
問題が遠くなるほど、今神秘的なrequire関数に戻ります.このインターフェースは暴露されたどの内部補助関数ですか?名前を見るとfn-require.jsの中にあると思いますが、実はそうではないです.また遠くを見ると、require関数の最外層はdefine関数です.fn-define.jsを開けば、コードは雲の中に見えますが、でも、require関数はdefine関数です.現在の目標を明確にする時にrequire関連の実現を見つけますが、まず、話題をそらして、CommunJSの中のこの規範を見て、Modules/Wrappingsを説明します.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
はい、今回はもう大体SeaJSの基本状況を了解しました.私を困らせている問題もようやく解けました.ソースコードのさらなる分析と解読は次の機会にしましょう.
最近NodeJSとCommonJSは本当にいいですね.先端は以前のように単純ではなく、もっと多くの伝統的なソフトウェア開発の知識と技能を身につけなければなりません.ここではなぜNodeJSとCommonJSを一緒にして話していますか?主に中のモジュール構造に興味があります.NodeJSのモジュール実現方式もCommonJSの関連規定に従っています.
不思議なレクリエーション
まずコードを見ます.
1
2
3
4
5
6
varhttp = 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
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については、まずそのウェブサイトを訪問することを提案します.その中で、自然とCommunJSの規範問題にも言及しています.
この不思議な
require関数をよりよく探究するために、まずgithubから最新のSeaJSソースコードに引っ張りました.大体seajsコードの実行を見てから何が発生しますか?はい、見間違えていません.seajsというオブジェクトが露出したインターフェースはこのように簡単です.しかし、暴露されたインターフェースが簡単で精巧なために、その豊富な内容を無視することはできません.ソースコードを開けて、プロジェクト全体の構造を大体見てみます.ここでは主にSrcディレクトリの中に目を向けます.
ファイルの名前は主にseaから始まるブートファイルとapiファイル、fnから始まる補助関数ファイル、utilから始まるツールファイルです.SeaJS全体のファイル構成が分かります.sea.jsファイルを開くと、先ほど述べた補助関数、ツールはプロジェクト全体の構造の中でプライベートで暴露されたseajsに保存されています.オブジェクトの中で、なぜこれらの私有属性が実際に見られないのですか?sea-appi.jsでコードを確認したいです.ここでは詳しく説明しません.つまり、seajs全体がクローズドの利点を十分に活用して、プライベート変数をクローズドに保存して使いやすいです.最終的なapiインターフェースで暴露された私有属性インターフェースを削除しますが、クローズド特性のため、その内部の値はまだ保持されています.このような方式は個人的には非常に新鮮で、特にこのような複数のファイルプロジェクトを行う時、最終的なappiリリース段階で不要なプライベートインターフェースをクリアします.
問題が遠くなるほど、今神秘的なrequire関数に戻ります.このインターフェースは暴露されたどの内部補助関数ですか?名前を見るとfn-require.jsの中にあると思いますが、実はそうではないです.また遠くを見ると、require関数の最外層はdefine関数です.fn-define.jsを開けば、コードは雲の中に見えますが、でも、require関数はdefine関数です.現在の目標を明確にする時にrequire関連の実現を見つけますが、まず、話題をそらして、CommunJSの中のこの規範を見て、Modules/Wrappingsを説明します.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
deps = parseDependencies(factory.toString()); /* ------------------------------------------ */ functionparseDependencies(code) { varpattern = /\brequire\s*\(\s*['"]?([^'")]*)/g; varret = [], match; while((match = pattern.exec(code))) { if(match[1]) { ret.push(match[1]); } } returnret;}なるほど!define関数の信頼関係(実際にはrequire関数の役割)ハード解析関数コードを通して、requireの使用状況を観察して決めました.思ったほど不思議ではありませんが、解決策ですね.ここで馬の仮説を見てみたら、仮説に合っています.ただここでは他のモジュールを全部ロードする必要はなく、コードの「ハード解析」を通して依存需要を完成させるには、define段階でチャンスがあります.まず、requireのモジュールを非同期的にロードして、そして、本当にrequireの時にはもちろん同期方式です.これは素晴らしいですね.はい、今回はもう大体SeaJSの基本状況を了解しました.私を困らせている問題もようやく解けました.ソースコードのさらなる分析と解読は次の機会にしましょう.