Skip to content

[zz] Scope in JavaScript

2007/07/23

Scope in JavaScript

Published on September 11, 2006

Scope is one of the foundational aspects of the JavaScript language, and probably the one I’ve struggled with the most when building complex programs. I can’t count the number of times I’ve lost track of what the this keyword refers to after passing control around from function to function, and I’ve often found myself contorting my code in all sorts of confusing ways, trying to retain some semblance of sanity in my understanding of which variables were accessible where.

In typical object-oriented programming, we need a way of identifying and referring to the object that we’re currently working with. this serves the purpose admirably, providing our objects the ability to examine themselves, and point at their own properties.

This article will tackle the problem head-on, outlining definitions of context and scope, examining two JavaScript methods that allow us to manipulate context, and concluding with a deep dive into an effective solution to ninety percent of the problems I’ve run into.

Where Am I? And Who Are You?

Every bit of your JavaScript program is executed in one execution context or another. You can think of these contexts as your code’s neighborhood, giving each line an understanding of where it comes from, and who its friends and neighbors are. As it turns out, this is important information, as JavaScript societies have fairly strict rules about who can associate with whom; execution contexts are better thought of as gated communities than as open subdivisions.

We can refer to these social boundaries generally as scope, and they’re important enough to be codified in each neighborhood’s charter, which we’ll refer to as the context’s scope chain. Code within a particular neighborhood can only access variables listed on its scope chain, and prefers interaction with locals to associations outside its neighborhood.

Practically speaking, evaluating a function establishes a distinct execution context that appends its local scope to the scope chain it was defined within. JavaScript resolves identifiers within a particular context by climbing up the scope chain, moving locally to globally. This means that local variables with the same name as variables higher up on the scope chain take precedence, which makes sense: If my good friends are talking together about “Mike West,” it’s pretty clear that they’re talking about me, not about the bluegrass singer or the Duke professor, even though the latter two are (arguably) better known.

Let’s walk through some example code to explore the implications:

<script type="text/javascript">
 var ima_celebrity = "Everyone can see me! I'm famous!",
  the_president = "I'm the decider!";
 
 function pleasantville() {
  var the_mayor = "I rule Pleasantville with an iron fist!",
   ima_celebrity = "All my neighbors know who I am!";
 
  function lonely_house() {
   var agoraphobic = "I fear the day star!",
    a_cat = "Meow.";
  }
 }
</script>

Our global star, ima_celebrity, is recognized by everyone. She’s politically active, talking with the_president on a fairly frequent basis, and incredibly friendly; she’ll sign autographs and answer questions for anyone she runs into. That said, she doesn’t have a whole lot of personal contact with her fans. She’s pretty sure they exist and that they probably have lives of their own somewhere, but she certainly doesn’t know what they’re doing, or even their names.

Inside pleasantville, the_mayor is a well-known face. She’s always walking the streets of her town, chatting up her constituents, shaking hands, and kissing babies. As pleasantville is a big, important neighborhood, she’s got a big red phone in her office, giving her a direct line to the president (or at least a top aide) 24 hours a day, 7 days a week. She’s seen lonely_house up on a hill at the outskirts of town, but never really worried about who lives inside.

That lonely_house is a world unto itself. The agoraphobic stays inside most of the time, playing solitaire and feeding a_cat. He’s called the_mayor a few times to ask about local noise regulations, and even wrote ima_celebrity (Pleasantville’s ima_celebrity, that is) some fan mail after seeing her on the local news.

this? What’s that?

In addition to establishing a scope chain, each execution context offers a keyword named this. In its most common usage, this serves as an identity function, providing our neighborhoods a way of referring to themselves. We can’t always rely on that behavior, however: Depending on how we get into a particular neighborhood, this might mean something else entirely. In fact, how we get into the neighborhood is itself exactly what this generally refers to. Four scenarios deserve special attention:

  • Calling an Object’s Method

    In typical object-oriented programming, we need a way of identifying and referring to the object that we’re currently working with. this serves the purpose admirably, providing our objects the ability to examine themselves, and point at their own properties.

     <script type="text/javascript">
      var deep_thought = {
       the_answer: 42,
       ask_question: function () {
        return this.the_answer;
       }
      };
     
      var the_meaning = deep_thought.ask_question();
     </script>

    This example builds an object named deep_thought, sets its the_answer property to 42, and creates an ask_question method. When deep_thought.ask_question() is executed, JavaScript establishes an execution context for the function call, setting this to the object referenced by whatever came before the last ”.”, in this case: deep_thought. The method can then look in the mirror via this to examine its own properties, returning the value stored in this.the_answer: 42.

  • Constructor

    Likewise, when defining a function to be used as a constructor with the new keyword, this can be used to refer to the object being created. Let’s rewrite the example above to reflect that scenario:

     <script type="text/javascript">
      function BigComputer(answer) {
       this.the_answer = answer;
       this.ask_question = function () {
        return this.the_answer;
       }
      }
     
      var deep_thought = new BigComputer(42);
      var the_meaning = deep_thought.ask_question();
     </script>

    Instead of explicitly creating the deep_thought object, we’ll write a function to create BigComputer objects, and instantiate deep_thought as an instance variable via the new keyword. When new BigComputer() is executed, a completely new object is created transparently in the background. BigComputer is called, and its this keyword is set to reference that new object. The function can set properties and methods on this, which is transparently returned at the end of BigComputer’s execution.

    Notice, though, that deep_thought.the_question() still works just as it did before. What’s going on there? Why does this mean something different inside the_question than it does inside BigComputer? Put simply, we entered BigComputer via new, so this meant “the new object.” On the other hand, we entered the_question via deep_thought, so while we’re executing that method, this means “whatever deep_thought refers to”. this is not read from the scope chain as other variables are, but instead is reset on a context by context basis.

  • Function Call

    What if we just call a normal, everyday function without any of this fancy object stuff? What does this mean in that scenario?

     <script type="text/javascript">
      function test_this() {
       return this;
      }
      var i_wonder_what_this_is = test_this();
     </script>

    In this case, we weren’t provided a context by new, nor were we given a context in the form of an object to piggyback off of. Here, this defaults to reference the most global thing it can: for web pages, this is the window object.

  • Event Handler

    For a more complicated twist on the normal function call, let’s say that we’re using a function to handle an onclick event. What does this mean when the event triggers our function’s execution? Unfortunately, there’s not a simple answer to this question.

    If we write the event handler inline, this refers to the global window object:

     <script type="text/javascript">
      function click_handler() {
       alert(this); // alerts the window object
      }
     </script>
     ...
     <button id='thebutton' onclick='click_handler()'>Click me!</button>

    However, when we add an event handler via JavaScript, this refers to the DOM element that generated the event. (Note: The event handling shown here is short and readable, but otherwise poor. Please use a real addEvent function instead.):

     <script type="text/javascript">
      function click_handler() {
       alert(this); // alerts the button DOM node
      }
     
      function addhandler() {
       document.getElementById('thebutton').onclick = click_handler;
      }
     
      window.onload = addhandler;
     </script>
     ...
     <button id='thebutton'>Click me!</button>

Complications

Let’s run with that last example for a moment longer. What if instead of running click_handler, we wanted to ask deep_thought a question every time we clicked the button? The code for that seems pretty straightforward; we might try this:

<script type="text/javascript">
 function BigComputer(answer) {
  this.the_answer = answer;
  this.ask_question = function () {
   alert(this.the_answer);
  }
 }
 
 function addhandler() {
  var deep_thought = new BigComputer(42),
   the_button = document.getElementById('thebutton');
 
  the_button.onclick = deep_thought.ask_question;
 }
 
 window.onload = addhandler;
</script>

Perfect, right? We click on the button, deep_thought.ask_question is executed, and we get back “42.” So why is the browser giving us undefined instead? What did we do wrong?

The problem is simply this: We’ve passed off a reference to the ask_question method, which, when executed as an event handler, runs in a different context than when it’s executed as an object method. In short, the this keyword in ask_question is pointing at the DOM element that generated the event, not at a BigComputer object. The DOM element doesn’t have a the_answer property, so we’re getting back undefined instead of “42.” setTimeout exhibits similar behavior, delaying the execution of a function while at the same time moving it out into a global context.

This issue crops up all over the place in our programs, and it’s a terribly difficult problem to debug without keeping careful track of what’s going on in all the corners of your program, especially if your object has properties that do exist on DOM elements or the window object.

Manipulating Context With .apply() and .call()

We really do want to be able to ask deep_thought a question when we click the button, and more generally, we do want to be able to call object methods in their native context when responding to things like events and setTimeout calls. Two little-known JavaScript methods, apply and call, indirectly enable this functionality by allowing us to manually override the default value of this when we execute a function call. Let’s look at call first:

<script type="text/javascript">
 var first_object = {
  num: 42
 };
 var second_object = {
  num: 24
 };
 
 function multiply(mult) {
  return this.num * mult;
 }
 
 multiply.call(first_object, 5); // returns 42 * 5
 multiply.call(second_object, 5); // returns 24 * 5
</script>

In this example, we first define two objects, first_object and second_object, each with a num property. Then we define a multiply function that accepts a single argument, and returns the product of that argument, and the num property of its this object. If we called that function by itself, the answer returned would almost certainly be undefined, since the global window object doesn’t have a num property unless we explicitly set one. We need some way of telling multiply what its this keyword ought refer to; the call method of the multiply function is exactly what we’re looking for.

The first argument to call defines what this means inside the executed function. The remaining arguments to call are passed into the executed function, just as if you’d called it yourself. So, when multiply.call(first_object, 5) is executed, the multiply function is called, 5 is passed in as the first argument, and the this keyword is set to refer to object first_object. Likewise, when multiply.call(second_object, 5) is executed, the multiply function is called, 5 is passed in as the first argument, and the this keyword is set to refer to object second_object.

apply works in exactly the same way as call, but allows you to wrap up the arguments to the called function in an array, which can be quite useful when programatically generating function calls. Replicating the functionality we just talked about using apply is trivial:

<script type="text/javascript">
 ...
 
 multiply.apply(first_object, [5]); // returns 42 * 5
 multiply.apply(second_object, [5]); // returns 24 * 5
</script>

apply and call are very useful on their own, and well worth keeping around in your toolkit, but they only get us halfway to solving the problem of context shifts for event handlers. It’s easy to think that we could solve the problem by simply using call to shift the meaning of this when we set up the handler:

function addhandler() {
 var deep_thought = new BigComputer(42),
  the_button = document.getElementById('thebutton');
 
 the_button.onclick = deep_thought.ask_question.call(deep_thought);
}

The problem with this line of reasoning is simple: call executes the function immediately. Instead of providing a function reference to the onclick handler, we’re giving it the result of an executed function. We need to exploit another feature of JavaScript to really solve this problem.

The Beauty of .bind()

I’m not a huge fan of the Prototype JavaScript framework, but I am very much impressed with the quality of its code as a whole. In particular, one simple addition it makes to the Function object has had a hugely positive impact on my ability to manage the context in which function calls execute: bind performs the same general task as call, altering the context in which a function executes. The difference is that bind returns a function reference that can be used later, rather than the result of an immediate execution that we get with call.

If we simplify the bind function a bit to get at the key concepts, we can insert it into the multiplication example we discussed earlier to really dig into how it works; it’s quite an elegant solution:

<script type="text/javascript">
 var first_object = {
  num: 42
 };
 var second_object = {
  num: 24
 };
 
 function multiply(mult) {
  return this.num * mult;
 }
 
 Function.prototype.bind = function(obj) {
  var method = this,
   temp = function() {
    return method.apply(obj, arguments);
   };
 
  return temp;
 }
 
 var first_multiply = multiply.bind(first_object);
 first_multiply(5); // returns 42 * 5
 
 var second_multiply = multiply.bind(second_object);
 second_multiply(5); // returns 24 * 5
</script>

First, we define first_object, second_object, and the multiply function, just as before. With those taken care of, we move on to creating a bind method on the Function object’s prototype, which has the effect of making bind available for all functions in our program. When multiply.bind(first_object) is called, JavaScript creates an execution context for the bind method, setting this to the multiply function, and setting the first argument, obj, to reference first_object. So far, so good.

The real genius of this solution is the creation of method, set equal to this (the multiply function itself). When the anonymous function is created on the next line, method is accessible via its scope chain, as is obj (this couldn’t be used here, because when the newly created function is executed, this will be overwritten by a new, local context). This alias to this makes it possible to use apply to execute the multiply function, passing in obj to ensure that the context is set correctly. In computer-science-speak, temp is a closure that, when returned at the end of the bind call, can be used in any context whatsoever to execute multiply in the context of first_object.

This is exactly what we need for the event handler and setTimeout scenarios discussed above. The following code solves that problem completely, binding the deep_thought.ask_question method to the deep_thought context, so that it executes correctly whenever the event is triggered:

function addhandler() {
 var deep_thought = new BigComputer(42),
  the_button = document.getElementById('thebutton');
 
 the_button.onclick = deep_thought.ask_question.bind(deep_thought);
}

Beautiful.

References

  • JavaScript Closures is the best resource on the net for a thorough discussion of closures: what they do, how they do it, and how to use them without going insane.
  • The Protype JavaScript Framework is full of little nuggets like bind. The version available here not only allows the binding of a particular this value, but also of some or all of a function’s arguments, which comes in handy all too often.
  • Douglas Crockford’s JavaScript essays are excellent resources for both basic and advanced JavaScript programmers. The man knows what he’s talking about, and explains difficult concepts in an easy-to-grasp manner.
  • Variable Scope for New Programmers is a good article if you’d like more discussion of scope from a beginner’s perspective. Written by Jonathan Snook, and published in this very magazine at the end of last year, it’s still an informative and useful read.
 

Mike West abandoned suburban Texas’ wide open plains in 2005 in favour of the Black Forest in Southern Germany where he currently lives and works. His musings about the web are periodically posted to his personal website, mikewest.org.

—————————————————————-

中文翻译

作用域(scope)是JavaScript语言的基石之一,在构建复杂程序时也可能是最令我头痛的东西。记不清多少次在函数之间传递控制后忘记 this关键字引用的究竟是哪个对象,甚至,我经常以各种不同的混乱方式来曲线救国,试图伪装成正常的代码,以我自己的理解方式来找到所需要访问的变量。

这篇文章将正面解决这个问题:简述上下文(context)和作用域的定义,分析可以让我们掌控上下文的两种方法,最后深入一种高效的方案,它能有效解决我所碰到的90%的问题。

我在哪儿?你又是谁

JavaScript 程序的每一个字节都是在这个或那个运行上下文(execution context)中执行的。你可以把这些上下文想象为代码的邻居,它们可以给每一行代码指明:从何处来,朋友和邻居又是谁。没错,这是很重要的信息,因为 JavaScript社会有相当严格的规则,规定谁可以跟谁交往。运行上下文则是有大门把守的社区而非其内开放的小门。

我们通常可以把这些社会边界称为作用域,并且有充足的重要性在每一位邻居的宪章里立法,而这个宪章就是我们要说的上下文的作用域链(scope chain)。在特定的邻里关系内,代码只能访问它的作用域链内的变量。与超出它邻里的变量比起来,代码更喜欢跟本地(local,即局部)的打交道。

具体地说,执行一个函数会创建一个不同的运行上下文,它会将局部作用域增加到它所定义的作用域链内。JavaScript通过作用域链的局部向全局攀升方式,在特定的上下文中解析标识符。这表示,本级变量会优先于作用域链内上一级拥有相同名字的变量。显而易见,当我的好友们一起谈论”Mike West”(本文原作者)时,他们说的就是我,而非bluegrass singer 或是Duke professor, 尽管(按理说)后两者著名多了。

让我们看些例子来探索这些含义:

<script type="text/javascript">
 var ima_celebrity = "Everyone can see me! I'm famous!",
  the_president = "I'm the decider!";

 function pleasantville() {
  var the_mayor = "I rule Pleasantville with an iron fist!",
   ima_celebrity = "All my neighbors know who I am!";

  function lonely_house() {
   var agoraphobic = "I fear the day star!",
    a_cat = "Meow.";
  }
 }
</script>

我们的全明星,img_celebrity, 家喻户晓(所有人都认识她)。她在政治上积极活跃,敢于在一个相当频繁的基层上叫嚣总统(即the_president)。她会为碰到的每一个人签名和回答问题。就是说,她不会跟她的粉丝有私下的联系。她相当清楚粉丝们的存在 并有他们自己某种程度上的个人生活,但也可以肯定的是,她并不知道粉丝们在干嘛,甚至连粉丝的名字都不知道。

而在欢乐市(pleasantville)内,市长(the_mayor)是众所周知的。她经常在她的城镇内散步,跟她的选民聊天、握手并亲吻小孩。因为欢乐市(pleasantville)还算比较大且重要的邻居,市长在她办公室内放置一台红色电话,它是一条可以直通总统的7×24热线。她还可以看到市郊外山上的孤屋(lonely_house),但从不在意里面住着的是谁。

而孤屋(lonely_house)是一个自我的世界。旷恐患者时常在里面囔囔自语,玩纸牌和喂养一个小猫(a_cat)。他偶尔会给市长(the_mayor)打电话咨询一些本地的噪音管制,甚至在本地新闻看到img_celebrity后会写些粉丝言语给她(当然,这是pleasantville内的img_celebrity)。

this? 那是虾米?

每一个运行上下文除了建立一个作用域链外,还提供一个名为this的关键字。它的普遍用法是,this作为一个独特的功能,为邻里们提供一个可访问到它的途径。但总是依赖于这个行为并不可靠:取决于我们如何进入一个特定邻居的具体情况,this表示的完全可能是其他东西。事实上,我们如何进去邻居家本身,通常恰恰就是this所指。有四种情形值得特别注意:

  • 呼叫对象的方法

    在经典的面向对象编程中,我们需要识别和引用当前对象。this极好地扮演了这个角色,为我们的对象提供了自我查找的能力,并指向它们本身的属性。

    <script type="text/javascript">
      var deep_thought = {
       the_answer: 42,
       ask_question: function () {
        return this.the_answer;
       }
      };
    
      var the_meaning = deep_thought.ask_question();
    </script>

    这个例子建立了一个名为deep_thought的对象,设置其属性 the_answer为42,并创建了一个名为ask_question 的方法(method)。当deep_thought.ask_question()执行时, JavaScript为函数的呼叫建立了一个运行上下文,通过”.“运算符把this指向被引用的对象,在此是deep_thought这个对象。之后这个方法就可以通过this在镜子中找到它自身的属性,返回保存在 this.the_answer中的值:42。

  • 构造函数

    类似地,当定义一个作为构造器的使用new关键字的函数时,this可以用来引用刚创建的对象。让我们重写一个能反映这个情形的例子:

    <script type="text/javascript">
      function BigComputer(answer) {
       this.the_answer = answer;
       this.ask_question = function () {
        return this.the_answer;
       }
      }
    
      var deep_thought = new BigComputer(42);
      var the_meaning = deep_thought.ask_question();
    </script>

    我们编写一个函数来创建BigComputer对象,而不是直白地创建 deep_thought对象,并通过new关键字实例化deep_thought为一个实例变量。当new BigComputer()被执行,后台透明地创建了一个崭新的对象。呼叫BigComputer后,它的this关键字被设置为指向新对象的引用。这个函数可以在this上设置属性和方法,最终它会在BigComputer执行后透明地返回。

    尽管如此,需要注意的是,那个deep_thought.the_question()依然可以像从前一样执行。那这里发生了什么事?为何thisthe_question内与BigComputer内会有所不同?简单地说,我们是通过new进入BigComputer的,所以this表示“新(new)的对象”。在另一方面,我们通过 deep_thought进入the_question,所以当我们执行该方法时,this表示 “deep_thought所引用的对象”。this并不像其他的变量一样从作用域链中读取,而是在上下文的基础上,在上下文中重置

  • 函数呼叫

    假如没有任何相关对象的奇幻东西,我们只是呼叫一个普通的、常见的函数,在这种情形下this表示的又是什么呢?

    <script type="text/javascript">
      function test_this() {
       return this;
      }
      var i_wonder_what_this_is = test_this();
    </script>

    在这样的场合,我们并不通过new来提供上下文,也不会以某种对象形式在背后偷偷提供上下文。在此, this默认下尽可能引用最全局的东西:对于网页来说,这就是 window对象。

  • 事件处理函数

    比普通函数的呼叫更复杂的状况,先假设我们使用函数去处理的是一个onclick事件。当事件触发我们的函数运行,此处的this表示的是什么呢?不凑巧,这个问题不会有简单的答案。

    如果我们写的是行内(inline)事件处理函数,this引用的是全局window对象:

    <script type="text/javascript">
      function click_handler() {
       alert(this); // 弹出 window 对象
      }
    </script>
     ...
    <button id='thebutton' onclick='click_handler()'>Click me!</button>

    但是,如果我们通过JavaScript来添加事件处理函数,this引用的是生成该事件的DOM元素。(注意:此处的事件处理非常简洁和易于阅读,但其他的就别有洞天了。请使用真正的addEvent函数取而代之):

    <script type="text/javascript">
      function click_handler() {
       alert(this); // 弹出按钮的DOM节点
      }
    
      function addhandler() {
       document.getElementById('thebutton').onclick = click_handler;
      }
    
      window.onload = addhandler;
    </script>
     ...
    <button id='thebutton'>Click me!</button>

复杂情况

让我们来短暂地运行一下这个最后的例子。我们需要询问deep_thought一个问题,如果不是直接运行click_handler而是通过点击按钮的话,那会发生什么事情?解决此问题的代码貌似十分直接,我们可能会这样做:

<script type="text/javascript">
 function BigComputer(answer) {
  this.the_answer = answer;
  this.ask_question = function () {
   alert(this.the_answer);
  }
 }

 function addhandler() {
  var deep_thought = new BigComputer(42),
   the_button = document.getElementById('thebutton');

  the_button.onclick = deep_thought.ask_question;
 }

 window.onload = addhandler;
</script>

很完美吧?想象一下,我们点击按钮,deep_thought.ask_question被执行,我们也得到了“42”。但是为什么浏览器却给我们一个undefined? 我们错在何处?

其实问题显而易见:我们给ask_question传递一个引用,它作为一个事件处理函数来执行,与作为对象方法来运行的上下文并不一样。简而言之,ask_question中的 this关键字指向了产生事件的DOM元素,而不是在BigComputer的对象中。DOM元素并不存在一个the_answer属性,所以我们得到的是 undefined而不是”42″. setTimeout也有类似的行为,它在延迟函数执行的同时跑到了一个全局的上下文中去了。

这个问题会在程序的所有角落时不时突然冒出,如果不细致地追踪程序的每一个角落的话,还是一个非常难以排错的问题,尤其在你的对象有跟DOM元素或者window对象同名属性的时候。

使用.apply().call()掌控上下文

在点击按钮的时候,我们真正需要的是能够咨询deep_thought一个问题,更进一步说,我们真正需要的是,在应答事件和setTimeout的呼叫时,能够在自身的本原上下文中呼叫对象的方法。有两个鲜为人知的JavaScript方法,applycall,在我们执行函数呼叫时,可以曲线救国帮我们达到目的,允许我们手工覆盖this的默认值。我们先来看call

<script type="text/javascript">
 var first_object = {
  num: 42
 };
 var second_object = {
  num: 24
 };

 function multiply(mult) {
  return this.num * mult;
 }

 multiply.call(first_object, 5); // 返回 42 * 5
 multiply.call(second_object, 5); // 返回 24 * 5
</script>

在这个例子中,我们首先定义了两个对象,first_objectsecond_object,它们分别有自己的num属性。然后定义了一个multiply函数,它只接受一个参数,并返回该参数与this所指对象的num属性的乘积。如果我们呼叫函数自身,返回的答案极大可能是undefined,因为全局window对象并没有一个num属性除非有明确的指定。我们需要一些途径来告诉multiply里面的this关键字应该引用什么。而multiplycall方法正是我们所需要的。

call的第一个参数定义了在业已执行的函数内this的所指对象。其余的参数则传入业已执行的函数内,如同函数的自身呼叫一般。所以,当执行multiply.call(first_object, 5)时,multiply被呼叫,5传入作为第一个参数,而this关键字被设置为first_object的引用。同样,当执行multiply.call(second_object, 5)时,5传入作为第一个参数,而this关键字被设置为second_object的引用。

applycall一样的方式工作,但可以让你把参数包裹进一个数组再传递给呼叫函数,在程序性生成函数呼叫时尤为有用。使用apply重现上一段代码,其实区别并不大:

<script type="text/javascript">
 ...

 multiply.apply(first_object, [5]); // 返回 42 * 5
 multiply.apply(second_object, [5]); // 返回 24 * 5
</script>

applycall本身都非常有用,并值得贮藏于你的工具箱内,但对于事件处理函数所改变的上下文问题,也只是送佛到西天的中途而已,剩下的还是得我们来解决。在搭建处理函数时,我们自然而然地认为,只需简单地通过使用call来改变this的含义即可:

function addhandler() {
 var deep_thought = new BigComputer(42),
  the_button = document.getElementById('thebutton');

 the_button.onclick = deep_thought.ask_question.call(deep_thought);
}

代码之所以有问题的理由很简单:call立即执行了函数(译注:其实可以用一个匿名函数封装,例如the_button.onclick = function(){deep_thought.ask_question.call(deep_thought);},但比起即将讨论的bind来,依然不够优雅)。我们给onclcik处理函数一个函数执行后的结果而非函数的引用。所以我们需要利用另一个JavaScript特色,以解决这个问题。

.bind()之美

我并不是 Prototype JavaScript framework的忠实粉丝,但我对它的总体代码质量印象深刻。具体而言,它为Function对象增加一个简洁的补充,对我管理函数呼叫执行后的上下文产生了极大的正面影响:bindcall一样执行相同的常见任务,改变函数执行的上下文。不同之处在于bind返回的是函数引用可以备用,而不是call的立即执行而产生的最终结果。

如果需要简化一下bind函数以抓住概念的重点,我们可以先把它插进前面讨论的乘积例子中去,看它究竟是如何工作的。这是一个相当优雅的解决方案:

<script type="text/javascript">
 var first_object = {
  num: 42
 };
 var second_object = {
  num: 24
 };

 function multiply(mult) {
  return this.num * mult;
 }

 Function.prototype.bind = function(obj) {
  var method = this,
   temp = function() {
    return method.apply(obj, arguments);
   };

  return temp;
 }

 var first_multiply = multiply.bind(first_object);
 first_multiply(5); // 返回 42 * 5

 var second_multiply = multiply.bind(second_object);
 second_multiply(5); // 返回 24 * 5
</script>

首先,我们定义了first_object, second_objectmultiply函数,一如既往。细心处理这些后,我们继续为Function对象的prototype定义一个bind方法,这样的话,我们程序里的函数都有一个bind方法可用。当执行multiply.bind(first_object)时,JavaScript为bind方法创建一个运行上下文,把this置为multiply函数的引用,并把第一个参数obj置为first_object的引用。目前为止,一切皆顺。

这个解决方案的真正天才之处在于method的创建,置为this的引用所指(即multiply函数自身)。当下一行的匿名函数被创建,method通过它的作用域链访问,obj亦然(不要在此使用this, 因为新创建的函数执行后,this会被新的、局部的上下文覆盖)。这个this的别名让apply执行multiply函数成为可能,而传递obj则确保上下文的正确。用计算机科学的话说,temp是一个闭包(closure),它可以保证,需要在first_object的上下文中执行multiplybind呼叫的最终返回可以用在任何的上下文中。

这才是前面说到的事件处理函数和setTimeout情形所真正需要的。以下代码完全解决了这些问题,绑定deep_thought.ask_question方法到deep_thought的上下文中,因此能在任何事件触发时都能正确运行:

function addhandler() {
 var deep_thought = new BigComputer(42),
  the_button = document.getElementById('thebutton');

 the_button.onclick = deep_thought.ask_question.bind(deep_thought);
}

漂亮。

Advertisements
5条评论 leave one →
  1. Unknown permalink
    2008/09/18 19:55

    塑料托盘 手推车 仓储笼 钢托盘  钢托盘  托盘  塑料托盘 手推车 仓储笼 料箱 钢托盘 托盘  手推车  仓储笼 塑料托盘 料箱  钢托盘 托盘 塑料托盘 手推车 仓储笼 仓储笼 手推车 料箱 塑料托盘 钢托盘 仓储笼 手推车 料箱 塑料托盘 钢托盘 仓储笼 手推车 料箱 塑料托盘 钢托盘 托盘转运车 仓储笼 手推车 料箱 塑料托盘 钢托盘 托盘转运车 手推车 尼龙吊带 尼龙吊带钢丝绳 起重链条 钢板起重钳 钢板起重吊具 吊钩附件 横梁/吊具 成套索具 钢丝绳 起重链条 钢板起重钳 钢板起重吊具 吊钩附件 横梁/吊具 成套索具  托盘 泰州托盘塑料托盘  手推车 钢托盘 塑料托盘 扬州托盘 各式托盘 泰州托盘  手推车 钢托盘 塑料托盘 扬州托盘 各式托盘 泰州托盘  起重链 柔性吊带 酸性吊带  江苏吊具 吊具  托盘转运车 手推车 钢托盘 塑料托盘 料箱 仓储笼

  2. Unknown permalink
    2008/09/18 19:56

     扬州托盘 泰州托盘 南京托盘 苏州托盘 连云港托盘 上海托盘 北京托盘  江苏托盘  浙江托盘  徐州托盘  高邮托盘 宿迁托盘  长沙托盘 杭州托盘 南昌托盘  镇江托盘  大连托盘 青岛托盘  烟台托盘  广州托盘 威海托盘  扬州托盘 泰州托盘 南京托盘 苏州托盘 连云港托盘 上海托盘 北京托盘 江苏托盘  浙江托盘  徐州托盘   高邮托盘 宿迁托盘  长沙托盘 杭州托盘 南昌托盘  镇江托盘  大连托盘 青岛托盘  烟台托盘 广州托盘 海托盘威 扬州托盘  泰州托盘 南京托盘 苏州托盘 连云港托盘 上海托盘 北京托盘 江苏托盘  浙江托盘  徐州托盘  高邮托盘 宿迁托盘  长沙托盘  杭州托盘 南昌托盘  镇江托盘  大连托盘 青岛托盘  烟台托盘 广州托盘 威海托盘  扬州托盘 泰州托盘 南京托盘 苏州托盘   连云港托盘 上海托盘 北京托盘 江苏托盘  浙江托盘  徐州托盘  高邮托盘 宿迁托盘  长沙托盘 杭州托盘 南昌托盘  镇江托盘   大连托盘 青岛托盘  烟台托盘 广州托盘 威海托盘

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: