你不知道的JavaScript ------- 回调

目录

continuation(延续)

顺序的大脑

执行与计划

嵌套回调与链式回调

信任问题

尝试挽救回调

分离回调

“error-first风格”

 完全不调用

 调用过早

---

continuation(延续)

说白了就是一种编码风格，就是把传统的参数-返回值形式的函数调用转变成“当我执行完操作下一步该干什么”的形式。

如果按照这种模式进行抽象，我们抽象出的很可能是：“早上醒来我要先开车去商店，然后买点牛奶，然后去一下干洗店”，伪代码是这样的：

function 醒来(){
    开车去商店(function(){
        买牛奶(function(){
            去干洗店();
        })
    })
}

嘶，看起来还可以哈，挺干净的，逻辑清晰。但是这是我们构想的情况，现实的情况中往往存在很多“噪声”。

我去商店，发现油箱里剩的油不多了，我只能先去附近最近的加油站加油，等我加完油，到了超市，我发现牛奶卖没了，牛奶没买到，我需要掉头去另一家超市，可是刚来这个城市，我不知道哪里还有超市了，我需要先去手机上检索......

function 醒来(){
    开车去商店(function(){
        if(没油了){
            加油(function(){
                买牛奶(function(){
                    if(没有牛奶){
                        function(){
                            // ...... 
                        }
                    }else{
                        去干洗店()
                    }
                })
            })
        }else{
            买牛奶(function(){
                if(没有牛奶){
                    function()
                }
                去干洗店();
            })
        }
    })
}

 这种写法被称为回调地狱，写到最后，我们已经没法分清哪里是干啥的了，只是在不停的麻木的缝缝补补，添加回调，完全面向运气编程。

// A 
ajax( "..", function(..){ 
 // C 
} ); 
// B

// A 和 // B 表示现在的部分，// C表示将来的部分。前半部分立刻执行，然后是一段时间不确定的停顿。在未来的某个 时刻，如果 Ajax 调用完成，程序就会从停下的位置继续执行后半部分。
我们可以理解为：回调函数包裹或者说封装了程序的延续。

顺序的大脑

• 我们大脑的工作方式优点类似于事件循环队列。
• 大脑在特定的时候，只能思考一件事情。我们好像并行执行多个任务，但实际上可能是快速的上下文切换。
• 也就是在多个任务之间快速地来回切换。
• 我们切换得非常快，对于外界来说，我们就像在并行地执行任务。

执行与计划

• 我们大脑先安排顺序，然后按照顺序（A，然后B，然后C）执行，如果有某种形式的拥塞，会保证B等待A完成，C等待B完成。
• 开发者编写代码的时候是在计划一系列动作的发生。
• 问题是，代码（通过回调）表达异步的方式并不能很好地映射到同步的大脑计划行为。
• 我们思考方式是一步一步的，但是从同步切换到异步后，回调却不是按照一步一步的方式来表达。这就是为什么精确编写和追踪使用回调的异步JavaScript困难的原因。

嵌套回调与链式回调

• 多个函数嵌套在一起，每个函数都代表异步序列（多个有顺序的异步任务）中的一个步骤，这种代码常常被称为回调地狱。

listen("click", function handler(evt) {
    setTimeout(function request() {
        ajax("http://some.url.1", function response(text) {
            if (text == "hello") {
                handler();
            }
            else if (text == "world") {
                request();
            }
        });
    }, 500);
});

这里我们得到了三个函数嵌套在一起构成的链，其中每个函数代表异步序列（任务，“进程”）中的一个步骤。
这种代码常常被称为回调地狱，有时也被称为毁灭金字塔。
手工硬编码（即使包含了硬编码的出错处理）回调的脆弱本性可就远没有这么优雅了。一旦你指定（也就是预选计划）了所有的可能事件和路径，代码就会变得非常复杂，以至于无法维护和更新。
这才是回调地狱的真正问题所在！嵌套和缩进基本上只是转移注意力的枝节而已。

信任问题

回调最大的问题是控制反转，它会导致信任链完全断裂。我们把自己程序一部分的执行控制交给某个第三方，称为控制反转。 我们使用第三方库的API，将回调函数传入的时候，可能会导致一些问题。

比如：在这个第三方库里面，因为某些错误将这个回调执行了多次。你可能只要它执行一次，但这不是你可以控制的。当然，不只是次数问题，还有

• 调用回调过早
• 调用回调过晚（或没有调用）
• 调用次数过多或过少
• 没有成功地将参数传入到回调中
• 吞掉可能出现的报错和异常
• 这不只是针对外部代码，对于我们自己控制下的代码，也可能会有问题。

// A
ajax( "..", function(..){
    // C
} );
// B
 
 

//A和//B发生于现在，在JavaScript主程序的直接控制之下。而//C会延迟到将来发生，并且是在第三方的控制下——在本例中就是函数ajax(..)。从根本上来说，这种控制的转移通常不会给程序带来很多问题。
但是，请不要被这个小概率迷惑而认为这种控制切换不是什么大问题。实际上，这是回调驱动设计最严重（也是最微妙）的问题。它以这样一个思路为中心：有时候ajax(..)（也就是你交付回调continuation的第三方）不是你编写的代码，也不在你的直接控制下。多数情况下，它是某个第三方提供的工具。
我们把这称为控制反转，也就是把自己程序一部分的执行控制交给某个第三方。在你的代码和第三方工具（一组你希望有人维护的东西）之间有一份并没有明确表达的契约。
多数人都同意，至少在某种程度上我们应该在内部函数中构建一些防御性的输入参数检查，以便减少或阻止无法预料的问题。

过分信任输入

function addNumbers(x, y) {
    // +是可以重载的，通过类型转换，也可以是字符串连接
    // 所以根据传入参数的不同，这个运算并不是严格安全的
    return x + y;
}
addNumbers(21, 21); // 42
addNumbers(21, "21"); // "2121"

针对不信任输入的防御性代码：

function addNumbers(x, y) {
    // 确保输入为数字
    if (typeof x != "number" || typeof y != "number") {
        throw Error("Bad parameters");
    }
    // 如果到达这里，可以通过+安全的进行数字相加
    return x + y;
}
addNumbers(21, 21); // 42
addNumbers(21, "21"); // Error: "Bad parameters"

不管你怎么做，这种类型的检查/规范化的过程对于函数输入是很常见的，即使是对于理论上完全可以信任的代码。大体上说，这等价于那条地缘政治原则：“信任，但要核实。”
所以，据此是不是可以推断出，对于异步函数回调的组成，我们应该要做同样的事情，而不只是针对外部代码，甚至是我们知道在我们自己控制下的代码？当然应该。但是，回调并没有为我们提供任何东西来支持这一点。我们不得不自己构建全部的机制，而且通常为每个异步回调重复这样的工作最后都成了负担。
回调最大的问题是控制反转，它会导致信任链的完全断裂。
如果你的代码中使用了回调，尤其是但也不限于使用第三方工具，而且你还没有应用某种逻辑来解决所有这些控制反转导致的信任问题，那你的代码现在已经有了bug，即使它们还没有给你造成损害。隐藏的bug也是bug。

尝试挽救回调

分离回调

回调设计存在几个变体，意在解决前面讨论的一些信任问题（不是全部！）。这种试图从回调模式内部挽救它的意图是勇敢的，但却注定要失败。
举例来说，为了更优雅地处理错误，有些API设计提供了分离回调（一个用于成功通知，一个用于出错通知）：

function success(data) {
    console.log(data);
}
function failure(err) {
    console.error(err);
}
ajax("http://some.url.1", success, failure);

在这种设计下，API的出错处理函数failure()常常是可选的，如果没有提供的话，就是假定这个错误可以吞掉。

“error-first风格”

还有一种常见的回调模式叫做“error-first风格”（有时候也称为“Node”风格，因为几乎所有Node.js API都可以采用这种风格），其中回调的第一个参数保留用作错误对象（如果有的话）。如果成功的话，这个参数就会被清空/置假（后续的参数就是成功数据）。不过，如果产生了错误结果，那么第一个参数就会被置起/置真（通常就不会再传递其他结果）；

function response(err, data) {
    // 出错？
    if (err) {
        console.error(err);
    }
    // 否则认为成功
    else {
        console.log(data);
    }
}
ajax("http://some.url.1", response);

 完全不调用

首先，这并没有像表面看上去那样真正解决主要的信任问题。这并没有涉及阻止或过滤不想要的重复调用回调的问题。现在事情更糟了，因为现在你可能同时得到成功或者失败的结果，或者都没有，并且你还是不得不编码处理所有这些情况。
另外，不要忽略这个事实：尽管这是一种你可以采用的标准模式，但是它肯定更加冗长和模式化，可复用性不高，所以你还得不厌其烦地给应用中的每个回调添加这样的代码。
那么完全不调用这个信任问题又会怎样呢？如果这是个问题的话（可能应该是个问题！），你可能需要设置一个超时来取消事件。可以构造一个工具（这里展示的只是一个“验证概念”版本）来帮助实现这一点：

function timeoutify(fn, delay) {
    var intv = setTimeout(function () {
        intv = null;
        fn(new Error("Timeout!"));
    }, delay)  ;
    return function () {
        // 还没有超时？
        if (intv) {
            clearTimeout(intv);
            fn.apply(this, arguments);
        }
    };
}
// 使用"error-first 风格" 回调设计
function foo(err, data) {
    if (err) {
        console.error(err);
    }
    else {
        console.log(data);
    }
}
ajax("http://some.url.1", timeoutify(foo, 500));

 调用过早 永远使用异步

假设这个ajax函数的设计者自作聪明，它缓存了每一个请求的结果，然后对于缓存中命中的url，它直接同步返回，而对于没命中的url异步去请求，想想这个输出的a是啥？

无法给出一个明确的结果，如果我们的回调被同步调用，那么会输出0，加入我们的回调被异步调用，那么它会在当前任务结束后才会被JS引擎执行，输出的a就是1。

这也是一个回调被提前调用的原因，这样的代码被戏称为Zalgo，一个恶魔，JS社区中经常会调侃这样的代码——不要放出Zalgo！！

• 对于既可能在现在（同步）也可能在将来（异步）调用你的回调的工具来说，会有明显的问题。
• 这种由同步或异步行为引起的不确定性总会带来极大的bug追踪难度。
• 永远异步调用回调，这样所有回调都是可以预测的异步调用了。

function result(data) {
    console.log(a);
}
var a = 0;
ajax("..pre-cached-url..", result);
a++;

这段代码会打印出0（同步回调调用）还是1（异步回调调用）呢？这要视情况而定。
如果你不确定关注的API会不会永远异步执行怎么办呢？可以创建一个类似于这个“验证概念”版本的asyncify(..)工具。

function asyncify(fn) {
    var orig_fn = fn,
        intv = setTimeout(function () {
            intv = null;
            if (fn) fn();
        }, 0);
    fn = null;
    return function () {
        // 触发太快，在定时器intv触发指示异步转换发生之前？
        if (intv) {
            fn = orig_fn.bind.apply(orig_fn)
                // 把封装器的this添加到bind(..)调用的参数中，
                // 以及克里化（currying）所有传入参数
                [this].concat([].slice.call(arguments))
            );
        }else{
            // 已经是异步,调用原来的函数
            orig_fn.apply(this, arguments);
        }
    };
}
function result(data) {
    console.log(a);
}
var a = 0;
ajax("..pre-cached-url..", asyncify(result));
a++;

a++;

不管这个Ajax请求已经在缓存中并试图对回调立即调用，还是要从网络上取得，进而在将来异步完成，这段代码总是会输出1，而不是0——result(..)只能异步调用，这意味着a++有机会在result(..)之前运行

在你自己写代码时，永远不要让Zalgo出现，要么完全同步回调，要么就完全异步回调，当你面临上面的ajax库的缓存需求时，你可以使用一个延时为0的setTimeout，确保回调不在当前任务中执行。