聽說每一個大牛、小牛都應該有本身的庫——框架篇

最近寫了一系列的關於JavaScript文章，時不時就會蹦出個需求，須要寫個特定的小函數，或者是爲了解決瀏覽器兼容性問題，或者是簡化一些操做，前面寫的幾篇博客實際上已經寫出了一些經常使用的函數，既然本身但願在兩年內變成個技術小牛，提早準備本身的庫函數吧。

框架選擇

是個庫函數都會有本身的框架，我經常使用的有兩種形式，一種能夠歸結爲靜態方法型，大概定義一個當即執行函數，對外提供一個對象引用，本身定義的庫函數都做爲這個對象的靜態函數供外部使用訪問；類外一種就是一個類jQuery的集成解決方案，相信介紹我就沒必要多說了。

這兩種方式各有利弊吧，通過數次糾結仍是決定使用靜態方法，好處有幾個

1. 代碼可讀性還稍微高那麼一小點兒，由於相對於類jQuery這樣的寫法仍是更好理解一些，方便別人讀代碼

2. 如今大部分網站包括咱們公司本身的網站中大部分頁面已經引用了jQuery，在寫一個相似的實際意義不大，而寫一個靜態方法的能夠在沒有應用jQuery的頁面上阻隔簡單的拓展

3.  從實用性上考慮，實際上要不是由於有些比較複雜的選擇器瀏覽器兼容性問題，我幾乎是不使用jQuery的，而平時本身寫一些demo頁面，結構很簡單，根本用不到複雜的選擇器，相反最經常使用的就是綁定方法等這些小功能，寫個靜態方法類的平時用起來更方便

選定了框架後看看標題，有些難爲情，由於下面這兩句就是框架的代碼，這麼簡單都很差意思稱之爲框架

//JavaScript原生對象拓展文件

 

庫文件

(function (window) { 
                
                var ssLib={

                    //內部函數

                    //1.Event
                    
                    //2.DOM 拓展、CSS
                    
                    //3.Ajax
                    
                    //4.動畫
                    
                    //5.簡單插件
                    
                };
                window.ssLib = ssLib; //對外提供接口
            })(window);

組織結構及內容

在讀jQuery源碼的時候我發現很難讀，裏面各類方法穿插，常常讀到某句的時候，發現其調用了一個內部函數，而後再去找這個內部函數在哪裏，好麻煩，因此在本身寫的庫函數裏面乾脆把公用的內部函數寫到最前面，方便查找。

看過一些書講過jQuery的一個好處就是不會與將來的API衝突，若是對JavaScript原生對象進行拓展很大可能會與將來API衝突，除非把名字起的很是奇怪，這裏就儘可能作一下判斷原生的有沒有，而且隨時關注人家將來API是什麼樣子，儘可能把做用及返回結果保持一致，使IE低版本用起來也不會感受很奇怪。

（後記：最近聽取朋友意見將JavaScript原生對象拓展部分抽取出庫函數，放到了一個extention.js內）

 

我平時除了選擇器用的最頻繁的大概就是Event處理了（最近在作插件），因此把它放到最前面，DOM拓展、CSS部分但願寫一些對class的處理、對DOM元素移動、添加、刪除等處理，Ajax及動畫就是那麼回事兒了，簡單插件部分但願添加像Dialog、Tab、Tree這樣的插件吧

最後

這只是今天早上拍拍腦殼的初步計劃與設想，有不少缺陷，但願各位多給意見，若是不吝分享本身的就更感激涕零了。