どの牛も子牛も自分の庫を持つべきだという――フレーム編

3114 ワード

最近、JavaScriptに関する一連の文章を書いていると、時々需要が飛び出して、特定の小さな関数を書く必要があります.あるいは、ブラウザの互換性の問題を解決するために、あるいは操作を簡略化するために、前に書いたいくつかのブログは実際によく使われている関数を書いています.自分が2年以内に技術の牛になりたい以上、自分のライブラリ関数を事前に準備しておきましょう.

フレーム選択


ライブラリ関数はすべて自分のフレームワークがあって、私がよく使うのは2つの形式があって、1つは静的な方法型にまとめることができて、大体1つの直ちに実行する関数を定義して、対外的に1つのオブジェクトの参照を提供して、自分で定義したライブラリ関数はすべてこのオブジェクトの静的な関数として外部の使用のためにアクセスします;クラス外の1つはクラスjQueryの統合ソリューションであり、紹介は言うまでもないと信じています.
この2つの方法はそれぞれメリットとデメリットがあるでしょうが、数回の葛藤を経て静的な方法を使うことにしました.メリットはいくつかあります.
1.コードの可読性はまだ少し高いです.クラスjQueryのような書き方よりも理解しやすいので、他の人がコードを読むのに便利です.
2.現在、大部分のウェブサイトは当社自身のウェブサイトの大部分のページを含んですでにjQueryを引用して、1つの類似の実際的な意義を書くのは大きくなくて、1つの静的な方法を書くのはjQueryを適用していないページの上で簡単な開拓を遮断することができます
3.実用性を考えると、実際には複雑なセレクタブラウザの互換性の問題があるからではなく、私はほとんどjQueryを使わないのですが、普段は自分でdemoページを書いています.構造が簡単で、複雑なセレクタはまったく使えません.逆に最もよく使われているのはバインド方法などの小さな機能で、静的メソッドクラスを書くときに便利です
フレームを選んでタイトルを見ると、恥ずかしいです.次の2つがフレームのコードなので、簡単にフレームと呼ぶのは耻ずかしいです.
//JavaScript        

 
ライブラリファイル
(function (window) { 
                
                var ssLib={
//
//1.Event //2.DOM 、CSS //3.Ajax //4. //5. }; window.ssLib = ssLib; // })(window);

組織構造及び内容


jQueryのソースコードを読む时、私は読みにくいことを発见して、中の各种の方法は挿入して、いつもある文を読む时、それが1つの内部の関数を呼び出したことを発见して、それから更にこの内部の関数がどこにあるかを探して、面倒で、だから自分で书いたライブラリの関数の中でいっそ共通の内部の関数を一番前に书いて、探しやすいです.
jQueryの利点の一つは、将来のAPIと衝突しないことであり、JavaScriptのオリジナルオブジェクトを拡張すると、将来のAPIと衝突する可能性が高いという本を読んだことがあります.名前を非常に奇妙にしない限り、ここではできるだけオリジナルの有無を判断し、人の未来のAPIがどのようなものかに注目し、できるだけ役割と戻り結果を一致させ、IEの低バージョンを使ってもおかしくないようにします.
(後記:最近友人の意見を聞いてJavaScriptオリジナルオブジェクト拡張部分を抽出してライブラリ関数をextention.js内に配置しました)
 
私は普段セレクタ以外で一番頻繁に使うのがEvent処理なので(最近プラグインをやっています)一番前に置いて、DOM拡張、CSS部分はclassの処理、DOM要素の移動、追加、削除などの処理を書いてほしいです.Ajaxやアニメーションはそういうことですが、単純プラグイン部分はDialog、Tab、Treeのようなプラグインを追加したいですね

最後に


これは今朝頭をたたいた初歩的な計画と構想にすぎず、多くの欠陥があり、皆さんがもっと意見を出してほしいと思っています.自分のことを分かち合えばもっと感謝します.