Javascript 中的上下文

js 中的 上下文 Context，能够说是一个，你即便不知道，没听过，也不影响你继续写 js 代码的一个概念。可是，它又确确实实是无所不在的一个东西，是的，无所不在。

从我本身的经验来看，对上下文的认识，算是分红了三个阶段，每个阶段，都让我从外在的表现中，理解了一些更本质上的东西。

1. 第一阶段，不知

我最开始接触 js 的时候，看到了它的 new ，看到了它的 this ，很天然地会把 js 和其它的一些 OOP 语言等同起来看待，而且，好像，也是这么回事。好比：

var Class = function(a){ this.a = a; this.add = function(){ this.a++;
  }
} var ins = new Class(1);
ins.add();
console.log(ins.a); //2

上面的代码，能够按预期的那样，最后获得 2 的输出。

可是，若是仅仅是 类，实例 这种层面的认识，我没法解释下面的问题：

var ins = new Class(1); var func = ins.add;
func();
console.log(ins.a); //1

甚至解释不清楚下面的代码：

var obj = {
  a: 1,
  add: function(){ this.a++;
  }
}
obj.add();
console.log(obj.a); //2

这里可没有 类 ，也没有 实例 。

我上面的最开始对 js 的认识当中，局限就在于，把 this 理解成了 实例 。也许在其它语言中（好比 Python 经常使用的实例方法第一个参数 self），是这样。可是在 js 中， this 跟 实例 彻底没有关系。

2. 第二阶段，this

当我明白问题出在 this 上，或者说，当我终于理解了 this 这个东西以后，上面的代码，不再会困扰我了。

我知道了， js 中有一个东西叫 上下文 ，惋惜的是，这时，我对上下文的概念，仅仅停留在 this上。

这时个人理解是： this 表示的是，函数调用时的 上下文 。

说得详细一点，就是 this 不是表示的 实例 ，而是函数调用时的 上下文 。 上下文 这个东西，默认是 window ，即 全局 。可是，你能够明确地为函数指定一个 上下文 。回到 this 上，就是在定义时你根本不知道 this 是什么，由于在调用时，它能够是任何东西（由于 上下文 是能够人为指定的）。

回到刚开始的代码：

var Class = function(a){ this.a = a; this.add = function(){ this.a++;
  }
} var ins = new Class(1);
ins.add();
console.log(ins.a); //2

这段代码的结构之因此是 2 ，不是由于 实例 ，而是由于 上下文 。

首先说一下 new 。 new 在 js 中，不考虑原型链它的做用，至关因而先建立了一个空的对象，而后把这个空的对象，做为 构造函数 的 上下文 ，再去执行 构造函数 ，最后再返回这个当初的空对象。即：

var what_new = function(func, a){ var context = {};
  func.apply(context, [a]); return context;
} var Class = function(a){ this.a = a; this.add = function(){ this.a++;
  }
} var ins = what_new(Class, 1);
ins.add();
console.log(ins.a);

固然， new 除了上面的 func.apply 的做用以外， 它还会处理原型链 ，这里就不介绍了。上面的代码仅是为了说明 new 对于所谓的构造函数作了什么事。

有了上下文，就不难解释 ins 这个东西了。所谓的构造函数，只是在指定了 this 究竟是哪个对象以后，做了相应的赋值操做而已，最后获得这个对象的返回，通过了一些赋值操做，对象中就有了新的东西了。

一样，对于一个在定义时包含了 this 的函数，好比前面的例子：

var obj = {
  a: 1,
  add: function(){ this.a++;
  }
}

若是来一句：

var func = obj.add;
func(); //undefined func.apply({a: 0}) //1

这些都很容易明白了。 js 中的函数，都是一些很单纯的函数，全部的函数跟它在哪里定义彻底没有关系（考虑闭包的状况除外）。因此上面的代码，虽然 add 函数是写在 obj 中的，可是，它跟你在window 中写一个函数是 彻底同样 的：

var add = function(){this.a++} var obj = {
  a: 1,
  add: add
}

既然 add 函数中有 this ，那么这个函数执行时的行为，就要当心一点了。因此上面明确地指定了一个上下文给它 func.apply({a: 0}) 。

仍是回到开始的代码：

var obj = {
  a: 1,
  add: function(){ this.a++;
  }
}

对于上面的代码，我知道了：

obj.add();

和：

var func = obj.add();
func();

会获得不同的结果。而且知道，这个不同的结果是上下文引发的，还知道，后者 func() 执行时，上下文是全局的 window 了。

我虽然知道是这样的一个状况，可是，为何？执行同一个函数结果怎么就不同了呢？

我在很长时间里，都没有去细细考虑过这个问题。不过，由于知道了“上下文是一个在定义时无心义，其具体值彻底由执行时决定”这点以后，我都尽可能避免去使用 this ，实在要用，在调用时，我都会经过 apply 或 call 明确指定上下文，这样，至少不会踩坑里。

3. 第三阶段，一切都是上下文

某天，我在网上看到了这样一段代码（原始出处不知道）：

var bind = Function.prototype.call.bind(Function.prototype.bind)

这个新定义的 bind 函数具体作什么事先无论它，我好奇的是 call.bind() 这个调用。由于 call这个函数，以前一直觉得它是 Function 对象的一个方法（它自己也是一个函数），可是，若是按“对象的方法”这个角度去想的话，那对它绑定一个上下文（ bind() 的调用 ）不就彻底没有意义了么？（由于对象的方法应该是跟上下文无关的）

后来看到了这篇文章， http://www.html-js.com/article/JavaScript-functional-programming-in-Javascript-Bind-Call-and-Apply

其中以 slice 函数举的例子让我恍然大悟：

• 上下文控制不只仅是 apply / call，全部的点 . ，都是在指定上下文。
• js 中的函数比我想像的还要纯，根本没有“对象中的方法”这个东西，即便是“原生对象”中。（它仅仅起一个名字空间的做用）

全部的函数调用，都有两层意义，好比 c.f()：

• f 这个函数，它在 c 中。（名字空间的问题）
• 把 c 做为 f 的上下文，去调用 f 。（前提是 f 没有绑定过上下文）

若是 c 没有，则默认是 window 。

全部的，js 中全部的函数调用，都是如此。即便是 f.call(context, x) ，我以前只看到了第一层意义（ f 中有一个 call 方法可使用），则忽略了第二层意义 —— 把 f 做为 call 的上下文。

简单来讲，咱们能够相像 call 这个函数，它的代码大概是这样的（可变参数的问题先无论）：

var call = function(context, a){ var new_func = this.bind(context);
    retur new_func(a);
}

它的做用，就是把 指定的上下文（context） 做为 本身的上下文（this） 的 上下文 ，而后再调用 本身的上下文（绑定上下文以后的 this） 。

上面一句话有些纠结哈，主要搞明白多种上下文的关系， f.call(context, x) 当中， 本身的上下文 上面是 f 。 指定的上下文 上面是 context 。

再看 f.call(context, x) 这个代码，结合“函数是单纯”这点，我想到，即便是原生对象的那些方法， 也不过是把一些单纯的函数放到了 prototype 中而已 ，好比把 call 函数放到了Function.prototype 当中。

至此，再看 c.f() ， a.b.c() 这些，不要去想是调用 c 对象中的 f 方法（这么说没错，可是名字空间的问题是显而易见的嘛），而是想成，调用时把 c 做为 f 的上下文。

好了，回到开始的那行例子：

var new_bind = Function.prototype.call.bind(Function.prototype.bind)

这个就很是好理解了（为了描述方便，我改为 new_bind 了），把 bind 做为上下文绑定到 call中。

这里注意一下，绑定了上下文的 call 函数，仍是 call 函数，可是 “此 call 已经非彼 call” 了。

因此：

new_bind != Function.prototype.call

虽然调用形式上， new_bind 和 call 彻底同样，可是他们的上下文行为不同：

• call 是未绑定状态，因此 f.call() 会在执行时把 f 做为上下文绑定到 call 函数中。
• new_bind 是已绑定状态，因此 f.new_bind() 对 new_bind() 的执行彻底没影响。

咱们能够以这样的流程来帮助咱们理解：

new_bind => call => bind.call => bind.call(f, context) => f.bind(context)

一步一步解释：

new_bind => callnew_bind 在形式上就是 call 。call => bind.call只是这个 call ，是指定了 bind 做为它的上下文的。既然是 bind 做为它的上下文，那咱们能够写成是bind.call 的样式。bind.call(f, context) => f.bind(context)new_bind 的调用 new_bind(f, context) 就至关因而 bind.call(f, context) 。考虑 call 函数以前的行为： f.call(context, a) 是把 context 做为 f 的上下文，也就是 context.f(a) ，那么bind.call(f, context) 对应的就是 f.bind(context) 。f.bind(context)不用多说了吧，把 context 绑定到 f 上，返回一个绑定了上下文的新函数。

彻底是最基本的代数推导嘛，形式上，上下文前置老是没有问题的。

4. 结语

我一直认同，要理解 js 的东西，从函数式语言入手，很是合适。硬要往面向对象的那套东西上套，太纠结了（我无论概念上到底什么样才叫面向对象，原生没有类定义，没有继承，没有实例化，就别扯这些就完了。对了，我认为原型追溯那不叫继承哈）。

固然，我不知道弄明白了最后那个“代数推导”到底有什么好处，也许没有，由于就算不明白这些也不影响我写了不少能够正常工做的 js 代码嘛。只是，我之后再写，思路上的可能会有一些不一样了。好比代码组织的形式上，能够尝试把不少的小函数作到不一样的“名字空间”中，而后再在业务层面，经过Mixin 来拼出不一样的业务对象。这些函数中可能处处充斥着 this ，我能控制好它们了