新闻资讯

新闻资讯 行业动态

JavaScript与异步·第二话——Promise:一诺千金

编辑:009     时间:2020-02-14

一、难以掌控的回调

我在第一话中介绍了异步的概念、事件循环、以及JS编程中可能的3种异步情况(用户交互、I/O、定时器)。在编写异步操作代码时,最直接、也是每个JSer最先接触的写法一定是回调函数(callback),比如下面这位段代码:

ajax('www.someurl.com', function(res) {
    doSomething();
    ...
});

Ajax请求是一种I/O操作,往往需要较长时间来完成,为了不阻塞单线程的JS程序,故设计为异步操作。此处,将一个匿名函数作为参数传给ajax,意思是“这个匿名函数先放你那儿,但暂不执行,须在收到response之后,再回过头来调用这个函数”,因此这个匿名函数也被称为“回调”。这样的写法相信每个JSer都再熟悉不过了,但仔细想想,这种写法可能有什么问题?

问题就出在“控制反转”。

匿名函数的代码,完完全全是我写的。但是,这段代码何时被调用、调用几次、调用时传入什么参数……等等,我却无法掌握;而本来是被我所调用的ajax函数,竟堂而皇之地接管了我的代码,回调的控制权旁落到了写ajax函数的那家伙手里——控制被反转了。

很多情况下,“那家伙”是个非常可信的机构或公司(比如Google的Chrome团队)、或是比你我牛得多的天才程序员,因此可以放心地把回调交给他。但也有很多情况下,事情并非如此:假如你在开发一个电商网站的代码,把“刷一次信用卡”的回调传给一个第三方库,而那个库很不巧地在某种特殊情况下把这个回调调用了5次,那么,你的老板可能不得不做好准备,在电话中亲自安抚怒气冲冲的顾客。而且,即使换一个第三方合作伙伴,就能保证不再出类似的问题吗?

换句话说,我们无法100%信任接管回调的第三方(当然,那个“第三方”也可能是自己)。

另一个问题是,异步操作本质上是无法保证完成时间的,因此,当多个异步操作需要按先后顺序依次执行、并且后面的步骤依赖于前面步骤的返回结果时,如果用回调的写法,就只能把后一个的步骤硬编码在前一个步骤的回调中,整个操作流程形成一个嵌一个的回调金字塔,再加上异常处理和多分支等情况,口味更加酸爽:

复制代码
ajax(url, function (res){
    ajax(res.url, function(res) {
        ajax(res.url, function(res) { if (res.status == '1') {
                ajax(res.url, function(res) {
                ...
                }
            } else if (res.status == '2') {
                ajax(url2, function(res) {
                ...
            }
            ...
        }
    }
}
);
复制代码

这样的流程是极其脆弱的,而且包含大量重复却无法复用的代码,体验非常糟心。

面对越来越复杂的业务场景,简单的回调已经越来越力不从心,更好的解决方案在哪儿呢?

二、事件订阅模式的启示

也许我们可以尝试换一种模式:不是把回调的控制权交出去,而是让异步操作在返回时触发一个事件,通知主线程异步操作的结果,随后主线程根据预先的设定执行事件相应的回调,这就是“事件订阅模式”。在这种模式下,本来要被反转的回调控制权又被反转回来了,因此称为“反控制反转”。伪代码如下:

复制代码
on('ajax_return', function(val) {
    doSomething();
});
ajax(url, function(res) {
    emitEvent('ajax_return', res);
}); 
复制代码

on()是假想的用于注册事件回调的函数,emitEvent()是假想的用于触发事件的函数。

这种模式解决了控制反转的问题,而且用ES5也能轻松实现。但是,它还没有很好地解决异步流程的问题——总不能为每一个异步操作都单独注册一个事件吧?无论如何,事件订阅模式给我们提供了十分有益的启示,接下来上场的主角正是以这种模式为基础设计的。

三、理解Promise的姿势

Promise是一种范式,专治异步操作的各种疑难杂症。本节不打算逐一介绍Promise的API,而是着重探求其设计思想,由此学习其正确的使用方法。

第一,Promise基于事件订阅模式。我们知道,Promise有三种状态:未决议、决议、拒绝。从未决议变化到决议或拒绝,就相当于触发了一个匿名事件,使得通过then方法注册的fulfilled或rejected回调被调用,实现了反控制反转。

第二,Promise“只能决议一次”的特性,使得“裸回调”和不可信的thenable对象都可以包装为可信的Promise对象。示例代码如下:

复制代码
// 例1.将ajax函数的返回结果Promise化 let p1 = new Promise((resolve, reject) => {
    ajax(url, function(res) { if (res.error) reject(res.error);
        resolve(res);
    });
}); // 例2.将不规范的thenable对象Promise化 let obj = {
    then: function(cb, errcb) {
        cb(1);
        cb(2); // 不合规范的用法! errcb('evil laugh');
    }
};

let p2 = new Promise((resolve, reject) => {
    obj.then(resolve, reject);
}); // 或写成如下语法糖 let p2 = Promise.resolve(obj);
复制代码

例1中,传给ajax的匿名函数不知道会被调用几次,然而由于Promise的特性,保证了只有第一次调用会使Promise的状态发生决议,之后的调用都被直接忽略。

例2中,obj对象有一个then方法,接受两个函数作为参数,所以它是一个thenable对象;但是其内部的代码却完全不符合Promise规范——"fulfilled"被调用了两次,"rejected"也在resolve时被调用,完全是乱来嘛!但是,只要把它包装成p2,那就没有问题了——resolve(1)顺利执行,resolve(2)和reject('evil laugh')被直接忽略。

第三,then方法注册的回调一定会被异步调用,比如:

console.log('A');
Promise.resolve('B').then(console.log);
console.log('C');

执行结果是 A C B。

这是为了将现在值(同步)和未来值(异步)归一化,避免出现Zalgo现象(指同一个操作既可能同步返回也可能异步返回,比如缓存命中则同步返回、未命中则异步返回)。

再看一段代码:

setTimeout(function(){console.log('A');}, 0);
setTimeout(function(){console.log('B');}, 0);
Promise.resolve('C').then(console.log);
Promise.resolve('D').then(console.log);
console.log('E');

执行结果为 E C D A B。

原因在于,Promise的then回调实现异步不是用setTimeout(.., 0),而是用一种叫做Job Queue(任务队列)的专门机制。传统的setTimeout(.., 0)把回调放在Event Loop的末尾,作为一个新的event老老实实排队;而Job Queue是Event Loop中每个event后面挂着的一个队列,往这个队列里插入回调,可以抢在下个event之前执行,相当于“插队”,因此Promise一旦决议,可以以最快的速度(在当前同步代码执行完之后,立刻)调用回调,没有别的异步能够抢在前面(除了另一个Promise)!

第四,then方法会返回一个新的Promise,以fulfilled回调为其resolve,以rejected回调为其reject,因此连续调用then方法可以构成一条Promise链。由于链上的Promise决议有先后顺序(别忘了,每一步都是异步的),因此可以用来控制异步操作的顺序。当然,一般情况下同步操作就不要强行异步化了,我见过p.then(res=>res.text).then(...)这样的代码,除了增加程序复杂度以外好像没什么用处。。。

 

从以上几点可以看出,Promise是一种非常强大的模式,对于异步操作中可能遇到的信任问题、硬编码流程问题等,都设计了相应的机制来加以克服,试着正确地了解它、使用它,你一定能体会到它的好处,从而爱不释手。但是,探寻更优雅的异步操作方法的任务,还没有结束……

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

回复列表

相关推荐