块儿(Chunks)中的程序

你可能将你的JS程序写在一个 .js 文件中,但几乎可以确定你的程序是由几个代码块儿构成的,仅有其中的一个将会在 现在 执行,而其他的将会在 稍后 执行。最常见的 代码块儿 单位是function

大多数刚接触JS的开发者都可能会有的问题是,稍后 并不严格且立即地在 现在 之后发生。换句话说,根据定义,现在 不能完成的任务将会异步地完成,而且我们因此不会有你可能在直觉上期望或想要的阻塞行为。

考虑这段代码:

  1. // ajax(..)是某个包中任意的Ajax函数
  2. var data = ajax( "http://some.url.1" );
  3. console.log( data );
  4. // 噢!`data`一般不会有Ajax的结果

你可能意识到Ajax请求不会同步地完成,这意味着ajax(..)函数还没有任何返回的值可以赋值给变量data。如果ajax(..)在应答返回之前 能够 阻塞,那么data = ..赋值将会正常工作。

但那不是我们使用Ajax的方式。我们 现在 制造一个异步的Ajax请求,直到 稍后 我们才会得到结果。

现在 “等到” 稍后 最简单的(但绝对不是唯一的,或最好的)方法,通常称为回调函数:

  1. // ajax(..) 是某个包中任意的Ajax函数
  2. ajax( "http://some.url.1", function myCallbackFunction(data){
  3. console.log( data ); // Yay, 我得到了一些`data`!
  4. } );

警告: 你可能听说过发起同步的Ajax请求是可能的。虽然在技术上是这样的,但你永远,永远不应该在任何情况下这样做,因为它将锁定浏览器的UI(按钮,菜单,滚动条,等等)而且阻止用户与任何东西互动。这是一个非常差劲的主意,你应当永远回避它。

在你提出抗议之前,不,你渴望避免混乱的回调不是使用阻塞的,同步的Ajax的正当理由。

举个例子,考虑下面的代码:

  1. function now() {
  2. return 21;
  3. }
  4. function later() {
  5. answer = answer * 2;
  6. console.log( "Meaning of life:", answer );
  7. }
  8. var answer = now();
  9. setTimeout( later, 1000 ); // Meaning of life: 42

这个程序中有两个代码块儿:现在 将会运行的东西,和 稍后 将会运行的东西。这两个代码块分别是什么应当十分明显,但还是让我们以最明确的方式指出来:

现在:

  1. function now() {
  2. return 21;
  3. }
  4. function later() { .. }
  5. var answer = now();
  6. setTimeout( later, 1000 );

稍后:

  1. answer = answer * 2;
  2. console.log( "Meaning of life:", answer );

你的程序一执行,现在 代码块儿就会立即运行。但setTimeout(..)还设置了一个 稍后 会发生的事件(一个超时事件),所以later()函数的内容将会在一段时间后(从现在开始1000毫秒)被执行。

每当你将一部分代码包进function并且规定它应当为了响应某些事件而执行(定时器,鼠标点击,Ajax应答等等),你就创建了一个 稍后 代码块儿,也因此在你的程序中引入了异步。

异步控制台

关于console.*方法如何工作,没有相应的语言规范或一组需求——它们不是JavaScript官方的一部分,而是由 宿主环境 添加到JS上的(见本丛书的 类型与文法)。

所以,不同的浏览器和JS环境各自为战,这有时会导致令人困惑的行为。

特别地,有些浏览器和某些条件下,console.log(..)实际上不会立即输出它得到的东西。这个现象的主要原因可能是因为I/O处理很慢,而且是许多程序的阻塞部分(不仅是JS)。所以,对一个浏览器来说,可能的性能更好的处理方式是(从网页/UI的角度看),在后台异步地处理consoleI/O,而你也许根本不知道它发生了。

虽然不是很常见,但是一种可能被观察到(不是从代码本身,而是从外部)的场景是:

  1. var a = {
  2. index: 1
  3. };
  4. // 稍后
  5. console.log( a ); // ??
  6. // 再稍后
  7. a.index++;

我们一般希望看到的是,就在console.log(..)语句被执行的那一刻,对象a被取得一个快照,打印出如{ index: 1 }的内容,如此在下一个语句a.index++执行时,它修改不同于a的输出,或者严格的在a的输出之后的某些东西。

大多数时候,上面的代码将会在你的开发者工具控制台中产生一个你期望的对象表现形式。但是同样的代码也可能运行在这样的情况下:浏览器告诉后台它需要推迟控制台I/O,这时,在对象在控制台中被表示的那个时间点,a.index++已经执行了,所以它将显示{ index: 2 }

到底在什么条件下consoleI/O将被推迟是不确定的,甚至它能不能被观察到都是不确定的。只能当你在调试过程中遇到问题时——对象在console.log(..)语句之后被修改,但你却意外地看到了修改后的内容——意识到I/O的这种可能的异步性。

注意: 如果你遇到了这种罕见的情况,最好的选择是使用JS调试器的断点,而不是依赖console的输出。第二好的选择是通过将目标对象序列化为一个string强制取得一个它的快照,比如用JSON.stringify(..)