Promise到底解决了什么问题？

我的github博客 https://github.com/zhuanyongxigua/blog

大家都知道Promise解决了回调地狱的问题。说到回调地狱，很容易想到下面这个容易让人产生误解的图片：

可回调地狱到底是什么？它到底哪里有问题？是因为嵌套不好看还是读起来不方便？

首先我们要想想，嵌套到底哪里有问题？

举个例子：

function a() {
  function b() {
    function c() {
      function d() {}
      d();
    }
    c();
  }
  b();
}
a();

这也是嵌套，虽然好像不是特别美观，可我们并不会觉得这有什么问题吧？因为我们经常会写出类似的代码。

在这个例子中的嵌套的问题仅仅是缩进的问题，而缩进除了会让代码变宽可能会造成读代码的一点不方便之外，并没有什么其他的问题。如果仅仅是这样，为什么不叫“缩进地狱”或“嵌套地狱”？

把回调地狱完全理解成缩进的问题是常见的对回调地狱的误解。要回到“回调地狱”这个词语上面来，它的重点就在于“回调”，而“回调”在JS中应用最多的场景当然就是异步编程了。

所以，“回调地狱”所说的嵌套其实是指异步的嵌套。它带来了两个问题：可读性的问题和信任问题。

可读性的问题

这是一个在网上随便搜索的关于执行顺序的面试题：

for (var i = 0; i < 5; i++) {
  setTimeout(function() {
    console.log(new Date, i);
  }, 1000);
}

console.log(new Date, i);

答案是什么大家自己想吧，这不是重点。重点是，你要想一会儿吧？

一个整洁的回调：

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); 
});

如果异步的嵌套都是这样干净整洁，那“回调地狱”给程序猿带来的伤害马上就会减少很多。

可我们实际在写业务逻辑的时候，真实的情况应该是这样的：

listen( "click", function handler(evt){ 
  doSomething1();
  doSomething2();
  doSomething3();
  doSomething4();
  setTimeout( function request(){ 
    doSomething8();
    doSomething9();
    doSomething10();
    ajax( "http:// some. url. 1", function response( text){ 
      if (text == "hello") { 
        handler(); 
      } else if (text == "world") { 
        request(); 
      } 
    }); 
    doSomething11();
    doSomething12();
    doSomething13();
  }, 500); 
  doSomething5();
  doSomething6();
  doSomething7();
});

这些“doSomething”有些是异步的，有些是同步。这样的代码读起来会非常的吃力，因为你要不停的思考他们的执行顺序，并且还要记在脑袋里面。这就是异步的嵌套带来的可读性的问题，它是由异步的运行机制引起的。

信任问题

这里主要用异步请求讨论。我们在做AJAX请求的时候，一般都会使用一些第三方的工具库（即便是自己封装的，也可以在一定程度上理解成第三方的），这就会带来一个问题：这些工具库是否百分百的可靠？

一个来自《YDKJS》的例子：一个程序员开发了一个付款的系统，它良好的运行了很长时间。突然有一天，一个客户在付款的时候信用卡被连续刷了五次。这名程序员在调查了以后发现，一个第三方的工具库因为某些原因把付款回调执行了五次。在与第三方团队沟通之后问题得到了解决。

故事讲完了，可问题真的解决了吗？是否还能够充分的信任这个工具库？信任依然要有，可完善必要的检查和错误处理势在必行。当我们解决了这个问题，由于它的启发，我们还会联想到其他的问题，比如没有调用回调。

再继续想，你会发现，这样的问题还要好多好多。总结一下可能会出现的问题：

• 回调过早（一般是异步被同步调用）；
• 回调过晚或没有回调；
• 回调次数过多；
• 等等

加上了这些检查，强壮之后的代码可能是这样的：

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

我们都清楚的知道，实际的check要比这里看起来的复杂的多，而且很多很难复用。这不但使代码变得臃肿不堪，还进一步加剧了可读性的问题。

虽然这些错误出现的概率不大，但我们依然必须要处理。

这就是异步嵌套带来的信任问题，它的问题的根源在于控制反转。控制反转在面向对象中的应用是依赖注入，实现了模块间的解耦。而在回调中，它就显得没有那么善良了，控制权被交给了第三方，由第三方决定什么时候调用回调以及如何调用回调。

一些解决信任问题的尝试

加一个处理错误的回调

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

nodejs的error-first

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

这两种方式解决了一些问题，减少了一些工作量， 但是依然没有彻底解决问题。首先它们的可复用性依然不强，其次，如回调被多次调用的问题依然无法解决。

Promise如何解决这两个问题

Promise已经是原生支持的API了，它已经被加到了JS的规范里面，在各大浏览器中的运行机制是相同的。这样就保证了它的可靠。

如何解决可读性的问题

这一点不用多说，用过Promise的人很容易明白。Promise的应用相当于给了你一张可以把解题思路清晰记录下来的草稿纸，你不在需要用脑子去记忆执行顺序。

如何解决信任问题

Promise并没有取消控制反转，而是把反转出去的控制再反转一次，也就是反转了控制反转。

这种机制有点像事件的触发。它与普通的回调的方式的区别在于，普通的方式，回调成功之后的操作直接写在了回调函数里面，而这些操作的调用由第三方控制。在Promise的方式中，回调只负责成功之后的通知，而回调成功之后的操作放在了then的回调里面，由Promise精确控制。

Promise有这些特征：只能决议一次，决议值只能有一个，决议之后无法改变。任何then中的回调也只会被调用一次。Promise的特征保证了Promise可以解决信任问题。

对于回调过早的问题，由于Promise只能是异步的，所以不会出现异步的同步调用。即便是在决议之前的错误，也是异步的，并不是会产生同步（调用过早）的困扰。

var a = new Promise((resolve, reject) => {
  var b = 1 + c;  // ReferenceError: c is not defined，错误会在下面的a打印出来之后报出。
  resolve(true);
})
console.log(1, a);
a.then(res => {
  console.log(2, res);
})
.catch(err => {
  console.log(err);
})

对于回调过晚或没有调用的问题，Promise本身不会回调过晚，只要决议了，它就会按照规定运行。至于服务器或者网络的问题，并不是Promise能解决的，一般这种情况会使用Promise的竞态APIPromise.race加一个超时的时间：

function timeoutPromise(delay) {
  return new Promise(function(resolve, reject) {
    setTimeout(function() {
      reject("Timeout!");
    }, delay);
  });
}

Promise.race([doSomething(), timeoutPromise(3000)])
.then(...)
.catch(...);

对于回调次数太少或太多的问题，由于Promise只能被决议一次，且决议之后无法改变，所以，即便是多次回调，也不会影响结果，决议之后的调用都会被忽略。

参考资料：

• You Don't Know JS: Async & Performance