总结几个JavaScript中易犯的小错误

1KE 发布于 2015/05/19 15:52
阅读 253
收藏 5
常见错误一:对于this关键词的不正确引用

我曾经听一位喜剧演员说过:

“我从未在这里,因为我不清楚这里是哪里,是除了那里之外的地方吗?”

这句话或多或少地暗喻了在js开发中开发者对于this关键字的使用误区。This指代的是什么?它和日常英语口语中的this是一个意思吗?


随着近些年js编程不断地复杂化,功能多样化,对于一个程序结构的内部指引、引用也逐渐变多起来

下面让我们一起来看这一段代码:


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

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

 };

运行上面的代码将会出现如下错误:


Uncaught TypeError: undefined is not a function

这是为什么?

this的调用和它所在的环境密切相关。之所以会出现上面的错误,是因为当你在调用 setTimeout()函数的时候, 你实际调用的是window.setTimeout(). 因此,在 setTimeout() 定义的函数其实是在window背景下定义的,而window中并没有 clearBoard() 这个函数方法。

下面提供两种解决方案第一种比较简单直接的方法便是,把this存储到一个变量当中,这样他就可以在不同的环境背景中被继承下来:


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

    var self = this;

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

第二种方法便是用bind()的方法,不过这个相比上一种要复杂一些,对于不熟悉bind()的同学可以在微软官方查看它的使用方法:bind 方法 (Function) (JavaScript)


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

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

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

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


常见错误二:传统编程语言的生命周期误区
另一种易犯的错误,便是带着其他编程语言的思维,认为在JS中,也存在生命周期这么一说。请看下面的代码:for (var i = 0; i < 10; i++) { /* ... */ } console.log(i);
如果你认为在运行console.log() 时肯定会报出 undefined 错误,那么你就大错特错了。我会告诉你其实它会返回 10吗。
当然,在许多其他语言当中,遇到这样的代码,肯定会报错。因为i明显已经超越了它的生命周期。在for中定义的变量在循环结束后,它的生命也就结束了。但是在js中,i的生命还会继续。这种现象叫做  variable hoisting
而如果我们想要实现和其他语言一样的在特定逻辑模块中具有生命周期的变量,可以用let关键字。


常见错误三:内存泄露
内存泄露在js变成中几乎是一个无法避免的问题。如果不是特别细心的话,在最后的检查过程中,肯定会出现各种内存泄露问题。
下面我们就来举例说明一下:
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);
如果运行上面的代码,你会发现你已经造成了大量的内存泄露,每秒泄露1M的内存,显然光靠GC(垃圾回收器)是无法帮助你的了。由上面的代码来看,似乎是longstr在每次replaceThing调用的时候都没有得到回收。这是为什么呢?

每一个theThing结构都含有一个longstr结构列表。每一秒当我们调用 replaceThing, 它就会把当前的指向传递给 priorThing. 但是到这里我们也会看到并没有什么问题,因为 priorThing 每回也是先解开上次函数的指向才会接受新的赋值。并且所有的这一切都是发生在 replaceThing 函数体当中,按常理来说当函数体结束之后,函数中的本地变量也将会被GC回收,也就不会出现内存泄露的问题了,但是为什么会出现上面的错误呢?

这是因为longstr的定义是在一个闭包中进行的,而它又被其他的闭包所引用,js规定,在闭包中引入闭包外部的变量时,当闭包结束时此对象无法被垃圾回收(GC) 。关于在JS中的内存泄露问题可以查看 Memory leaks

常见错误四:比较运算符

JavaScript中一个比较便捷的地方,便是它可以给每一个在比较运算的结果变量强行转化成布尔类型。但是从另一方面来考虑,有时候它也会为我们带来很多不便,下面的这些例子便是一些一直困扰很多程序员的代码实例:


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

console.log(null == undefined); 

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

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

if ({}) // ... 

if ([]) // ...

最后两行的代码虽然条件判断为空(经常会被人误认为转化为false),但是其实不管是{ }还是[ ]都是一个实体类,而任何的类其实都会转化为true。就像这些例子所展示的那样,其实有些类型强制转化非常模糊。因此很多时候我们更愿意用 === 和 !== 来替代== 和 !=, 以此来避免发生强制类型转化。. ===和!== 的用法和之前的== 和 != 一样,只不过他们不会发生类型强制转换。另外需要注意的一点是,当任何值与 NaN 比较的时候,甚至包括他自己,结果都是false。因此我们不能用简单的比较字符来决定一个值是否为 NaN。我可以用内置的 isNaN() 函数来辨别:


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

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

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


常见错误五:低效的DOM操作

js中的DOM基本操作非常简单,但是如何能有效地进行这些操作一直是一个难题。这其中最典型的问题便是批量增加DOM元素。增加一个DOM元素是一步花费很大的操作。而批量增加对系统的花销更是不菲。一个比较好的批量增加的办法便是使用 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元素是一个非常昂贵的操作。但是如果是先把要添加的元素全部创建出来,再把它们全部添加上去就会高效很多。

常见错误6:原型继承问题

很大一部分的js开发者都不能完全掌握原型的继承问题。下面具一个例子来说明:


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);  // -> 结果是'default' 

console.log(secondObj.name); // -> 结果是 'unique'

但是如果我们执行delete语句呢:


delete secondObj.name;

我们会得到:


console.log(secondObj.name); // -> 结果是 'undefined'

但是如果能够重新回到 ‘default’状态不是更好么? 其实要想达到这样的效果很简单,如果我们能够使用原型继承的话:


BaseObject = function (name) 

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

{         this.name = name;     } };  

BaseObject.prototype.name = 'default';

在这个版本中, BaseObject 继承了原型中的name 属性, 被设置为了 'default'.。这时,如果构造函数被调用时没有参数,则会自动设置为 default。相同地,如果name 属性被从BaseObject移出,系统将会自动寻找原型链,并且获得 'default'值:


var thirdObj = new BaseObject('unique'); 

 console.log(thirdObj.name);  

 delete thirdObj.name;

 console.log(thirdObj.name);  // -> 结果是 'default'


常见错误7:忽略 “strict mode”的作用

“strict mode” 是一种更加严格的代码检查机制,并且会让你的代码更加安全。当然,不选择这个模式并不意味着是一个错误,但是使用这个模式可以确保你的代码更加准确无误。

下面我们总结几条“strict mode”的优势:

1. 让Debug更加容易:在正常模式下很多错误都会被忽视掉,“strict mode”模式会让Debug极致更加严谨。

2. 防止默认的全局变量:在正常模式下,给一个为经过声明的变量命名将会将这个变量自动设置为全局变量。在strict模式下,我们取消了这个默认机制。

3. 取消this的默认转换:在正常模式下,给this关键字指引到null或者undefined会让它自动转换为全局。在strict模式下,我们取消了这个默认机制。

4. 防止重复的变量声明和参数声明:在strict模式下进行重复的变量声明会被抱错,如(e.g., var object = {foo: "bar", foo: "baz"};) 同时,在函数声明中重复使用同一个参数名称也会报错,如 (e.g., function foo(val1, val2, val1){}),

5. 让eval()函数更加安全。

6. 当遇到无效的delete指令的事后报错:delete指令不能对类中未有的属性执行,在正常情况下这种情况只是默默地忽视掉,而在strict模式是会报错的。

加载中
返回顶部
顶部