欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

10個JavaScript中易犯小錯誤

 更新時間:2016年02月14日 16:05:08   投稿:lijiao  
10個JavaScript中易犯小錯誤,需要大家注意!

在今天,JavaScript已經(jīng)成為了網(wǎng)頁編輯的核心。尤其是過去的幾年,互聯(lián)網(wǎng)見證了在SPA開發(fā)、圖形處理、交互等方面大量JS庫的出現(xiàn)。

  如果初次打交道,很多人會覺得js很簡單。確實,對于很多有經(jīng)驗的工程師,或者甚至是初學者而言,實現(xiàn)基本的js功能幾乎毫無障礙。但是JS的真實功能卻比很多人想象的要更加多樣、復(fù)雜。JavaScript的許多細節(jié)規(guī)定會讓你的網(wǎng)頁出現(xiàn)很多意想不到的bug,搞懂這些bug,對于成為一位有經(jīng)驗的JS開發(fā)者很重要。

常見錯誤一:對于this關(guān)鍵詞的不正確引用

我曾經(jīng)聽一位喜劇演員說過:

“我從未在這里,因為我不清楚這里是哪里,是除了那里之外的地方嗎?”

  這句話或多或少地暗喻了在js開發(fā)中開發(fā)者對于this關(guān)鍵字的使用誤區(qū)。This指代的是什么?它和日常英語口語中的this是一個意思嗎?

  隨著近些年js編程不斷地復(fù)雜化,功能多樣化,對于一個程序結(jié)構(gòu)的內(nèi)部指引、引用也逐漸變多起來

  下面讓我們一起來看這一段代碼:

Game.prototype.restart = function () {  this.clearLocalStorage(); 

  this.timer = setTimeout(function(){   this.clearBoard();    }, 0);

 };

  運行上面的代碼將會出現(xiàn)如下錯誤:

Uncaught TypeError: undefined is not a function
  這是為什么?this的調(diào)用和它所在的環(huán)境密切相關(guān)。之所以會出現(xiàn)上面的錯誤,是因為當你在調(diào)用 setTimeout()函數(shù)的時候, 你實際調(diào)用的是window.setTimeout(). 因此,在 setTimeout() 定義的函數(shù)其實是在window背景下定義的,而window中并沒有 clearBoard() 這個函數(shù)方法。

  下面提供兩種解決方案。第一種比較簡單直接的方法便是,把this存儲到一個變量當中,這樣他就可以在不同的環(huán)境背景中被繼承下來:

Game.prototype.restart = function () {  this.clearLocalStorage(); 

  var self = this;

  this.timer = setTimeout(function(){   self.clearBoard();}, 0); };

  第二種方法便是用bind()的方法,不過這個相比上一種要復(fù)雜一些。

Game.prototype.restart = function () {  this.clearLocalStorage(); 

  this.timer = setTimeout(this.reset.bind(this), 0); };   

Game.prototype.reset = function(){   this.clearBoard();};

  上面的例子中,兩個this均指代的是Game.prototype。

常見錯誤二:傳統(tǒng)編程語言的生命周期誤區(qū)

  另一種易犯的錯誤,便是帶著其他編程語言的思維,認為在JS中,也存在生命周期這么一說。請看下面的代碼:

for (var i = 0; i < 10; i++) {  /* ... */ } console.log(i);

  如果你認為在運行console.log() 時肯定會報出 undefined 錯誤,那么你就大錯特錯了。我會告訴你其實它會返回 10嗎。

  當然,在許多其他語言當中,遇到這樣的代碼,肯定會報錯。因為i明顯已經(jīng)超越了它的生命周期。在for中定義的變量在循環(huán)結(jié)束后,它的生命也就結(jié)束了。但是在js中,i的生命還會繼續(xù)。這種現(xiàn)象叫做 variable hoisting。

  而如果我們想要實現(xiàn)和其他語言一樣的在特定邏輯模塊中具有生命周期的變量,可以用let關(guān)鍵字。

常見錯誤三:內(nèi)存泄露

  內(nèi)存泄露在js變成中幾乎是一個無法避免的問題。如果不是特別細心的話,在最后的檢查過程中,肯定會出現(xiàn)各種內(nèi)存泄露問題。下面我們就來舉例說明一下:

var theThing = null; 

var replaceThing = function () {  

    var priorThing = theThing; 

    var unused = function () { 

         if (priorThing) {    console.log("hi");   }  

    }; 

    theThing = {   longStr: new Array(1000000).join('*'), // 

         someMethod: function () {    console.log(someMessage);   }  
    }; 
};  
setInterval(replaceThing, 1000); 

  如果運行上面的代碼,你會發(fā)現(xiàn)你已經(jīng)造成了大量的內(nèi)存泄露,每秒泄露1M的內(nèi)存,顯然光靠GC(垃圾回收器)是無法幫助你的了。由上面的代碼來看,似乎是longstr在每次replaceThing調(diào)用的時候都沒有得到回收。這是為什么呢?

  每一個theThing結(jié)構(gòu)都含有一個longstr結(jié)構(gòu)列表。每一秒當我們調(diào)用 replaceThing, 它就會把當前的指向傳遞給 priorThing. 但是到這里我們也會看到并沒有什么問題,因為 priorThing 每回也是先解開上次函數(shù)的指向才會接受新的賦值。并且所有的這一切都是發(fā)生在 replaceThing 函數(shù)體當中,按常理來說當函數(shù)體結(jié)束之后,函數(shù)中的本地變量也將會被GC回收,也就不會出現(xiàn)內(nèi)存泄露的問題了,但是為什么會出現(xiàn)上面的錯誤呢?

  這是因為longstr的定義是在一個閉包中進行的,而它又被其他的閉包所引用,js規(guī)定,在閉包中引入閉包外部的變量時,當閉包結(jié)束時此對象無法被垃圾回收(GC)。

常見錯誤四:比較運算符

  JavaScript中一個比較便捷的地方,便是它可以給每一個在比較運算的結(jié)果變量強行轉(zhuǎn)化成布爾類型。但是從另一方面來考慮,有時候它也會為我們帶來很多不便,下面的這些例子便是一些一直困擾很多程序員的代碼實例:

console.log(false == '0'); 

console.log(null == undefined); 

console.log(" \t\r\n" == 0); 

console.log('' == 0); // And these do too! 

if ({}) // ... 

if ([]) // ... 

  最后兩行的代碼雖然條件判斷為空(經(jīng)常會被人誤認為轉(zhuǎn)化為false),但是其實不管是{ }還是[ ]都是一個實體類,而任何的類其實都會轉(zhuǎn)化為true。就像這些例子所展示的那樣,其實有些類型強制轉(zhuǎn)化非常模糊。因此很多時候我們更愿意用 === 和 !== 來替代== 和 !=, 以此來避免發(fā)生強制類型轉(zhuǎn)化。. ===和!== 的用法和之前的== 和 != 一樣,只不過他們不會發(fā)生類型強制轉(zhuǎn)換。另外需要注意的一點是,當任何值與 NaN 比較的時候,甚至包括他自己,結(jié)果都是false。因此我們不能用簡單的比較字符來決定一個值是否為 NaN 。我們可以用內(nèi)置的 isNaN() 函數(shù)來辨別:

console.log(NaN == NaN);  // false 

console.log(NaN === NaN);  // false 

console.log(isNaN(NaN));  // true 

常見錯誤五:低效的DOM操作

  js中的DOM基本操作非常簡單,但是如何能有效地進行這些操作一直是一個難題。這其中最典型的問題便是批量增加DOM元素。增加一個DOM元素是一步花費很大的操作。而批量增加對系統(tǒng)的花銷更是不菲。一個比較好的批量增加的辦法便是使用 document fragments :

var div = document.getElementsByTagName("my_div"); 

var fragment = document.createDocumentFragment(); 

 for (var e = 0; e < elems.length; e++) { fragment.appendChild(elems[e]); } div.appendChild(fragment.cloneNode(true)); 

  直接添加DOM元素是一個非常昂貴的操作。但是如果是先把要添加的元素全部創(chuàng)建出來,再把它們?nèi)刻砑由先ゾ蜁咝Ш芏唷?/p>

常見錯誤六:在for循環(huán)中的不正確函數(shù)調(diào)用

請大家看以下代碼:

var elements = document.getElementsByTagName('input');

var n = elements.length; 

for (var i = 0; i < n; i++) {   

elements[i].onclick = function() {     

console.log("This is element #" + i);   }; } 

  運行以上代碼,如果頁面上有10個按鈕的話,點擊每一個按鈕都會彈出 “This is element #10”! 。這和我們原先預(yù)期的并不一樣。這是因為當點擊事件被觸發(fā)的時候,for循環(huán)早已執(zhí)行完畢,i的值也已經(jīng)從0變成了。

  我們可以通過下面這段代碼來實現(xiàn)真正正確的效果:

var elements = document.getElementsByTagName('input'); 

var n = elements.length; 

var makeHandler = function(num) { // outer function

   return function() { 

console.log("This is element #" + num);   }; }; 

for (var i = 0; i < n; i++) 

{   elements[i].onclick = makeHandler(i+1); } 

  在這個版本的代碼中, makeHandler 在每回循環(huán)的時候都會被立即執(zhí)行,把i+1傳遞給變量num。外面的函數(shù)返回里面的函數(shù),而點擊事件函數(shù)便被設(shè)置為里面的函數(shù)。這樣每個觸發(fā)函數(shù)就都能夠是用正確的i值了。

常見錯誤七:原型繼承問題

很大一部分的js開發(fā)者都不能完全掌握原型的繼承問題。下面具一個例子來說明:

BaseObject = function(name) {   

if(typeof name !== "undefined") 

{     this.name = name;   } 

else 

{     this.name = 'default'   } }; 

  這段代碼看起來很簡單。如果你有name值,則使用它。如果沒有,則使用 ‘default':

var firstObj = new BaseObject(); 

var secondObj = new BaseObject('unique'); 

console.log(firstObj.name); // -> 結(jié)果是'default' 

console.log(secondObj.name); // -> 結(jié)果是 'unique' 

  但是如果我們執(zhí)行delete語句呢:

delete secondObj.name;
  我們會得到:

console.log(secondObj.name); // -> 結(jié)果是 'undefined'
  但是如果能夠重新回到 ‘default'狀態(tài)不是更好么? 其實要想達到這樣的效果很簡單,如果我們能夠使用原型繼承的話:

BaseObject = function (name) 

{   if(typeof name !== "undefined") 

{     this.name = name;   } }; 

BaseObject.prototype.name = 'default'; 

  在這個版本中, BaseObject 繼承了原型中的name 屬性, 被設(shè)置為了 'default'.。這時,如果構(gòu)造函數(shù)被調(diào)用時沒有參數(shù),則會自動設(shè)置為 default。相同地,如果name 屬性被從BaseObject移出,系統(tǒng)將會自動尋找原型鏈,并且獲得 'default'值:

 var thirdObj = new BaseObject('unique'); 

 console.log(thirdObj.name); 

 delete thirdObj.name;

 console.log(thirdObj.name); // -> 結(jié)果是 'default' 

常見錯誤八:為實例方法創(chuàng)建錯誤的指引

  我們來看下面一段代碼:

var MyObject = function() {} 

 MyObject.prototype.whoAmI = function() {   

console.log(this === window ? "window" : "MyObj"); }; 

 var obj = new MyObject(); 

  現(xiàn)在為了方便起見,我們新建一個變量來指引 whoAmI 方法, 因此我們可以直接用 whoAmI() 而不是更長的obj.whoAmI():

var whoAmI = obj.whoAmI;
  接下來為了確保一切都如我們所預(yù)測的進行,我們可以將 whoAmI 打印出來:

console.log(whoAmI);
  結(jié)果是:

function () {   console.log(this === window ? "window" : "MyObj"); } 

  沒有錯誤!

  但是現(xiàn)在我們來查看一下兩種引用的方法:

obj.whoAmI(); // 輸出 "MyObj" (as expected) 

whoAmI();   // 輸出 "window" (uh-oh!) 

  哪里出錯了呢?

  原理其實和上面的第二個常見錯誤一樣,當我們執(zhí)行 var whoAmI = obj.whoAmI;的時候,新的變量 whoAmI 是在全局環(huán)境下定義的。因此它的this 是指window, 而不是obj!

  正確的編碼方式應(yīng)該是:

var MyObject = function() {} 

MyObject.prototype.whoAmI = function() {   

   console.log(this === window ? "window" : "MyObj"); }; 

var obj = new MyObject(); 

obj.w = obj.whoAmI;  // still in the obj namespace obj.whoAmI(); // 輸出 "MyObj" (as expected) 

obj.w();    // 輸出 "MyObj" (as expected) 

常見錯誤九:用字符串作為setTimeout 或者 setInterval的第一個參數(shù)

  首先我們要聲明,用字符串作為這兩個函數(shù)的第一個參數(shù)并沒有什么語法上的錯誤。但是其實這是一個非常低效的做法。因為從系統(tǒng)的角度來說,當你用字符串的時候,它會被傳進構(gòu)造函數(shù),并且重新調(diào)用另一個函數(shù)。這樣會拖慢程序的進度。

setInterval("logTime()", 1000); 

setTimeout("logMessage('" + msgValue + "')", 1000); 

另一種方法是直接將函數(shù)作為參數(shù)傳遞進去:

setInterval(logTime, 1000);  

setTimeout(function() { 

logMessage(msgValue); }, 1000); 

常見錯誤十:忽略 “strict mode”的作用

   “strict mode” 是一種更加嚴格的代碼檢查機制,并且會讓你的代碼更加安全。當然,不選擇這個模式并不意味著是一個錯誤,但是使用這個模式可以確保你的代碼更加準確無誤。

  下面我們總結(jié)幾條“strict mode”的優(yōu)勢:

  1. 讓Debug更加容易:在正常模式下很多錯誤都會被忽視掉,“strict mode”模式會讓Debug極致更加嚴謹。

  2. 防止默認的全局變量:在正常模式下,給一個為經(jīng)過聲明的變量命名將會將這個變量自動設(shè)置為全局變量。在strict模式下,我們?nèi)∠诉@個默認機制。

  3. 取消this的默認轉(zhuǎn)換:在正常模式下,給this關(guān)鍵字指引到null或者undefined會讓它自動轉(zhuǎn)換為全局。在strict模式下,我們?nèi)∠诉@個默認機制。

  4. 防止重復(fù)的變量聲明和參數(shù)聲明:在strict模式下進行重復(fù)的變量聲明會被抱錯,如(e.g., var object = {foo: "bar", foo: "baz"};) 同時,在函數(shù)聲明中重復(fù)使用同一個參數(shù)名稱也會報錯,如 (e.g., function foo(val1, val2, val1){}),

  5. 讓eval()函數(shù)更加安全。

  6. 當遇到無效的delete指令的事后報錯:delete指令不能對類中未有的屬性執(zhí)行,在正常情況下這種情況只是默默地忽視掉,而在strict模式是會報錯的。

正如和其他的技術(shù)語言一樣,你對JavaScript了解的的越深,知道它是如何運作,為什么這樣運作,你才會熟練地掌握并且運用這門語言。相反地,如果你缺少對JS模式的認知的話,你就會碰上很多的問題。了解JS的一些細節(jié)上的語法或者功能將會有助于你提高編程的效率,減少變成中遇到的問題。

相關(guān)文章

  • JavaScript如何實現(xiàn)數(shù)組按屬性分組

    JavaScript如何實現(xiàn)數(shù)組按屬性分組

    在JavaScript中,有多種方法可以對數(shù)組按屬性進行分組,這篇文章主要為大家至少介紹了6種常見的方法,感興趣的小伙伴可以跟隨小編一起學習一下
    2023-08-08
  • 微信小程序制作扭蛋機代碼實例

    微信小程序制作扭蛋機代碼實例

    這篇文章主要介紹了微信小程序制作扭蛋機代碼實例,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
    2019-09-09
  • 原生js實現(xiàn)簡易抽獎系統(tǒng)

    原生js實現(xiàn)簡易抽獎系統(tǒng)

    這篇文章主要為大家詳細介紹了原生js實現(xiàn)簡易抽獎系統(tǒng),文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2022-03-03
  • 談?wù)凱HP中相對路徑的問題與絕對路徑的使用

    談?wù)凱HP中相對路徑的問題與絕對路徑的使用

    經(jīng)??吹接腥瞬仍诹薖HP路徑的坑上面了,感覺有必要來說說PHP中相對路徑的一些坑,以及PHP中絕對路徑的使用,下面一起來看看。
    2016-08-08
  • 復(fù)選框全選與全不選操作實現(xiàn)思路

    復(fù)選框全選與全不選操作實現(xiàn)思路

    通過js簡單實現(xiàn)下復(fù)選框全選與全不選,很常用的一個操作,具體實現(xiàn)思路及代碼如下,有需求的朋友可以參考下,希望對大家有所幫助
    2013-08-08
  • js千分位實現(xiàn)方法大匯總

    js千分位實現(xiàn)方法大匯總

    這篇文章主要介紹了js千分位實現(xiàn)方法大匯總,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-04-04
  • javascript實現(xiàn)div浮動在網(wǎng)頁最頂上并帶關(guān)閉按鈕效果實例

    javascript實現(xiàn)div浮動在網(wǎng)頁最頂上并帶關(guān)閉按鈕效果實例

    我們有時會看到有些網(wǎng)站最頂部一直會跟著我們滾動而滾動了,這種方法其實很簡單,下面我來給大推薦一個javascript實現(xiàn)div浮動在網(wǎng)頁最頂上并帶關(guān)閉按鈕效果
    2013-08-08
  • 一不小心就做錯的JS閉包面試題

    一不小心就做錯的JS閉包面試題

    這篇文章為大家推薦了許多經(jīng)典的JS閉包面試題,也可以說是一不小心就做錯的JS閉包面試題,感興趣的小伙伴們可以參考一下,自己試著解答這些大部分人都會做錯的JS閉包面試題,檢驗自己的知識水平
    2015-11-11
  • js中判斷兩個數(shù)組對象是否完全相等

    js中判斷兩個數(shù)組對象是否完全相等

    這篇文章主要介紹了js中判斷兩個數(shù)組對象是否完全相等方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2023-04-04
  • 微信小程序使用image組件顯示圖片的方法【附源碼下載】

    微信小程序使用image組件顯示圖片的方法【附源碼下載】

    這篇文章主要介紹了微信小程序使用image組件顯示圖片的方法,結(jié)合實例形式簡單分析了微信小程序附image組件的相關(guān)使用技巧,并附帶源碼供讀者下載參考,需要的朋友可以參考下
    2017-12-12

最新評論