谈谈 JavaScript 中的 this

JavaScript 中的 this 经常会表现得让人抓摸不透，甚至让新手感到疑惑不解。

有些文章为了讲解 this，甚至有时会将它和其他概念混在一起讲解，但这只会让人更加疑惑，最后彻底迷失在这些概念中。

本文主要目标就是剔除这些概念的混淆，从本质上看清楚 this。在理解 this 的概念后，根据这些理解我会给出一些合理的建议。

理解 Lexical Scoping 和 Dynamic Scoping

在弄清 this 之前，需要理解静态作用域(Lexical Scoping，简称 LS ) 和 动态作用域(Dynamic Scoping，简称 DS ) 的概念。LS 和 DS 涉及到语言设计的层面，它们是不同类型的作用域。虽然在大多数情况下，它们表现类似，但在有些情况下，它们会表现出微妙的差别。而这些差别，真是我们被 this 迷惑的原因。

下面的这段代码，可以分辨出一种语言的作用域是 LS 还是 DS。

var a = 'I am Lexical Scoping'  // a1
var b = function () {
  console.log(a)
}

var c = function () {
  var a = 'I am Dynamic Scoping'    // a2
  b()
}

c()     // I am Lexical Scoping

将这代码复制黏贴到浏览器的控制台，就会发现 JavaScript 是 LS 的。

LS 和 DS 最根本的区别在于，它们对函数中的自由变量（上面例子中的 a 变量）具有不同的处理方式。

LS 会在函数声明的时候保存该函数所需要的自由变量(上面例子中的 a1)，并且在函数执行的时候调用前面保存的自由变量(上面例子中的 a1)。

DS 会在函数执行的时候寻找该函数所需要的自由变量(上面例子中的 a2)。因此在 DS 的语言中，上面的例子的执行结果应该是 'I am Dynamic Scoping'。

尽管 DS 更具有灵活性，因为如果能够允许函数的自由变量在执行的时候确定的话，那么一个函数就能在不同的上下文中表现出不同的效果。然而当我们写代码需要用到自由变量的时候，更倾向于在声明的时候确定自由变量。在这种情况下，DS 隐蔽的灵活性将是一场灾难。更致命的是，DS 破坏了函数的封闭性，函数不再作为一个黑箱，而有可能因为环境的变化而表现不同，导致耦合的产生。

假设例子中的 函数b 在另一个文件被调用，而那个文件中恰好声明了一个 变量a，那么就很可能会导致很多奇怪的事情发生。因为对于调用者而言，函数b 应该是一个黑盒，他不应该也没有义务费心思去了解 函数b 中有哪些自由变量。

出于以上的种种原因，现代语言几乎都采用 LS，而 JavaScript 自然也采用了 LS。但是 JavaScript 有一个致命的缺陷，那就是 JavaScript 中的 this 更倾向于表现得像 DS。

this 让人疑惑的原因

在 JavaScript 中，this 是在函数执行的时候才确定下来的(箭头函数除外)。

将上面的小例子转换下，得到下面的例子，就可以看出问题所在。

var name = 'I am window'
var a1 = {
  name: 'I am Lexical',
  b: function () {
    // this 是在函数执行的时候确定
    console.log(this.name)
  }
}

var c = function () {
  var a2 = {
    name: 'I am Dynamic'
  }
  a2.b = a1.b
  a2.b()
}

c()     // I am Dynamic

而这就是 JavaScript 中的 this 表现得让人疑惑的根本原因。

箭头函数

为了解决这个问题，ES6 引入了箭头函数。箭头函数有一个重要的特点，就是在箭头函数的 this 是在函数定义的时候确定下来的，并且不管用 bind，call 还是 apply，箭头函数中的 this 都不会改变。怎么样，听起来很像静态作用域对不对。

将上面例子中 函数b 的定义变成箭头函数。

var name = 'I am window'
var a1 = {
  name: 'I am Lexical',
  // 函数b变成箭头函数
  b: () => {
    console.log(this.name)
  }
}

var c = function () {
  var a2 = {
    name: 'I am Dynamic'
  }
  a2.b = a1.b
  a2.b()
}

c()     // I am window

你会发现结果并不是我们希望看到的 'I am Lexical'，而是 'I am window'。

这是因为每个普通函数(非箭头函数)会在其执行的时候，通过执行时候的上下文生成一个属于自己的 this。

而箭头函数虽然会在声明的时候确定它的 this ，但是却不会生成一个新的this，而是借用当前上下文所指向的 this 来作为自身的 this。

从上一个例子和接下来的例子，都可以看出来。

var name = 'I am window'
var a1 = {
  name: 'I am Lexical',
  bCreator: function () {
    return () => {
      // 该 this 为 bCreator 所产生的 this
      console.log(this.name)
    }
  }
}

// 在这里 函数bCreator 执行的时候生成了一个 this 指向 a1
// 函数b 借用了由 bCreator函数生成的 this
a1.b = a1.bCreator()

var c = function () {
  var a2 = {
    name: 'I am Dynamic'
  }
  a2.b = a1.b
  a2.b()    // 函数b 中的 this 一直指向 a1
}

c()     // I am Lexical

何时使用 this

由于普通函数下的 this 的表现是如此诡异，在我们使用函数的时候，我们应该尽量确保函数中的 this 不变。

比如尽管我们在 class 的定义中使用了普通函数，但可以通过在 constructor 的时候对普通函数进行 bind 而使其 this 不变。而对于其他情况则应该用箭头函数来保证这种不变性。

class View {
  constructor (name) {
    this.name = name
    this.handler = this.handler.bind(this)  // good part
  }

  handler () {
    console.log(this.name)
  }
}

最不应该的就是尝试利用普通函数的“动态” this 来“增加”该函数的功能。

如果一个函数需要在不同上下文中表现不同的特点，最好的方法应该是把上下文作为参数显示地传递进去。而不是通过偷偷地改变函数的 this 来做到这一点。同时也尽量避免用 apply，call 等来改变 this。

对于前面的例子，如果需要 函数b 在不同的对象中表现得不一样，最好的方法应该是下面这种方法。

var name = 'I am window'
var a1 = {
  name: 'I am Lexical',
  // 将上下文作为参数显示地传递进函数
  b: function (ctx) {
    console.log(ctx.name)
  }
}

var c = function () {
  var a2 = {
    name: 'I am Dynamic'
  }
  a2.b = a1.b
  a2.b(a2)  // 在函数执行的时候确定好 ctx
}

c()     // I am Dynamic

这种方式清晰明了，而且 ctx 同样是在函数执行的时候确定，不会减弱其灵活性。

总结

总体而言，通过保证函数的 this 的不变性，可以让我们的思想负担变轻，因为我们不需要每次调用一个函数的 this 的时候，都考虑它会不会变的情况。这也让一些很隐晦的 bug 无处藏身。

当你需要改变 this 的时候，你需要的可能不是 this，而是一个普通的参数。

Just keep it simple and make your life easy.