?

? ? ? ? 在web開發(fā)的過程中，我們會需要用到很多大大小小的插件，比如文本框，下拉樹，下拉框等等各種各樣的都需要。或許在開發(fā)的網(wǎng)頁中會用到同一種插件來滿足各種各樣復(fù)雜的業(yè)務(wù)邏輯，比如簡單的一個下拉樹，有的地方需要進行拖拽排序，有的地方需要能夠進行模糊搜索，有的地方需要權(quán)限控制等等。如果僅僅一次被使用到，那么我們在使用的時候，寫一個滿足需求的插件就可以了。但是當(dāng)許多地方需要用到時候，你就會發(fā)現(xiàn)自己會不停去復(fù)制曾經(jīng)寫過的部分代碼，隨著越用越頻繁，復(fù)制的量也會越來越大。當(dāng)其中的一處代碼出現(xiàn)bug時，所有復(fù)制過該處代碼的地方都需要進行同樣的維護。本人是堅決抵制復(fù)制代碼的，這也絕對是代碼界的大忌，當(dāng)我們需要復(fù)制代碼的時候，我們更需要做的就是深入的思考。比如搭建一個可以不斷擴展的結(jié)構(gòu)，那么同一類的控件就會有一套結(jié)構(gòu)，慢慢不斷積累，豐富多樣的控件組合到了一起所形成的可擴展框架就統(tǒng)稱為UI框架，比較常見的有JQuery官方的JQueryUI，另外也有smartUI，easyUI，ExtJs等等。鑒于此，隨著使用的插件不對增多，慢慢地我們自己也會希望能夠?qū)懸惶卓蚣軄砼c這些大框架進行較量。

? ? ? ? 那么組成框架地重要元素必然是一個個獨立地插件，當(dāng)我們在寫一個插件時，要怎樣才能讓它的擴展性能夠滿足幾乎所有地業(yè)務(wù)邏輯呢？這是一個十分值得思考的問題。

? ? ? ? 最近，接觸到了一個很優(yōu)秀的下拉樹控件zTree，不得不說真的十分優(yōu)秀。第一次拿來使用，10分鐘便可熟悉所有的API，靈活應(yīng)用。無論是性能，交互還是擴展性，幾乎無可挑剔。我曾2次遍歷過其中的所有代碼，從中受益匪淺，同時也漸漸養(yǎng)成了自己寫擴展性插件的一個習(xí)慣，當(dāng)然肯定還有很多不足的地方，畢竟自己的框架寫給自己用，用起來不爽就絕對存在不足的地方。下面就來和大家一起探討下到底有哪些值得我們學(xué)習(xí)的地方吧：

規(guī)范的API接口函數(shù)和屬性配置。
大大降低了API使用的學(xué)習(xí)成本。比如所有事件類函數(shù)統(tǒng)一on開頭，每種事件都有對應(yīng)的onBefore(事件發(fā)生前)，on(事件發(fā)生時)，onAfter(事件發(fā)生后)三種。屬性配置也有一定命名規(guī)范，is開頭表示“是否是”，has開頭表示“是否有/存在”等等。

有意義的傳參與返回值。
這點也很重要，許多人寫js的函數(shù)時，喜歡一個函數(shù)寫到底，沒有返回值也沒有參數(shù)傳遞，其實這是比較糟糕的。曾經(jīng)我也不以為然，后來發(fā)現(xiàn)其實這樣的一個function和把代碼寫在調(diào)用function的地方幾乎沒有什么差別，唯一的區(qū)別頂多就是看著清爽了或者可以被繼承下擴展什么的。實際上這樣的function，在被不熟悉這段代碼的人來使用是很不爽的。多一個有意義的返回值，比如Boolean類型，返回這個函數(shù)操作是否有成功執(zhí)行等等；多幾個參數(shù)傳遞進函數(shù)，這樣才能感覺到這個函數(shù)是真的在處理一些特定的數(shù)據(jù)，而傳遞的參數(shù)也可以讓我們更快的理解這個函數(shù)做了怎么樣的數(shù)據(jù)處理。

錯誤的英文單詞。
倆字：“杜絕”。(每個coder都是藝術(shù)家，我們不容許有瑕疵)

區(qū)分private和public。開放出來的API函數(shù)最好都相對集中地寫在一起，而私有地一些方法地命名盡量區(qū)分開來，比如前面加“下劃線”等。

精簡的注釋。注釋不是寫給自己看的，一個產(chǎn)品地代碼有80%地可能，開發(fā)者和維護者不是同一個人，為了降低成本，作為開發(fā)者我們需要給維護者一個可維護地環(huán)境。就是在需要地地方給予有效地注釋。大大增強可讀性。

css的規(guī)范使用。
很多人都忽視css，覆蓋和權(quán)重問題經(jīng)常讓我們無法得到自己想要的效果。很多時候，覺得只要當(dāng)前的頁面看的過去就認為css沒有問題，確實如此。但是寫框架類的插件就不能夠這樣去思考問題，css也會污染全局，僅僅通過特有的類名是不夠的。比較好的方法，就是比如我們寫一個下拉樹控件，下拉樹有個基礎(chǔ)類是fr-combotree。那么我們所有下拉樹的css都統(tǒng)一用.fr-combotree開頭，然后一層層向下選擇。這樣就可以有效的避免互相影響。

時間復(fù)雜度。
最大只能O(n2)，盡量優(yōu)化成O(n)或者O(logn)，超過肯定有問題。

API文檔。
十分重要，任何一個優(yōu)秀框架的必備品。當(dāng)我們大致寫完一個粗糙的框架后，我們就會希望有一份較為完美的doc文檔，方便查閱。推薦ExtJs的JsDuck。

IE兼容。
框架的兼容性是很多企業(yè)級應(yīng)用開發(fā)所選擇的重要依據(jù)。

性能優(yōu)化。
web端的性能也是需要重視的，不然會嚴重影響到用戶體驗。可參考：http://115.29.194.184/?p=311

下面針對IE6及IE6以上的兼容的注意點做一些總結(jié)：

css不要使用偽類。只有a標(biāo)簽可以使用:hover，:link，:active，:visited。

使用動畫效果務(wù)必考慮兼容問題。slideDown slideUp fadeIn fadeOut可以考慮使用。

new Date函數(shù)，只能使用?new Date(年,月,日,時,分,秒)或new Date(毫秒)

不要使用String[index]方法，應(yīng)該使用?String.charAt(index)

$(‘<form/>’)的寫法改為$(‘<form></form>’)

.text()和.html()的區(qū)別使用，不要取DOM的text或者html來給控件賦值，因為text()會合并空格，不準(zhǔn)確。

IE6下字過長顯示省略號overflow必須和width連用，可參考：http://115.29.194.184/?p=107

display: inline-block IE8，有些可以采用display: inline和zoom:1解決

圖片透明問題。可參考http://115.29.194.184/?p=98

只能使用HTML3.2及其以下的實體字符

轉(zhuǎn)載于:https://www.cnblogs.com/littlehb/p/3866470.html

總結(jié)

以上是生活随笔為你收集整理的不断学习UI框架的写法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。